From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ivan Boule Subject: Re: ixgbe : query regarding your code changes for VF mac add Date: Fri, 22 Apr 2016 09:21:01 +0200 Message-ID: <5719D0DD.6070706@6wind.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" To: santosh Return-path: Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com [74.125.82.48]) by dpdk.org (Postfix) with ESMTP id A8C122BF9 for ; Fri, 22 Apr 2016 09:21:13 +0200 (CEST) Received: by mail-wm0-f48.google.com with SMTP id u206so12354560wme.1 for ; Fri, 22 Apr 2016 00:21:13 -0700 (PDT) In-Reply-To: List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Santosh, My job at 6WIND does not consist in answering to DPDK questions. In=20 general, I have other priorities, including vacations... In the meantime, nobody prevents you to add traces in the code to really=20 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 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@localhost:~# lspci >> .... "Intel Corporation 82599 Ethernet Controller Virtual Funct= ion" >> >> 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@mx86-bgl-1-r1# show interfaces >> ge-0/0/0 { >> unit 0 { >> family inet { >> address 10.1.1.103/24; >> } >> } >> } >> >> [edit] >> root@mx86-bgl-1-r1# >> root@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=3D0 ttl=3D64 time=3D0.980 ms >> 64 bytes from 10.1.1.101: icmp_seq=3D1 ttl=3D64 time=3D1.433 ms >> >> >> 3. Default MAC address of interface ge-0/0/0 is as shown below: >> >> root@mx86-bgl-1-r1# run show interfaces ge-0/0/0 extensive | grep curr= ent >> Current address: 02:06:0a:0e:ff:f0, Hardware address: 02:06:0a:0e:f= f:f0 >> >> [edit] >> root@mx86-bgl-1-r1# >> >> >> 4. Now I am changing MAC. Ping works this time also >> >> root@mx86-bgl-1-r1# set interfaces ge-0/0/0 mac 02:06:0a:0a:ff:f0 >> >> [edit] >> root@mx86-bgl-1-r1# commit >> commit complete >> >> [edit] >> root@mx86-bgl-1-r1# run show interfaces ge-0/0/0 extensive | grep curr= ent >> Current address: 02:06:0a:0a:ff:f0, Hardware address: 02:06:0a:0e:f= f:f0 >> >> [edit] >> root@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@mx86-bgl-1-r1# >> root@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=3D0 ttl=3D64 time=3D1.338 ms >> 64 bytes from 10.1.1.101: icmp_seq=3D1 ttl=3D64 time=3D8.832 ms >> 64 bytes from 10.1.1.101: icmp_seq=3D2 ttl=3D64 time=3D1.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@mx86-bgl-1-r1# delete interfaces ge-0/0/0 mac >> >> [edit] >> root@mx86-bgl-1-r1# commit >> commit complete >> >> [edit] >> root@mx86-bgl-1-r1# show interfaces >> ge-0/0/0 { >> unit 0 { >> family inet { >> address 10.1.1.103/24; >> } >> } >> } >> >> [edit] >> >> root@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:f= f:f0 >> >> [edit] >> root@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@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)= ) =3D=3D 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@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=3D0 ttl=3D64 time=3D2.356 ms >> 64 bytes from 10.1.1.101: icmp_seq=3D1 ttl=3D64 time=3D1.415 ms >> 64 bytes from 10.1.1.101: icmp_seq=3D2 ttl=3D64 time=3D1.226 ms >> ^C >> --- 10.1.1.101 ping statistics --- >> 3 packets transmitted, 3 packets received, 0% packet loss >> round-trip min/avg/max/stddev =3D 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 wro= te: >>> 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)) =3D=3D 0) in the function ixgbevf_add_mac_= addr() >>> prevents them to be successfully performed. >>> >>> Ivan >>> >>> PS : please, can you CC your emails to dev@dpdk.org >>> >>> >>> 2016-04-19 17:01 GMT+02:00 santosh : >>>> >>>> Hi Ivan, >>>> >>>> Your following code changes causing issue in Vmware environment. >>>> >>>> ----------------------------------- ------------------- >>>> ------------------------------ >>>> + /* >>>> + * On a 82599 VF, adding again the same MAC addr is not an idempote= nt >>>> + * 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))= =3D=3D 0) >>>> + return; >>>> diag =3D 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 applie= d. >>>> 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 completel= y. >>>> 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@6wind.com >>> www.6wind.com >>> Join the Multicore Packet Processing Forum: >>> www.multicorepacketprocessing.com >>> >>> Ce courriel ainsi que toutes les pi=C3=A8ces jointes, est uniquement = destin=C3=A9 =C3=A0 >>> son ou ses destinataires. Il contient des informations confidentielle= s qui >>> sont la propri=C3=A9t=C3=A9 de 6WIND. Toute r=C3=A9v=C3=A9lation, dis= tribution ou copie des >>> informations qu'il contient est strictement interdite. Si vous avez r= e=C3=A7u ce >>> message par erreur, veuillez imm=C3=A9diatement le signaler =C3=A0 l'= =C3=A9metteur et >>> d=C3=A9truire toutes les donn=C3=A9es re=C3=A7ues. >>> >>> This e-mail message, including any attachments, is for the sole use o= f the >>> intended recipient(s) and contains information that is confidential a= nd >>> proprietary to 6WIND. All unauthorized review, use, disclosure or >>> distribution is prohibited. If you are not the intended recipient, pl= ease >>> contact the sender by reply e-mail and destroy all copies of the orig= inal >>> message. >>> --=20 Ivan Boule 6WIND Development Engineer