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
