From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f66.google.com (mail-wm0-f66.google.com [74.125.82.66]) by dpdk.org (Postfix) with ESMTP id 890045F30 for ; Wed, 14 Mar 2018 13:23:41 +0100 (CET) Received: by mail-wm0-f66.google.com with SMTP id 139so3673075wmn.2 for ; Wed, 14 Mar 2018 05:23:41 -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 :user-agent; bh=S7Zp+X8qcP2Plcew8tsdPI53AP6b1yywYc/dC+ANCWA=; b=UoeqEkg7mVXT6APGFaYCb80r59jOX1mgfaOkFn/k2A9uss3+5/ORTwMTfYYves4cg9 +wlpL81ElHifeDwF/k3wK/a4kmMpCjdH54fEDhuvlelRjb5Ou6EyfEbLIz4sd6W++vSF qf2bNv4OHfhTQg5z5orIgQxeF0jnd1PdYXuYWYTw7A1tHmNoLs4XTo2zR4fGYDW1HplD uhAzVM3mmy916DFT+JWKvD1pL+iW+Hj1YFjfmPAVFTlPogrJsiw0F5neroYUvi/Fwymw +hULs/Ofp8yRnlWUfNQJ2TpfzyuQ86q77NHopQktwSw/CH8FeSxt8V+4u59cu0pCNCvv KdIA== 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:user-agent; bh=S7Zp+X8qcP2Plcew8tsdPI53AP6b1yywYc/dC+ANCWA=; b=GhDi04iWhUYw5F5cZF0F8bU1KetOONLYORmPsgfdO4IkGRuE5pMv6LHCzG4aiMTqag NC9pvcn595gpuRjpLqwjxq5jop/9yetl5Ih67uy+RTp4z9Q/1DdPyOHB7M2TRBPYqgqP +jRCGLqZCtfy7SSEmYjpbSJ2uJYmDzjNi16HQzBQIQWLOjZ0YUVVbcgE1DSiJ3V7ymmv lC5WwTex9X5O9mQIKU87dfS+xVOIhin92F5dAlp17zRCwC2zXTgYnm4tJdrp52kj3ddQ m9g/Z/o6ZHvDW6ZCTGtsCKil+DKcIv/NmbvdfkWG6bxpCr5SEUWqLs/rsA47LyCplbdx KBcA== X-Gm-Message-State: AElRT7HWoE+nvIW454xPI1A9Y5nX8Q2vEWpZvRqq2HPxRMxr2oSTxfm0 z4eAQ5odnYG6yE6vH7i4OxBv X-Google-Smtp-Source: AG47ELvx8pm2yOE7A3ZabKEw6YZHFQ+o+s437BSMzVNsCZJ9m2u4ndRA5oxlUpft5r+tAaQeF7g80w== X-Received: by 10.28.177.86 with SMTP id a83mr1505147wmf.143.1521030221098; Wed, 14 Mar 2018 05:23:41 -0700 (PDT) Received: from laranjeiro-vm.dev.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id m190sm1221625wmb.6.2018.03.14.05.23.40 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 14 Mar 2018 05:23:40 -0700 (PDT) Date: Wed, 14 Mar 2018 13:22:33 +0100 From: =?iso-8859-1?Q?N=E9lio?= Laranjeiro To: Yongseok Koh Cc: dev@dpdk.org, Adrien Mazarguil , shahafs@mellanox.com, stable@dpdk.org Message-ID: <20180314122233.6ykzqoeyh4pww43w@laranjeiro-vm.dev.6wind.com> References: <21fb91002768a627d9c7f3d81e0c8a12fbf6811f.1518684427.git.nelio.laranjeiro@6wind.com> <20180313215443.GB26229@yongseok-MBP.local> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180313215443.GB26229@yongseok-MBP.local> User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-stable] [PATCH v2 2/3] net/mlx5: fix link status behavior X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 12:23:41 -0000 On Tue, Mar 13, 2018 at 02:54:44PM -0700, Yongseok Koh wrote: > On Mon, Mar 12, 2018 at 02:43:18PM +0100, Nelio Laranjeiro wrote: > > This behavior is mixed between what should be handled by the application > > and what is under PMD responsibility. > > > > According to DPDK API: > > - link_update() should only query the link status [1] > > - link_set_{up,down}() should only set the link to the according status [1] > > - dev_{start,stop}() should enable/disable traffic reception/emission [2] > > The description of rte_eth_dev_set_link_up() is [1] : > The device rx/tx functionality will be disabled if success, and it can > be re-enabled with a call to rte_eth_dev_set_link_up() > > This means, if user runs "set link-down port 0" on testpmd, traffic should stop > by disabling Rx/Tx on device. But unfortunately, mlx5 doesn't have a way to stop > device but it rather relies on kernel implementation - e.g. SIOCSIFFLAGS. So, > even if the command is run, traffic goes on. I guess the original > implementation might be needed to workaround this situation. As you mention the traffic is not disabled on the hardware, which also means that replacing the burst functions does not solve anything, it just moves the issue. The fact is, the queues can still send/receive traffic even if the link is down. Not polling them won't solve the fact that Rx queues will still receive traffic addressed to the application. Considering an application should not try to send nor poll traffic once it has set the link down and this, until it sets the link up, the behavior is identical to the "original" code i.e. at the first poll, the application will receive enqueued packets in the Rx queues while the link was down. > Shall we talk to HW and driver people regarding how to access dev (or PHY) from > user-level? We can. > [1] http://dpdk.org/doc/api/rte__ethdev_8h.html#a51d7a0d2bb4202f9ebf9f174ba1f6e5c Regards, -- Nélio Laranjeiro 6WIND