From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f67.google.com (mail-wm0-f67.google.com [74.125.82.67]) by dpdk.org (Postfix) with ESMTP id 797FB5F2A for ; Wed, 14 Mar 2018 13:23:41 +0100 (CET) Received: by mail-wm0-f67.google.com with SMTP id q83so3693222wme.5 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=nOuCsV96lZ+xEqUPGluxRa6mvUiJWgddzGyed3D1jshMmhaWxzUcD+Kb0c6pfdeteX fyVHZAgUSSSJgI/pd7SBKGsel/Kvq+bcVsRZUswtgo7Psv5vZkMDl21Xhn0XF4x+S7Ux V7FrkusukUOZO1nsHmiCskeHONFVD/ZoWUhbYyoIGUGX+NlvxZM7zqo3YdxgsOmDKz0g CROCsyYiFWhhD2HnKBZpu7v9VI5k+g5b/6/cy5/zBXl43t/krlbN8UoqwhhrluVZweD+ qyZ/qKriAxFbHcMvKMzg3D9eNJYnMC6DZobNDbY5C/R7APH+xNc5wF/L80JqRjndfLTb y5uw== X-Gm-Message-State: AElRT7HCoiN3p/lfLeVM+sDN/dPpg7CX1CTLY9oa5kZDPqv+e/UcVTug 4y5cMovoxKnsRKN4kq4Dyz0B 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-dev] [PATCH v2 2/3] net/mlx5: fix link status behavior 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, 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