From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 8D919A053A; Wed, 5 Aug 2020 22:37:07 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D77E82C28; Wed, 5 Aug 2020 22:37:06 +0200 (CEST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by dpdk.org (Postfix) with ESMTP id 23A582BB5 for ; Wed, 5 Aug 2020 22:37:05 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id DB768714; Wed, 5 Aug 2020 16:37:03 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 05 Aug 2020 16:37:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm1; bh= XNNuK+UNk0ErtYqWxY/K710ZREx3H0AfvRUvTYztV6w=; b=JW1JJiLqY76DBrMF ddueLHYOfd4yiwh7HQ5pah+ckLmiGQ0adxorR0E4jWRVyMecK+xBVbPM8w33J3XH TPmpSo3qwjGNnCbSyzUWwTEkp8ocw9czbeCkx78jYCIhRYG6D3H4oEbe4X5RUSm2 wOAkUdrgn6wRvtdsGOT+ycSuilGoU92N+txhgmg34UBL/u1krwcX2+RiSnss3bZ8 WKROlETqmvwH+X2QM3f6vBAmGwz7aT2e9M93A3AIv2536oFbe4K3ChluUTKENP3N NTgCz5ewnh//zaFuRFIni0QlgeIozhB1SKL2Rr7KSxo5sajWQIPPvvu14KY920ET KHs5Eg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=XNNuK+UNk0ErtYqWxY/K710ZREx3H0AfvRUvTYztV 6w=; b=EAEFshRO3DJx3hcz8m3cVYqYlJ4w5M4KbY7qHHnAqq892vRvhCclPOEr8 bLxtxAmtKXd/pyrv4MljprcMpCeEH4ebesJbSn63wplgIluyseEFBn0b5/PoCTu/ eSLOt4WxPICEDuI1MjJ8RG19k4c/7p8TTYNryMdD0Ovcr9G1GE7B97NhlGVOAeNr wAVSFv+1dSeVSZXUKon5KXwZa+oTrak2myJtd5+o0XLZcNW41zVdrDYHSR1wguuV 2NWiJq8hPWnyOyBJls77AFl54p8BgSqkC8QomlSOYF0fV4+3r2haUWCiSNQVG+T6 Ym7lNUc7N6NqGHrbZqgYhWmpWQZfQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrjeekgdduheehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 4D3FD328005E; Wed, 5 Aug 2020 16:37:02 -0400 (EDT) From: Thomas Monjalon To: Venkat Duvvuru , Ajit Khaparde Cc: dev@dpdk.org, ferruh.yigit@intel.com, Somnath Kotur Date: Wed, 05 Aug 2020 22:37:01 +0200 Message-ID: <13231762.CZJP8ZC4vz@thomas> In-Reply-To: <20200731172302.5292-5-ajit.khaparde@broadcom.com> References: <20200731172302.5292-1-ajit.khaparde@broadcom.com> <20200731172302.5292-5-ajit.khaparde@broadcom.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2 4/4] net/bnxt: fix vfrep add when VF interface is down 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 31/07/2020 19:23, Ajit Khaparde: > From: Venkat Duvvuru > > While adding vfrep port to OVS bridge, vnic & svif information of You should avoid justifying use cases with external applications. > vfrep's endpoint(VF) would be needed to program default flow rules. vfrep is not a well known word. Please use "VF representor". > However, if the endpoint interface is down when vfrep port is added, > firmware will return invalid vnic & svif information. > > This patch fixes the problem by registering to DEFAULT_VNIC_CHANGE > async event and once the async event is received, use the endpoint > information(VF's fid) to fetch it's vnic & svif information and > program the default flow rules. > > Fixes: 322bd6e70272 ("net/bnxt: add port representor infrastructure") It looks to be a patch adding the support of a special case: configuring VF representor while VF is down. I don't think it is a fix. > Signed-off-by: Venkat Duvvuru > Reviewed-by: Somnath Kotur > --- > drivers/net/bnxt/bnxt.h | 21 ++++++++++ > drivers/net/bnxt/bnxt_cpr.c | 51 +++++++++++++++++++++++++ > drivers/net/bnxt/bnxt_ethdev.c | 12 +++++- > drivers/net/bnxt/bnxt_hwrm.c | 4 ++ > drivers/net/bnxt/bnxt_hwrm.h | 2 + > drivers/net/bnxt/bnxt_reps.c | 70 +++++++++++++++++++++++++--------- > 6 files changed, 140 insertions(+), 20 deletions(-) This is quite a big change. This patchset has been deferred (not pulled in next-net) in -rc3. I confirm it is postponed to DPDK 20.11. In general, the idea is to have limits to avoid last minute rushes. Thanks for understanding.