[dpdk-dev] ixgbe : query regarding your code changes for VF mac add

santosh santosh.iitg at gmail.com
Mon Apr 25 15:35:22 CEST 2016
Previous message: [dpdk-dev] ixgbe : query regarding your code changes for VF mac add
Next message: [dpdk-dev] ixgbe : query regarding your code changes for VF mac add
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi Ivan

 ixgbevf_set_default_mac_addr()   could not find in our code base.
put traces at other places as suggested by you.
 Log at "eth_ixgbevf_dev_init"  never displayed
Rest logs displayed as shown below.  I re-build the  driver module and
loaded on our virtual router and rebooted the system.

1.
Logs at the time of boot up:
-----------------------------------------

INIT: Initializing NIC port 0 RX queue 0 ...
INIT: Initializing NIC port 0 TX queue 0 ...
Santosh ixgbevf_add_mac_addr portid=0 mac=00:50:56:A0:10:C2
.....
....

Santosh ixgbevf_add_mac_addr portid=0 mac=00:50:56:A0:10:C2
RUNTIME: Detected port  0 status changed to UP.

2.
a.
Configured  a new MAC at Virtual Router CLI

root at mx86-bgl-2-r1# set interfaces ge-0/0/0 mac 00:50:56:a0:a0:c3

[edit]
root at mx86-bgl-2-r1# commit
commit complete

[edit]
root at mx86-bgl-2-r1# show interfaces
ge-0/0/0 {
    mac 00:50:56:a0:a0:c3;
    unit 0 {
        family inet {
            address 10.1.1.102/24;
        }
    }
}

[edit]
root at mx86-bgl-2-r1# run ping 10.1.1.101
PING 10.1.1.101 (10.1.1.101): 56 data bytes
64 bytes from 10.1.1.101: icmp_seq=0 ttl=64 time=2.142 ms
64 bytes from 10.1.1.101: icmp_seq=1 ttl=64 time=8.465 ms
^C
--- 10.1.1.101 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.142/5.303/8.465/3.162 ms

[edit]
root at mx86-bgl-2-r1#

b.
   Logs at console for above config:
   -------------------------------------------------

root at localhost:/home/pfe# Santosh ixgbevf_add_mac_addr portid=0
mac=00:50:56:A0:A0:C3

root at localhost:/home/pfe#


3.
a. Deleted above config MAC
root at mx86-bgl-2-r1# delete interfaces ge-0/0/0 mac

[edit]
root at mx86-bgl-2-r1# commit
commit complete

[edit]
root at mx86-bgl-2-r1# show interfaces
ge-0/0/0 {
    unit 0 {
        family inet {
            address 10.1.1.102/24;
        }
    }
}

[edit]
root at mx86-bgl-2-r1# run ping 10.1.1.101
PING 10.1.1.101 (10.1.1.101): 56 data bytes
^C
--- 10.1.1.101 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss

[edit]
root at mx86-bgl-2-r1#

b.
 Logs at console for above cofig
 -------------------------


root at localhost:/home/pfe# ixgbevf_remove_mac_addr santosh portid=0
index=1 mac=00:50:56:A0:A0:C3



Thanks
Santosh














On Fri, Apr 22, 2016 at 12:51 PM, Ivan Boule <ivan.boule at 6wind.com> wrote:
> Hi Santosh,
>
> My job at 6WIND does not consist in answering to DPDK questions. In general,
> I have other priorities, including vacations...
> In the meantime, nobody prevents you to add traces in the code to really
> understand what happens, as suggested in my last answer.
>
> Regards,
> Ivan
>
>
> On 04/21/2016 07:55 AM, santosh wrote:
>>
>> Hi Ivan and team,
>>
>> Please respond to my last mail and  let me know if there is any
>> alternate way to handle this.
>> Our release is in pending due to this issue.
>>
>>
>> Thanks & Regards
>> Santosh
>>
>> On Wed, Apr 20, 2016 at 2:35 PM, santosh <santosh.iitg at gmail.com> wrote:
>>>
>>> Hi Ivan,
>>>
>>> Thanks for your response.
>>>
>>> Let me explain you the issue that we are facing on our virtual router
>>> in VMware environment.
>>>
>>> 1. We are using ixgbe driver , SRIOV enabled .
>>>      root at localhost:~# lspci
>>>        .... "Intel Corporation 82599 Ethernet Controller Virtual
>>> Function"
>>>
>>> 2.  "mx86-bgl-1-r1"  is our router under testing and  R2 is a standard
>>> router.
>>>
>>>        mx86-bgl-1-r1 is connected to R2
>>>        mx86-bgl-1-r1 (10.1.1.103)------------------>R2(10.1.1.101)
>>>
>>> 2. This time ping test passes
>>>
>>> root at mx86-bgl-1-r1# show interfaces
>>> ge-0/0/0 {
>>>      unit 0 {
>>>          family inet {
>>>              address 10.1.1.103/24;
>>>          }
>>>      }
>>> }
>>>
>>> [edit]
>>> root at mx86-bgl-1-r1#
>>> root at mx86-bgl-1-r1# run ping 10.1.1.101
>>> PING 10.1.1.101 (10.1.1.101): 56 data bytes
>>> 64 bytes from 10.1.1.101: icmp_seq=0 ttl=64 time=0.980 ms
>>> 64 bytes from 10.1.1.101: icmp_seq=1 ttl=64 time=1.433 ms
>>>
>>>
>>> 3.  Default MAC address of interface ge-0/0/0  is as shown below:
>>>
>>> root at mx86-bgl-1-r1# run show interfaces ge-0/0/0 extensive | grep current
>>>    Current address: 02:06:0a:0e:ff:f0, Hardware address:
>>> 02:06:0a:0e:ff:f0
>>>
>>> [edit]
>>> root at mx86-bgl-1-r1#
>>>
>>>
>>> 4.  Now I am changing MAC. Ping works this time also
>>>
>>> root at mx86-bgl-1-r1# set interfaces ge-0/0/0 mac 02:06:0a:0a:ff:f0
>>>
>>> [edit]
>>> root at mx86-bgl-1-r1# commit
>>> commit complete
>>>
>>> [edit]
>>> root at mx86-bgl-1-r1# run show interfaces ge-0/0/0 extensive | grep current
>>>    Current address: 02:06:0a:0a:ff:f0, Hardware address:
>>> 02:06:0a:0e:ff:f0
>>>
>>> [edit]
>>> root at mx86-bgl-1-r1# show interfaces
>>> ge-0/0/0 {
>>>      mac 02:06:0a:0a:ff:f0;
>>>      unit 0 {
>>>          family inet {
>>>              address 10.1.1.103/24;
>>>          }
>>>      }
>>> }
>>>
>>> [edit]
>>> root at mx86-bgl-1-r1#
>>> root at mx86-bgl-1-r1# run ping 10.1.1.101
>>> PING 10.1.1.101 (10.1.1.101): 56 data bytes
>>> 64 bytes from 10.1.1.101: icmp_seq=0 ttl=64 time=1.338 ms
>>> 64 bytes from 10.1.1.101: icmp_seq=1 ttl=64 time=8.832 ms
>>> 64 bytes from 10.1.1.101: icmp_seq=2 ttl=64 time=1.292 ms
>>>
>>>
>>> 5.  I am deleting the above configured MAC.
>>>       In this case newly configured MAC as shown above will be deleted
>>> and Default MAC (02:06:0a:0e:ff:f0)
>>>        will be applied.  Ping fails at this step.  "return statement
>>> added by you is not allowing to configure default MAC.
>>>
>>>
>>> [edit]
>>> root at mx86-bgl-1-r1# delete interfaces ge-0/0/0 mac
>>>
>>> [edit]
>>> root at mx86-bgl-1-r1# commit
>>> commit complete
>>>
>>> [edit]
>>> root at mx86-bgl-1-r1# show interfaces
>>> ge-0/0/0 {
>>>      unit 0 {
>>>          family inet {
>>>              address 10.1.1.103/24;
>>>          }
>>>      }
>>> }
>>>
>>> [edit]
>>>
>>> root at mx86-bgl-1-r1# run show interfaces ge-0/0/0 extensive | grep
>>> current     // Displays value from router's local database not from
>>> NIC.
>>>    Current address: 02:06:0a:0e:ff:f0, Hardware address:
>>> 02:06:0a:0e:ff:f0
>>>
>>> [edit]
>>> root at mx86-bgl-1-r1# run ping 10.1.1.101
>>> PING 10.1.1.101 (10.1.1.101): 56 data bytes
>>> ^C
>>> 2 packets transmitted, 0 packets received, 100% packet loss
>>>
>>> [edit]
>>> root at mx86-bgl-1-r1#
>>>
>>>
>>> 7. LOGs:    (I have added a debug log just before the return statement
>>> that you place)
>>>
>>> Log o/p in failure case
>>> ....
>>> Santosh ixgbevf_add_mac_addr returning
>>> ....
>>>
>>> code changes:
>>> -----------------------------
>>> ixgbevf_add_mac_addr(....)  {
>>> ...
>>>      if (memcmp(hw->mac.perm_addr, mac_addr, sizeof(struct ether_addr))
>>> == 0) {
>>>          PMD_DRV_LOG(DEBUG, "Existing MAC \n");
>>>          printf("Santosh %s returning \n",__FUNCTION__);
>>>          return;
>>>      }
>>>
>>>
>>> 8.  If I remove the above "return" statement, build the driver, loaded
>>> in router and repeat the steps-2 to steps-5 of MAC add and MAC delete
>>> on our router then ping passes.
>>>
>>> root at mx86-bgl-1-r1# run ping 10.1.1.101
>>> PING 10.1.1.101 (10.1.1.101): 56 data bytes
>>> 64 bytes from 10.1.1.101: icmp_seq=0 ttl=64 time=2.356 ms
>>> 64 bytes from 10.1.1.101: icmp_seq=1 ttl=64 time=1.415 ms
>>> 64 bytes from 10.1.1.101: icmp_seq=2 ttl=64 time=1.226 ms
>>> ^C
>>> --- 10.1.1.101 ping statistics ---
>>> 3 packets transmitted, 3 packets received, 0% packet loss
>>> round-trip min/avg/max/stddev = 1.226/1.666/2.356/0.494 ms
>>>
>>>
>>> 9.  Please let me know whether is it  fine to remove that return
>>> statement added by you in  "ixgbevf_add_mac_addr"  ?
>>>
>>>
>>>
>>> Thanks & Regards,
>>> Santosh
>>>
>>> On Wed, Apr 20, 2016 at 3:31 AM, Ivan Boule <ivan.boule at 6wind.com> wrote:
>>>>
>>>> Hi Santosh,
>>>>
>>>> I do not get exactly what you attempt to do on a VF.
>>>> Are you first deleting the so-called permanent MAC address by a call to
>>>> the
>>>> function ixgbevf_remove_mac_addr() ? This operation is not allowed.
>>>> Can you explain exactly the sequence of operations that are done, so
>>>> that I
>>>> can understand how the test (memcmp(hw->mac.perm_addr, mac_addr,
>>>> sizeof(struct ether_addr)) == 0) in the function ixgbevf_add_mac_addr()
>>>> prevents them to be successfully performed.
>>>>
>>>> Ivan
>>>>
>>>> PS : please, can you CC your emails to dev at dpdk.org
>>>>
>>>>
>>>> 2016-04-19 17:01 GMT+02:00 santosh <santosh.iitg at gmail.com>:
>>>>>
>>>>>
>>>>> Hi Ivan,
>>>>>
>>>>> Your following code changes causing issue in Vmware environment.
>>>>>
>>>>> ----------------------------------- -------------------
>>>>> ------------------------------
>>>>> + /*
>>>>> + * On a 82599 VF, adding again the same MAC addr is not an idempotent
>>>>> + * operation. Trap this case to avoid exhausting the [very limited]
>>>>> + * set of PF resources used to store VF MAC addresses.
>>>>> + */
>>>>> + if (memcmp(hw->mac.perm_addr, mac_addr, sizeof(struct ether_addr)) ==
>>>>> 0)
>>>>> + return;
>>>>>    diag = ixgbevf_set_uc_addr_vf(hw, 2, mac_addr->addr_bytes);
>>>>> --------------------------------------------------------------------
>>>>> ------------- -------
>>>>>
>>>>>
>>>>> Issue:
>>>>> At CLI , we have provision to add /del MAC of an interface.
>>>>> During MAC delete, existing MAC is deleted and default MAC is applied.
>>>>> This default MAC is not being applied in VMware environment
>>>>> successfully due to "return" statement
>>>>> in your above code changes. As a result traffic is stopped completely.
>>>>> If I remove above
>>>>> "return" statement then traffic continues to flow after MAC delete.
>>>>>
>>>>> Please let me know your suggestion to handle this scenario .  If I
>>>>> remove "return" what will be the consequences ?
>>>>>
>>>>> If removing "return" statement is not good idea then what are other
>>>>> way to handle MAC delete scenario ?  we have only 1 VF per PF in our
>>>>> setup as of now.
>>>>>
>>>>>
>>>>> Thanks
>>>>> Santosh
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Ivan BOULE
>>>> 6WIND
>>>> Software Engineer
>>>>
>>>> Tel: +33 1 39 30 92 47
>>>> Mob: + 33 6 77 25 26 38
>>>> Fax: +33 1 39 30 92 11
>>>> ivan.boule at 6wind.com
>>>> www.6wind.com
>>>> Join the Multicore Packet Processing Forum:
>>>> www.multicorepacketprocessing.com
>>>>
>>>> Ce courriel ainsi que toutes les pièces jointes, est uniquement destiné
>>>> à
>>>> son ou ses destinataires. Il contient des informations confidentielles
>>>> qui
>>>> sont la propriété de 6WIND. Toute révélation, distribution ou copie des
>>>> informations qu'il contient est strictement interdite. Si vous avez reçu
>>>> ce
>>>> message par erreur, veuillez immédiatement le signaler à l'émetteur et
>>>> détruire toutes les données reçues.
>>>>
>>>> This e-mail message, including any attachments, is for the sole use of
>>>> the
>>>> intended recipient(s) and contains information that is confidential and
>>>> proprietary to 6WIND. All unauthorized review, use, disclosure or
>>>> distribution is prohibited. If you are not the intended recipient,
>>>> please
>>>> contact the sender by reply e-mail and destroy all copies of the
>>>> original
>>>> message.
>>>>
>
>
> --
> Ivan Boule
> 6WIND Development Engineer
Previous message: [dpdk-dev] ixgbe : query regarding your code changes for VF mac add
Next message: [dpdk-dev] ixgbe : query regarding your code changes for VF mac add
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the dev mailing list