From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51]) by dpdk.org (Postfix) with ESMTP id 9A1F72986 for ; Fri, 22 Apr 2016 09:17:32 +0200 (CEST) Received: by mail-wm0-f51.google.com with SMTP id v188so9523136wme.1 for ; Fri, 22 Apr 2016 00:17:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=na9M1A1lsIDhDNwQnetg1VEszkMdPPj2lrh2cTT6XdQ=; b=ZfSxI+1G+mzUPQ/vaGWDsRDPe+X8e3Q317LsFgwELnjRDvu+fLUoucYyFfFghqixxX ocV6XuPZhlvGevT3TW6ZWeTR1woWWCCVmwcqwwiXNb45Vh3wRkxUVqsvDATFQiT44cBl M5B19EyWt4NFX4H1neLsOV+4WTjNddNawie4GaO4wmaWDUubZ6ujrUD6c5X/mpOc27dA F1+k4G1HW/4LZNPYf7gRkwF0YssVnfTjl9BUPaAVWu/sYpgMCZmeIoyJ+qFSvgLKuyoI SoFRBO6RmT3J7gQVhT7N3HEDNQYQlXYx2iPgQpB6vnFDp8w7YxL+KnSoqMRNgUMT/G/Q mW+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=na9M1A1lsIDhDNwQnetg1VEszkMdPPj2lrh2cTT6XdQ=; b=H+RlmEDbmccmt3WVtEg/DKz9kCYgGOLIjO8PFavpTD0h2vu0KSu80ec1Cpnolz36hb wAAEBJ4tbja6IGxt0ktwOkOw5l+bD0To/hScshEONGZTEOlrn/ciPsU1qOVRxjjYGdOe WLRa9DVOA9qyXnJEj+f8zFHSG9jmg64OlIbEiLUecTynYuwtZel33fIPvmmsFAle+R2x Js2LeEAHyv430BUcovbC51+csPDZZ+dfqpB5aNFW+BAGPCa1pZMo/lAo1geIwvCTiUAy EcxgfPkjhOIJV6pXF8Gq9lPz4fZeqRoD0Fk5Sy6soh/TA7yvC9NDeoC63A9zNFAa6VbD r6MQ== X-Gm-Message-State: AOPr4FVEtTZRIz/28PuRqFStl1o8DYhIT6XlYlPLioIH0uoPPxPUCQgHjAHdE4DBqrqGP3r1 X-Received: by 10.195.6.65 with SMTP id cs1mr12143317wjd.8.1461309452372; Fri, 22 Apr 2016 00:17:32 -0700 (PDT) Received: from [10.16.0.189] (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by smtp.gmail.com with ESMTPSA id y70sm531269wmd.3.2016.04.22.00.17.30 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Apr 2016 00:17:31 -0700 (PDT) To: santosh References: Cc: "dev@dpdk.org" From: Ivan Boule Message-ID: <5719CFF7.5000703@6wind.com> Date: Fri, 22 Apr 2016 09:17:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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: Fri, 22 Apr 2016 07:17:32 -0000 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@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@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=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@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=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@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)) == 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=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 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@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)) == 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@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