From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) by dpdk.org (Postfix) with ESMTP id 340F11B740 for ; Wed, 31 Jan 2018 10:15:27 +0100 (CET) Received: by mail-wm0-f47.google.com with SMTP id v71so6463009wmv.2 for ; Wed, 31 Jan 2018 01:15: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:in-reply-to; bh=OuYXlZI4qwGKeqesKZztrtalwMSFdb8NtyHMcoUxuxA=; b=GUQh9aueCd3MCbQ9fxbtrLsXF/DqmFL9wfPc5Y18PtJc6SOBwGIT6nGJRh8UQu1zbT wXxH1oXNJ6uhcmteMQhpw41fo8MmXzdSDpK+g7VqifZ8B8UQ764jhea0Gb6NnextFvEi mghC26EWzhcv2MY3JvI3eteBVHU4Sd9tyBDuisLCFV0P4AAh8Oj8NL05jCUlKxcE/O1o FHaOt/x/jpbPURSjeKwWpa6zYFhf89e7nGJlruY6XablhJU3UnfDiM8t+1/7eBj1vEQh 4ttu9VYAd6ymtaW4gX/ZL0nqflvAApUCbejMGnhZ6DNe8zcEdFDLM/KOMHc/R4xDwslt +ASg== 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:in-reply-to; bh=OuYXlZI4qwGKeqesKZztrtalwMSFdb8NtyHMcoUxuxA=; b=F5nSn2rE2KkAWgjON9EmfbjJSn9RLeGz3/vdgz/ed6vIYXCT5yymFSdb1vcdHJ4ePf a4kWc16okYb0UWVbV+EjutHRxVis+030o6TwsT8ml3GPouFR6oIJyb4gWWWglitDSzdn wz1j6M9pqNwMPVL+wHqimotXDqfsSfImVNWYbu+wV9AoiVGm+/LepR9kMenwgEUEoV2W cpWQDbsWyLM0i0qlh2+P/BybGLwn7ETrWeFDLQTQQGK1bTTp6lfJ0mDuFFJCvvWwtAmJ XhlPCj7z1wX4gRkQ79nV8OCn5bXLaf4gV/d7Zsop3Urm0VOM/pOPw1tjTUQaS5ygOVGa 2NLw== X-Gm-Message-State: AKwxytfUe8K7F6t6IuTSBea3oEOODxsq6BF0WtGMj28DMsd5VwHDYGpO WevjcwtRaPQuL+2hCOWo9JP4sQ8I X-Google-Smtp-Source: AH8x226HNBl4El5Vvh18yISHEIUS5IClSne9572rcZi04oI4NFeTUebRLX0ZQ3Xjq58T9XJE5nFyoQ== X-Received: by 10.80.196.73 with SMTP id w9mr50489112edf.293.1517390126934; Wed, 31 Jan 2018 01:15:26 -0800 (PST) Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id s23sm8701988edm.15.2018.01.31.01.15.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 Jan 2018 01:15:26 -0800 (PST) Date: Wed, 31 Jan 2018 10:15:13 +0100 From: Adrien Mazarguil To: Shahaf Shuler Cc: Mordechay Haimovsky , "dev@dpdk.org" , "stable@dpdk.org" Message-ID: <20180131091513.GS4256@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dpdk-dev] [PATCH v3] net/mlx4: fix dev rmv not detected after port stop 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, 31 Jan 2018 09:15:27 -0000 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. > > 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 -- Adrien Mazarguil 6WIND