From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f174.google.com (mail-wr0-f174.google.com [209.85.128.174]) by dpdk.org (Postfix) with ESMTP id 92A561B75E for ; Wed, 31 Jan 2018 10:54:27 +0100 (CET) Received: by mail-wr0-f174.google.com with SMTP id v31so14241259wrc.11 for ; Wed, 31 Jan 2018 01:54:27 -0800 (PST) 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=dTt0mjyjdTjbVAk/lPdjjFbQj6wm0WhNX0twbaI3Clc=; b=vRDLJRxn/lngYhbga8QeOKtRaU4i5oY1jGdnP7X7Nhi5mub5K4uehYEtpO5AXS5FAh TrFZ7K1yR/WLQPkjPE9mVISHxAjH3Hd7eCsiu49o86OkP006trDH8LUPCF6oWn4wp/mK FX8GUDogKXHjWU8hN2BAJlhshq4gbnO5motkl3ic1Rt6pOt8OGK7v2bSSQj2XPqIWuQm aY5kDqS/EXkVl42lqvSve1ttBxqgtNUZC5Wm3xbCc6H+yNEplPFYZy9ao7GwJvEf3Y6T KsBX6O9Xw0INymomJYvSk2Kf2a+0sL7KVJ/BFxOHSr2DTzXmgEemDB8qRwN55yvZHS94 7mNA== 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=dTt0mjyjdTjbVAk/lPdjjFbQj6wm0WhNX0twbaI3Clc=; b=EEVI1/nFINgjHTssYHbtWm2FE4KPUP8xE4MaEFs9Kzcxu4ZCl2qvgG2XBviLNI1zj3 jkY8OA7USZlCUZzJRKQihiFnmqK+zYiOHzsnxO/Ac87aBxwqTEtJJXz468Ss0TAD1Ype YTUpzWKoA+OML0D+noBrlileD5eDbpXmCWr1ypIyy4alqeYFS3l8SEqBye6u/Wzy7glW dQbgXt7ASjcZYNmIc3a63pFIcF3ni8C+mqUX0Ilix7uBCtmq5uoRx/C2alBgSOdFbayC 2eiOxeBFymQWV4rBcXXXRbof6iqJKdezo871roSG2LQvcRLDUaAFlsRPAcYpPnMyIDLW Oxkw== X-Gm-Message-State: AKwxytcvqfLOaE4cWoZzu8ecgB6sDhRYs5OZD60ICTAg93pFi737RVT3 TTLhoqRDIxm/LR6Cp42uE86B1g== X-Google-Smtp-Source: AH8x224ErpMvMvPGKYW6cDbzsWPW7bbOMbdJnP46VM1lJ729k+/Qg9M1YjxLCpE+P0240fImMhIGOw== X-Received: by 10.223.168.49 with SMTP id l46mr17519903wrc.29.1517392467141; Wed, 31 Jan 2018 01:54:27 -0800 (PST) Received: from bidouze.vm.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id d73sm17988402wma.25.2018.01.31.01.54.25 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 31 Jan 2018 01:54:26 -0800 (PST) Date: Wed, 31 Jan 2018 10:54:13 +0100 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: Adrien Mazarguil Cc: Shahaf Shuler , Mordechay Haimovsky , "dev@dpdk.org" , "stable@dpdk.org" Message-ID: <20180131095413.oth3ved2lyoriixt@bidouze.vm.6wind.com> References: <1516357009-15463-1-git-send-email-motih@mellanox.com> <1517214877-126768-1-git-send-email-motih@mellanox.com> <20180130093958.GE4256@6wind.com> <20180131091513.GS4256@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180131091513.GS4256@6wind.com> User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH v3] net/mlx4: fix dev rmv not detected after port stop 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, 31 Jan 2018 09:54:27 -0000 On Wed, Jan 31, 2018 at 10:15:13AM +0100, Adrien Mazarguil wrote: > On Tue, Jan 30, 2018 at 08:37:06PM +0000, Shahaf Shuler wrote: > > Tuesday, January 30, 2018 11:40 AM, Adrien Mazarguil: > > > Unfortunately I didn't get a chance to review this patch before it was applied. > > > I'm not sure a stopped port is supposed to report events (interrupts). Will > > > applications expect them to occur at this point? > > > > Why not? > > > > Stopped port is still counted as attached. The fact the application stopped the packet receive on it doesn't mean it should not receive a sync events (such as the remove event). > > async events, by definition, are not related to traffic being flows through the port. > > My comment is based on my understanding of rte_eth_dev_stop(), which is a > device (or port) is completely stopped, in a suspended state and no > interrupts shall occur, as a means for applications to temporarily not be > bothered by them until restarted. > > Think about it that way: applications do not want to get interrupts > immediately after the device is initialized, because they might not be ready > to process them at this point. An explicit call to rte_eth_dev_start() tells > the PMD when it's OK to do so. The converse is rte_eth_dev_stop(). > > Stopping traffic can already be achieved by not polling from the application > side, calling rte_eth_dev_[rt]x_queue_stop() and/or toggling RX/TX > interrupts through rte_eth_dev_[rt]x_intr_enable(). rte_eth_dev_stop() > provides lower-level device control. > > Perhaps documentation is not clear, however that's how LSC seems implemented > in all PMDs; it gets disabled after rte_eth_dev_stop() and one should > explicitly use rte_eth_link_get() to retrieve link status afterward. I think > RMV should behave similarly with rte_eth_dev_is_removed(). Adapting > fail-safe should be easier than modifying all the remaining PMDs. > I think fail-safe should follow the API, but for that the API should be defined explicitly, instead of relying on common interpretation. It makes sense for relatively harmless interrupts (LSC, RX) to be masked when stopped, but I'm not sure this holds true for all possible interrupts (RMV), or future ones. If applications needs to ignore all interrupts at some point, it could be interesting to extend the interrupt API to allow for enabling / disabling them instead of relying on PMDs to register / unregister their callbacks each time. On that note, it could also be interesting for applications that won't use interrupts, not to launch the interrupt thread during rte_eal_init(). This is nonsense to force an additional thread to operate without clear affinity. But I digress. Interrupt API needs an overhaul, and its implementation as well. > > > In my opinion it's not a fix, as in, it doesn't address an issue introduced by the > > > mentioned patch whose behavior was correct. > > > > > > It's probably too late to change it now and it does address an issue seen with > > > a use case involving this PMD, however I think the fail-safe PMD could as well > > > poll using the recently-added rte_eth_dev_is_removed() when it's aware > > > the underlying port is stopped instead of expecting interrupts. > > > > > > -- > > > Adrien Mazarguil > > > 6WIND -- Gaëtan Rivet 6WIND