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 A958A12A8 for ; Thu, 21 Apr 2016 07:55:47 +0200 (CEST) Received: by mail-vk0-f68.google.com with SMTP id e185so8953144vkb.2 for ; Wed, 20 Apr 2016 22:55:47 -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=1E53iNYeGSQljtuzt6cBYr7Wa57HWFZJylCS24LiylI=; b=ZcNLNFgS4PUBHMdLTzbwVMUJDeu19WUamal9IBO+90pt1GokZDgu+reBPiNfZAO2Zd EMSdqlMe41GW78A3gJ5H18gYoNXab0kp3TkL8VF98jrI1vEEeRSIkqEUmXAOfu0fbk1x 9Bqg7dfhxpYrv7XnElIR4iTwkRZ94td5AUJrT/ouAgM6/jadk6JC1IaT2XymgNbT0FPA Liv6mAH/Y/mLC2O7CX0DzbelkglyKFtZxF+obPpVj8JZ5pjeMii+bFSXaJ7pOzz4fk1W wQK8OKO9NjKNcttOT6oy/wcnarmSB6h0vGmyLdxvvWmbtrsV8Ts4DHlGZ6DkzkTEqJt7 I0Gw== 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=1E53iNYeGSQljtuzt6cBYr7Wa57HWFZJylCS24LiylI=; b=e6zFnq7ln+0t451dEmMizBtNnhxW8Szv4v/r5D6K3GcHrT6MWysIZX+Rsm0DljF7ss TQpfuSSHUuINt7jwsBxeX/6u+zdztXiVbpzwQKVLM5lolzj/cv8NAiG60ZbCD3bDZOgO SqAeSJwQ/DiGq0LjwLC/CB4TWX6dgmYRwrS2CXhgeuEn6cWzPS3SjR1mongSOTc9jzsP iFDAgGNxucZI4Fvggh9B4k8UOVpqZBg9EHSKGIm196l02R/bLVnJWQKA4CGo9OMWLQ8c uj7AE/GEGjaRKeS5YH3FiWCm6+2gEl8dRp6RnngIEJiVRGa1UlV7YOwZnz6VS5FNlo2r E7mw== X-Gm-Message-State: AOPr4FUaknZWoCy0Nh6w5tgRztMUxbvZ3FZQI281wX0hJugViFjvYZ2/MDyWNDX1xnoiHAlHFH/WdRusb8zEXQ== MIME-Version: 1.0 X-Received: by 10.31.152.11 with SMTP id a11mr7453306vke.69.1461218147110; Wed, 20 Apr 2016 22:55:47 -0700 (PDT) Received: by 10.176.0.73 with HTTP; Wed, 20 Apr 2016 22:55:47 -0700 (PDT) In-Reply-To: References: Date: Thu, 21 Apr 2016 11:25:47 +0530 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: Thu, 21 Apr 2016 16:44:11 +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: Thu, 21 Apr 2016 05:55:48 -0000 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 Function" > > 2. "mx86-bgl-1-r1" is our router under testing and R2 is a standard ro= uter. > > 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 = the >> function ixgbevf_remove_mac_addr() ? This operation is not allowed. >> Can you explain exactly the sequence of operations that are done, so tha= t 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_add= r() >> 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 des= tin=C3=A9 =C3=A0 >> son ou ses destinataires. Il contient des informations confidentielles q= ui >> sont la propri=C3=A9t=C3=A9 de 6WIND. Toute r=C3=A9v=C3=A9lation, distri= bution 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 t= he >> 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, pleas= e >> contact the sender by reply e-mail and destroy all copies of the origina= l >> message. >>