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 105B0A0C53; Thu, 14 Oct 2021 08:41:49 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id F2E9A40042; Thu, 14 Oct 2021 08:41:48 +0200 (CEST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by mails.dpdk.org (Postfix) with ESMTP id 211BC40041 for ; Thu, 14 Oct 2021 08:41:47 +0200 (CEST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 99A523200AB0; Thu, 14 Oct 2021 02:41:45 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Thu, 14 Oct 2021 02:41:46 -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=fm2; bh= rDHKVISE0iUTurEZvCY4BAG27JC+2D2tzhwbpnOC5cE=; b=KSIingElO7tNNzIK f68YfDU6yoisH2Pi/2fQxRKEJG+9PK4Q+kLBvz7trbfhQpitnlhIOGpvMvXDaji3 OVFo4pPlUqpZAt6upxvJtRnP7JPkxa3SVEvvNhFpqTmKVuUccTC/GjTUUMx7l7PI 5hxAZaNB6JshsBjcSs9lr7SDU9/tFLm6gEwwHNFX0PsJfYaFumaE8CB5RG90SkLm 2DmhYTkrdBFEGcd1CmQij6hh1O72udnhTsHaUi7lu6NFxa5a6VWGx63TABubD1SB TF2M6qR4EBFCwNn8BgtgsC4Kzv0Aj54s7e4D1a2GRO9NYkt2WiZa7W9Pd00pHGik Rp74uA== 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=fm1; bh=rDHKVISE0iUTurEZvCY4BAG27JC+2D2tzhwbpnOC5 cE=; b=dlfnhE0URFf3x30WoTcGN8dWjOIr8yGXqkC+q9aMNjzn5N/6O3LcOrbWr 44yOiJ3LhKOMiKxy2zrI75bP9++e6LuPmzC3SufrdRUipE/Fpzs7J8UXpYbUjUAR KDpMDtzrWkaKXahVBipQgnKyH0ROw1XaG95HPYKlXLE8V3UqvYwILX12HRFh5GgS bIZ3S2IVGNVjmiJZFFTpBGWnR3ZEONoQ8UQQvUPo82FH4b5/FM2XHNvZU8WGWzp0 gRhLSsvUoYzxe94+lqVJjdbM0SaxAjfgeohUMg69rBJF9Ei0FwD9hoolBA2uuRq8 L9hbql+QpPPmqsuVmwNTr74z6RB2g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvdduuddguddtgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdej ueeiiedvffegheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 14 Oct 2021 02:41:43 -0400 (EDT) From: Thomas Monjalon To: "Harris, James R" , "Walker, Benjamin" , "Xia, Chenbo" Cc: "Liu, Changpeng" , David Marchand , "dev@dpdk.org" , Aaron Conole , "Zawadzki, Tomasz" Date: Thu, 14 Oct 2021 08:41:40 +0200 Message-ID: <1656274.a7FMDE9GDv@thomas> In-Reply-To: References: <20210910022402.26620-1-chenbo.xia@intel.com> <3045344.l62tAgFhRq@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2 0/7] Removal of PCI bus ABIs 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" 14/10/2021 04:21, Xia, Chenbo: > From: Thomas Monjalon > > 13/10/2021 19:56, Walker, Benjamin: > > > > From: Thomas Monjalon > > > > > > > > In order to be perfectly clear, all the changes done around this option > > > > enable_driver_sdk share the goal of tidying stuff in DPDK so that ABI > > becomes > > > > better manageable. > > > > I think that nobody want to annoy the SPDK project. > > > > I understand that the changes effectively add troubles, and I am sorry > > about > > > > that. If SPDK and other projects can manage with this change, good. > > > > If there is a real blocker, we should discuss what are the options. > > > > > > > > Thanks for your understanding > > > > > > I completely understand the desire to make the ABI manageable. If I were in > > your shoes, I'd be doing the same exact thing. What I don't currently > > understand is the motivation behind this enable_driver_sdk option. My guess is > > that it's one of two things. > > > > > > \1 ABI manageability: You say that's the purpose above, and that was my > > initial assumption. But wouldn't that necessarily mean, over time, no longer > > considering the symbols that were defined by the header files as part of the > > stable ABI? > > > > Absolutely. The idea is that we don't guarantee ABI for the drivers. > > > > > If you still consider these symbols as part of the ABI in shared library > > builds, then the enable_driver_sdk option does absolutely nothing to improve > > the ABI situation, so why bother to have it at all? We can't have packaged > > SPDK relying on symbols in a packaged DPDK that are not part of the official > > ABI. > > > > > \2 Not supporting out-of-tree drivers: Another option is that you just don't > > want people writing out of tree drivers. > > > > We don't want complications due to support of out-of-tree drivers, > > but we don't want to forbid them. > > > > > You can't just drop it outright because people already do it, > > > but you'd like to not support it for shared library builds at least. > > > > I didn't think about it in these terms. > > But saying we don't offer compatibility for shared library drivers > > is not too far of "no support" indeed. > > > > > So I'd like to really understand which of these two motivated the > > enable_driver_sdk option . Maybe it's not even one of the two above. If it is > > #1, then I think maybe we can work with DPDK to define a very small set of > > out-of-tree driver APIs/ABIs that need to continue to exist in the shared > > libraries by default. I do think SPDK needs only a very small number. If it's > > #2, then that's the entire SPDK use case and I'd ask you to reconsider the > > direction. > > > > Yes I think we need to agree on functions to keep as-is for compatibility. > > Waiting for your input please. > > So, do you mean currently DPDK doesn't guarantee ABI for drivers Yes > but could have driver ABI in the future? I don't think so, not general compatibility, but we can think about a way to avoid breaking SPDK specifically, which has less requirements.