From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 38ABDA0C47; Tue, 6 Jul 2021 15:44:32 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7934D412D7; Tue, 6 Jul 2021 15:44:31 +0200 (CEST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mails.dpdk.org (Postfix) with ESMTP id C01A74120E; Tue, 6 Jul 2021 15:44:29 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id A90C55C0512; Tue, 6 Jul 2021 09:44:26 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Tue, 06 Jul 2021 09:44:26 -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= cV0g1F/lsj6cavt8dX94frJRqv0mG1RHM0+wLxyRopI=; b=h+45UhPJRYs5NkK+ GxgrqclO5GAxiU3IKmXvcOBob6R8ItwxAv+9HyOfg8Pn0bc2lFIopCGNa5KHVoxA SUZBQHuyEa4j8rASdofOSOORNgYLftdo22OeNKruzbiTHBoHXT8LbQG13125Fs03 ZFZwHBvATukWmBzwNm+DnI4AAROl0Voor4JtSVw7lzFUq7OyCMicHSq5Evsk6UYX 2YmvPONKA9LPuSjObqZ+PsKFa+filJf7LHBoQCXddzsnzMQDqjPUnz0rzgbiXh4U gJF/CJDLXEnxCiLmrVV9Bw1Vim1jbclvBJwgSWF/ZBOpj80ABO5oh9xCyx1y3+V8 XfRLfw== 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=cV0g1F/lsj6cavt8dX94frJRqv0mG1RHM0+wLxyRo pI=; b=HuhH3Po9A0tcvyhNa4ZvE+LhP4BGd8vW68Xa/FbAaPmaZAfNxfm8WZLlf Xrt9+oArbmWzQJU/PhHxWPVfIHHtQAw3XFieeGVtXti1Wy1nr9m1/j/RaiupW4IQ Wxlkoazeu6Kw5aBWo2sEDbGelV2WvL252ILEOrR0CvjnHl8fePEHHBs/N0feBgEp F/qxY3XHBq7bBz2JXVK5qs1h9HHEhqRIawIYOXNM8A/aI5x+J5CiBBvkXfDJsR4Q SiAIeqDS0qCXdYGuKx9P8CyzG9iSOAaZAC7xIj8FTqIl3oBZWsoNUxDWRo6MPB7H ysMEtLcecOl9ccsXVNR1O9GyYxRYg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrtddtgddviecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei iedvffegheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 6 Jul 2021 09:44:25 -0400 (EDT) From: Thomas Monjalon To: Viacheslav Ovsiienko Cc: dev@dpdk.org, rasland@nvidia.com, matan@nvidia.com, david.marchand@redhat.com, stable@dpdk.org Date: Tue, 06 Jul 2021 15:44:23 +0200 Message-ID: <1667547.2qPZxae6db@thomas> In-Reply-To: <20210701071552.3339-1-viacheslavo@nvidia.com> References: <20210701071552.3339-1-viacheslavo@nvidia.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v3 1/2] common/mlx5: add provider query port support to glue library X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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" 01/07/2021 09:15, Viacheslav Ovsiienko: > In order to get E-Switch vport identifiers the mlx5 PMD relies > on two approaches: > - use port query API if it is provided by rdma-core library > - otherwise, deduce vport ids from the related VF index > The latter is not reliable and may not work with newer kernel > driver versions and in some configurations (LAG), causing > the E-Switch malfunction. Hence, engaging the port query API > is highly desirable. > > The port attributes query API was supported by vendor rdma-core > versions only (in OFED). In Upstream, the rdma-core mlx5 provider > introduced the port attributes query API since version v35.0 - the > mlx5dv_query_port routine, that differs from vendor API. In order > to support this change in the rdma-core the conditional compilation > flag HAVE_MLX5DV_DR_DEVX_PORT_V35 is introduced by the this patch. > > In the OFED rdma-core version the new compatible mlx5dv_query_port > routine was introduced as well, replacing the existing proprietary > mlx5dv_query_devx_port routine. The proprietary routine is still > controlled in PMD code with HAVE_MLX5DV_DR_DEVX_PORT conditional > flag. > > Currently, the OFED rdma-core library contains both versions of > port query API. And this version is a transitional one, there are "this version" of what? > the plans to remove the proprietary mlx5dv_query_devx_port routine > and the HAVE_MLX5DV_DR_DEVX_PORT flag in PMD will not work anymore. > > With this patch applied the mlx5 PMD can be compiled and operates > over all rdma-core versions: > - Upstream rdma-core before v35 (deduces vport id from VF name) > (* E-Switch may not operate correctly) > - Upstream rdma-core v35 and above (uses common port query API) > - rdma-core OFED before 5.5 (uses proprietary port query API) > - rdma-core OFED 5.5 and above (uses common port query API) This is the kind of explanation which should come first, with exact function and flag names, before and after. > Despite this patch is not a bugfix (it follows the introduced API > variation in underlying library), it covers the major compatibility > issue and is highly desired to be ported to DPDK LTS. > > Cc: stable@dpdk.org > > Signed-off-by: Viacheslav Ovsiienko > Acked-by: Matan Azrad [...] > --- a/drivers/common/mlx5/linux/meson.build > +++ b/drivers/common/mlx5/linux/meson.build > @@ -93,6 +93,8 @@ has_sym_args = [ > 'IBV_WQ_FLAG_RX_END_PADDING' ], > [ 'HAVE_MLX5DV_DR_DEVX_PORT', 'infiniband/mlx5dv.h', > 'mlx5dv_query_devx_port' ], > + [ 'HAVE_MLX5DV_DR_DEVX_PORT_V35', 'infiniband/mlx5dv.h', > + 'mlx5dv_query_port' ], It seems there is an indentation issue. > [ 'HAVE_IBV_DEVX_OBJ', 'infiniband/mlx5dv.h', > 'mlx5dv_devx_obj_create' ], > [ 'HAVE_IBV_FLOW_DEVX_COUNTERS', 'infiniband/mlx5dv.h', [...] > + * pf0vf2, we can deduce the VF number as 2, and set vport index > + * as 3 (2+1). This assigning schema should be changed if the > + * multiple E-Switch instances per PF configurations or/and PCI > + * subfunctions are added. I don't understand this last sentence.