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

santosh santosh.iitg at gmail.com
Wed Apr 20 11:05:24 CEST 2016


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.
>


More information about the dev mailing list