From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk0-f68.google.com (mail-vk0-f68.google.com [209.85.213.68]) by dpdk.org (Postfix) with ESMTP id 96A5728FD for ; Wed, 20 Apr 2016 11:05:25 +0200 (CEST) Received: by mail-vk0-f68.google.com with SMTP id a6so5689760vkh.1 for ; Wed, 20 Apr 2016 02:05:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=SR0PALGoSJyyFssNU2c5WYwQTcAiK2zZ1LWJbeJxP3A=; b=EnKWt4K20gEFRruOY8Q0UntYlEGnJDCal+OshmvNrIqLohonX6vC4PkLaQw2lXywVB P5gtW77IYixlZ+49GndeYn/8Sh7iWbAh5vk0GqVUD6o1UPVL+LJ9dBliR2mxMAW5A/US ppzc8ftl9aFZ/E4oR2KOjvGzlXVuHkMfDhD2SYflUEnpmhy8wqX7ISbdra0MGaL5ZX95 SmF9TNJthyo8kjzqQfTdYKu/ZR4+zikh6NrOTSBnrf0VOyhM3E2G5VrqEVxvvWsohOlM 0kHziIp+WpP24eef3SFgv5LPXMTS8Y4YRBl0U4sBzRSvHBoqTe4F0t+G+4Bb2aBCNXxW Etaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=SR0PALGoSJyyFssNU2c5WYwQTcAiK2zZ1LWJbeJxP3A=; b=AkgPNlU82lkLiQprE9X3yojxffahLumaClSUAeGiJQRmI8p7SQrFLzHnqJyH+SbcHb XSxaaLCjYWCpapd8alb2KekFpRBN8Pc5SAJZHxbxpWucxRAew4ZIgiG5JUyVjGyNzDOX BT8qGvimX1drJqOnG/CuesEETEXPL2dPoLZw6tgUTM89Z7Qe4j3EB2qyjJqGDn6hUPg3 Cdg3iUVe3XuJE0rg34TYUGpP9FmmrxCY90PrhSTrij2Ddocqz2cuQwToKFlO2eYJbT6Y scFawvny4XVtAZ5s5Lpig5FnMNyxc8qsw/P/3JPfztnSA9Xkyq9crQj+0YPmg3FdEXcP guoA== X-Gm-Message-State: AOPr4FXRmSuqHyy/tQT0AIpexz7qMZ36YJDS/UDTdrMj3f4+gW2ydK2C7ojfDgK+6WTF8W3wN4K3dOM7hoeDWg== MIME-Version: 1.0 X-Received: by 10.176.3.172 with SMTP id 41mr4236776uau.108.1461143124950; Wed, 20 Apr 2016 02:05:24 -0700 (PDT) Received: by 10.176.0.73 with HTTP; Wed, 20 Apr 2016 02:05:24 -0700 (PDT) In-Reply-To: References: Date: Wed, 20 Apr 2016 05:05:24 -0400 Message-ID: From: santosh To: Ivan Boule Cc: "dev@dpdk.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 20 Apr 2016 11:35:05 +0200 Subject: Re: [dpdk-dev] ixgbe : query regarding your code changes for VF mac add X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 09:05:25 -0000 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 Function" 2. "mx86-bgl-1-r1" is our router under testing and R2 is a standard rout= er. 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 current Current address: 02:06:0a:0e:ff:f0, Hardware address: 02:06:0a:0e:ff: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 current Current address: 02:06:0a:0a:ff:f0, Hardware address: 02:06:0a:0e:ff: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:ff: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 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 t= he > 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 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)) =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 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@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 dest= in=C3=A9 =C3=A0 > son ou ses destinataires. Il contient des informations confidentielles qu= i > sont la propri=C3=A9t=C3=A9 de 6WIND. Toute r=C3=A9v=C3=A9lation, distrib= ution ou copie des > informations qu'il contient est strictement interdite. Si vous avez re=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 of th= e > 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. >