From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw0-f196.google.com (mail-yw0-f196.google.com [209.85.161.196]) by dpdk.org (Postfix) with ESMTP id EE95A2B8C for ; Mon, 25 Apr 2016 15:35:22 +0200 (CEST) Received: by mail-yw0-f196.google.com with SMTP id i22so25720050ywc.1 for ; Mon, 25 Apr 2016 06:35:22 -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=9W67x/OrpCiiTmjDnPeMIoh5b2AuupTlp8QK+vfFtrA=; b=Nop7Ai1iGcNmj75kv+VjLeBhf5mYgNay2ihbV+wTCyfSUrASiuGL27np2HavnGHj5j 8oA4QzKhnSR/VdSv3SyGLk+a8beov3Gr3Z3RMSBihCPsvUaiL4LjnvE4R5+ByfsbElMj dpt3SwXPt9VKrQMDMM6T3b1c1cuI1z0qGpAmn6+D8xf3dHWsU9OITUTRaAFXnAhSFAWe 3K3mVqtx4DJf5Tbee3NvYjEK6CJ0X/sNQAOzqiji3D2jpWdUEfwXeSOdCNsnD2dXhn5u noei8syVdlGCVJ2V52pbyF2XRGBqVVm3QFLFt02AOVg0/PXRwOg3RejB0/oL45VXjRMD MGKw== 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=9W67x/OrpCiiTmjDnPeMIoh5b2AuupTlp8QK+vfFtrA=; b=fBc6rgS6/qM/r0zqDdIdy/WgQcHzZSpN5h5ugvVlGHAZux9Api3AZSxLSQ2wS5J5ic QG+AL6a+K5aPWaXGm6YNnIT3cK+nTm8UxYkWreKO6QagbSeSY4K+spZ7uR07lWxe6K2B QqGoRcqyX/oAJs3F1G8Smnv5mxWyqh3/6+vv73Q1XkODVKFWfeGDsvTfgFExqGSkhn9n a9Kjrzcj6n9nO/BDlwG6d0+JTKwn2O2XKFdUGfJzJIbAuA/E9eti1ROOsnDV47og5HJB khIm6fFxa183/zvFtalq7A0tzjckdMXLWxxQdBiRrfRr/MF37S6DaFtkjBwcwlTrTH7Q 0pPA== X-Gm-Message-State: AOPr4FWnJ7u9eswDINd5l7XJ+acP7iRofD5id0BtWjUtffppSm+F7tbynywvPwLamRnlYNV9QOMlugjVRkQ9hw== MIME-Version: 1.0 X-Received: by 10.159.37.72 with SMTP id 66mr18871328uaz.111.1461591322338; Mon, 25 Apr 2016 06:35:22 -0700 (PDT) Received: by 10.176.0.73 with HTTP; Mon, 25 Apr 2016 06:35:22 -0700 (PDT) In-Reply-To: <5719D0DD.6070706@6wind.com> References: <5719D0DD.6070706@6wind.com> Date: Mon, 25 Apr 2016 19:05:22 +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: Mon, 25 Apr 2016 21:14:48 +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: Mon, 25 Apr 2016 13:35:23 -0000 Hi Ivan ixgbevf_set_default_mac_addr() could not find in our code base. put traces at other places as suggested by you. Log at "eth_ixgbevf_dev_init" never displayed Rest logs displayed as shown below. I re-build the driver module and loaded on our virtual router and rebooted the system. 1. Logs at the time of boot up: ----------------------------------------- INIT: Initializing NIC port 0 RX queue 0 ... INIT: Initializing NIC port 0 TX queue 0 ... Santosh ixgbevf_add_mac_addr portid=3D0 mac=3D00:50:56:A0:10:C2 ..... .... Santosh ixgbevf_add_mac_addr portid=3D0 mac=3D00:50:56:A0:10:C2 RUNTIME: Detected port 0 status changed to UP. 2. a. Configured a new MAC at Virtual Router CLI root@mx86-bgl-2-r1# set interfaces ge-0/0/0 mac 00:50:56:a0:a0:c3 [edit] root@mx86-bgl-2-r1# commit commit complete [edit] root@mx86-bgl-2-r1# show interfaces ge-0/0/0 { mac 00:50:56:a0:a0:c3; unit 0 { family inet { address 10.1.1.102/24; } } } [edit] root@mx86-bgl-2-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.142 ms 64 bytes from 10.1.1.101: icmp_seq=3D1 ttl=3D64 time=3D8.465 ms ^C --- 10.1.1.101 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev =3D 2.142/5.303/8.465/3.162 ms [edit] root@mx86-bgl-2-r1# b. Logs at console for above config: ------------------------------------------------- root@localhost:/home/pfe# Santosh ixgbevf_add_mac_addr portid=3D0 mac=3D00:50:56:A0:A0:C3 root@localhost:/home/pfe# 3. a. Deleted above config MAC root@mx86-bgl-2-r1# delete interfaces ge-0/0/0 mac [edit] root@mx86-bgl-2-r1# commit commit complete [edit] root@mx86-bgl-2-r1# show interfaces ge-0/0/0 { unit 0 { family inet { address 10.1.1.102/24; } } } [edit] root@mx86-bgl-2-r1# run ping 10.1.1.101 PING 10.1.1.101 (10.1.1.101): 56 data bytes ^C --- 10.1.1.101 ping statistics --- 3 packets transmitted, 0 packets received, 100% packet loss [edit] root@mx86-bgl-2-r1# b. Logs at console for above cofig ------------------------- root@localhost:/home/pfe# ixgbevf_remove_mac_addr santosh portid=3D0 index=3D1 mac=3D00:50:56:A0:A0:C3 Thanks Santosh On Fri, Apr 22, 2016 at 12:51 PM, Ivan Boule wrote: > Hi Santosh, > > My job at 6WIND does not consist in answering to DPDK questions. In gener= al, > I have other priorities, including vacations... > In the meantime, nobody prevents you to add traces in the code to really > 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 >>> 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=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 curre= nt >>> 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 curre= nt >>> 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 wrot= e: >>>> >>>> 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 t= o >>>> 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_a= ddr() >>>> 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 idempoten= t >>>>> + * 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 d= estin=C3=A9 >>>> =C3=A0 >>>> son ou ses destinataires. Il contient des informations confidentielles >>>> qui >>>> sont la propri=C3=A9t=C3=A9 de 6WIND. Toute r=C3=A9v=C3=A9lation, dist= ribution 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 >>>> the >>>> intended recipient(s) and contains information that is confidential an= d >>>> 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