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

Ivan Boule ivan.boule at 6wind.com
Fri Apr 22 09:17:11 CEST 2016


Hi Santosh,

To explain what's really going on in your use case, it would be better 
to add traces in the following functions of the ixgbevf PMD:

Ivan

At the end of eth_ixgbevf_dev_init()

   printf("%s portid=%d mac=%02X:%02X:%02X:%02X:%02X:%02X\n",
          __func__, dev->data->port_id,
          perm_addr->addr_bytes[0],
	 perm_addr->addr_bytes[1],
	 perm_addr->addr_bytes[2],
	 perm_addr->addr_bytes[3],
	 perm_addr->addr_bytes[4],
	 perm_addr->addr_bytes[5]);

At the begining of ixgbevf_add_mac_addr()

    printf("%s portid=%d mac=%02X:%02X:%02X:%02X:%02X:%02X\n",
           __func__, dev->data->port_id,
           mac_addr->addr_bytes[0],
	  mac_addr->addr_bytes[1],
	  mac_addr->addr_bytes[2],
	  mac_addr->addr_bytes[3],
	  mac_addr->addr_bytes[4],
	  mac_addr->addr_bytes[5]);

At the begining of ixgbevf_remove_mac_addr()

  printf("%s portid=%d index=%d mac=%02X:%02X:%02X:%02X:%02X:%02X\n",
         __func__, dev->data->port_id, index,
         dev->data->mac_addrs[i].addr_bytes[0],
	dev->data->mac_addrs[i].addr_bytes[1],
	dev->data->mac_addrs[i].addr_bytes[2],
	dev->data->mac_addrs[i].addr_bytes[3],
	dev->data->mac_addrs[i].addr_bytes[4],
	dev->data->mac_addrs[i].addr_bytes[5]);

At the begining of ixgbevf_set_default_mac_addr()

    printf("%s portid=%d mac=%02X:%02X:%02X:%02X:%02X:%02X\n",
           __func__, dev->data->port_id,
           addr->addr_bytes[0],
	  addr->addr_bytes[1],
	  addr->addr_bytes[2],
	  addr->addr_bytes[3],
	  addr->addr_bytes[4],
	  addr->addr_bytes[5]);

On 04/20/2016 11:05 AM, santosh 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


More information about the dev mailing list