From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f179.google.com (mail-wr0-f179.google.com [209.85.128.179]) by dpdk.org (Postfix) with ESMTP id 7A9B67EE0 for ; Wed, 18 Apr 2018 11:05:06 +0200 (CEST) Received: by mail-wr0-f179.google.com with SMTP id q13-v6so2685753wre.3 for ; Wed, 18 Apr 2018 02:05:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=+9b9lNlLddX1TGg1LarEerMB0M3Wx1BRNeDh1ai5Tio=; b=dL6fTp70WXsTZbO3wKBbJ/1OiYD2X1QEzYq4OtDpxBBaBFnPWjjM+UZTqmnpCe67gd EpNh11sLM4ytc55R8zYRz5G+tYWbDMUaT9OiyiXSWgObU74o1mmoBcoMqvP+Uk0CNYzb GQcrbfF9GpSsN2+R6j/oKhhdxI8o0iBe3QD0H96wyuy/SGWrurwW48aIZ/sObqeprVzG lltVpBq8MK58nBgSMeyPC2mD1H0/mm3xhZXCwbwB0lh/NmGdb5PwVLJYe+trdPkKCnwq GT/G5ZVHTlmh/556NBS+m3VqAPAc2sSX/xpNhQw5ZeOXSO5fKtd8Fo2LIWZNeCkQrY6I C3HQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=+9b9lNlLddX1TGg1LarEerMB0M3Wx1BRNeDh1ai5Tio=; b=ueMoA2/slEY94ZJ1LHrxIf1Rd7gw1sMfKmY/ZbNgq+JE2bIEWgSj4E/56ZOw/TxVsa 55luelUFZDnG2axajg27jFRtH0ADkHSX1Z0xaV55gricd74zw8WsoTKr9W52C0fTKhL8 YBf12EQga7bHfwXfJnFjBsRywxoN6iJC8VanzSwJG54xPSKMB7UQXDuyO98mYlinp8aI 1q61oDZhiaR29EaxrSpTvrMtB+Fafo2puImUUmYTk/LyK1C6UI4egKjued+OK0wwjkXK d4uxTYNtkp6ploWlSNloOWvGSUfohcSxMB4RqtSQL3dZUNFOZJMS00BuySBW56VBblON s+Dg== X-Gm-Message-State: ALQs6tBEuSyPCE+810DOym6I2x7lj+GYkU/rXK9FqypT4Top1Q6YbAVo 7IHLelp9DmojMqDTlFcpDgNMF5+B X-Google-Smtp-Source: AIpwx4/pfdvOAGa4bFSCdk93jXWQ9SU8IVrf18Kj8TErQDYFJMx0DYOMAGrM96uc13lZ0fuojPruJg== X-Received: by 2002:adf:b859:: with SMTP id u25-v6mr1014797wrf.162.1524042306167; Wed, 18 Apr 2018 02:05:06 -0700 (PDT) Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id 78sm1535960wmm.19.2018.04.18.02.05.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Apr 2018 02:05:05 -0700 (PDT) Date: Wed, 18 Apr 2018 11:04:52 +0200 From: Adrien Mazarguil To: chenchanghu Cc: "dev@dpdk.org" , "nelio.laranjeiro@6wind.com" , "Zhoujingbin (Robin, Cloud Networking)" , "Zhoulei (G)" , yangleyuan Message-ID: <20180418090452.GO4957@6wind.com> References: <859E1CB9FBF08C4B839DCF451B09C5032E0137FD@dggeml509-mbx.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <859E1CB9FBF08C4B839DCF451B09C5032E0137FD@dggeml509-mbx.china.huawei.com> Subject: Re: [dpdk-dev] reply: [disscussion] A problem about dpdk backup-mode bond switching with mlx4 VF devices X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 09:05:06 -0000 On Wed, Apr 18, 2018 at 01:55:41AM +0000, chenchanghu wrote: > Hi, Adrien Mazarguil, > > Thanks for your reply very much. > > It means in our tests, when ‘ifconfig eth7 down’, the expect result is the bond primary netdevice will switch to eth8. > > However, we find the bond primary is not changed to eth8 in 19 times of 20 time tests., and it means the dpdk bond doesn't receive an LSC interrupt signal. > > In our test, the netdevice is mlx4 VF in Virtual Machine, which netdevice is direct through by SR-IOV. I overlooked this part, I'm not sure VFs impact link status on the DPDK side since they can't really bring it down. Regardless, you should have encountered an identical behavior 20 out of 20 times otherwise there could be a bug in the DPDK version you're using. > We also test mlx4 PF in Physical Machine, when ‘ifconfig eth7 down’, the test esult is the bond primary netdevice switched to eth8. Right, PF has authority over link status, this is expected as documented. > Quesetion: > > Is it related with SR-IOV direct through ? For example, the VF netdevice status changed, but it will not send an LSC interruput signal. > > Looking forward to your any reply. To summarize, updating the link status of a netdevice associated with a VF shouldn't impact a DPDK application. On the other hand updating it on a netdevice associated with PF will impact all VFs and their applications. Please check again with a more recent DPDK version (e.g. 18.02). If you manage to get a consistent behavior every time, it means a bug is present in in 16.04. > -----邮件原件----- > 发件人: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com] > 发送时间: 2018年4月17日 18:08 > 收件人: chenchanghu > 抄送: dev@dpdk.org; nelio.laranjeiro@6wind.com; Zhoujingbin (Robin, Cloud Networking) ; Zhoulei (G) ; yangleyuan > 主题: Re: [disscussion] A problem about dpdk backup-mode bond switching with mlx4 VF devices > > > > On Tue, Apr 17, 2018 at 06:40:20AM +0000, chenchanghu wrote: > > > > > > Hi, > > > When I used the mlx4 pmd, I meet a problem about mlx4 VF bond switching which bond mod is backup-mode . The detail test is descripted below. > > > 1.Test environmemt infomation: > > > a. Linux distribution: CentOS > > > b. dpdk version: dpdk-16.04 > > > c. Ethernet device : mlx4 VF > > > d. pmd info: mlx4 poll-mode-driver > > > > > > 2.Test step: > > > a. we bond the mlx4 VF Ethernet device eth7,eth8 into backup-mode by dpdk application. Eth7 and eth8 are both active, and eth7 is the primary device. > > > b. As we know, the device eth7 , eth8 are also visible by kernel driver mlx4_en. > > > c. Then we config the Ethernet device eth7 down by the command ' ifconfig eth7 down', the expect result is the bond primary device will not switch. > > > d. However we find the dpdk bond primary device switch to eth8 by dpdk maintenance interface one time in all 20 test times. > > > > > > 3.Question: > > > Is the VF up or down State of kernel interface has some relations to user-space state? For example, when ifconfig eth7 down, and the user-space will change to down state too. > > > > Yes, this is expected. Netdevices and the mlx4 DPDK PMD share a common link status. Bringing a netdevice down causes link status to be down for all its users. This behavior is documented [1]. > > > > [1] http://dpdk.org/doc/guides/nics/mlx4.html#run-time-configuration > > > > -- > > Adrien Mazarguil > > 6WIND -- Adrien Mazarguil 6WIND