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 E2EE4A0C55; Wed, 13 Oct 2021 20:59:59 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C9367411FA; Wed, 13 Oct 2021 20:59:59 +0200 (CEST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) by mails.dpdk.org (Postfix) with ESMTP id 4AFF3411EC for ; Wed, 13 Oct 2021 20:59:58 +0200 (CEST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id CFC003200F81; Wed, 13 Oct 2021 14:59:54 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 13 Oct 2021 14:59:55 -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= soxnplPystCTVyRBehgIxZOSTBnG7T3CYwFUOrJZuEw=; b=V4u5kHla/YWzak0D ji+IDJrpvNdxfzFOJq6USpQK3GYzLe2S/VmLRWUgblar4Vho1BLrWVLFhIX6Kd7C 8JnbDW32fyFQpEeY9oMZtB45f21DgjZTtmnivO1DYYAKdec1WSb5XM7Pvmlj81pE a8IxXC/2pVzjC44CKcGKpR1mCQ7Cs0RQxbEFXiDzw7MtGyqL/K/ZiOG5FAweGBMf nBaxbg61TjQraxqk5LAPETozE/mcM9Qxd5yt8WfliWeu7+T9BeZUoACrb9y1IgtS 4CoQrAZDwUUpEmTN3Ca/88vPbXfOMyUliyDOEqUzouV3Hjn2RgBasVEIRCW62A5l pSI+bA== 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=soxnplPystCTVyRBehgIxZOSTBnG7T3CYwFUOrJZu Ew=; b=fAsYZn7pRuQPQbAxcphKxdGKIvfMnUd+lGzqsOZuGHIlU+ge8uAu6EiWN kf2ojP3ABH1P5/X2+6033o9//1j70900lIrMd9TSAzu22qyKk1MC3BB2sWSglW9W MaJ5UnqlIMw6YoxnIhadMRfk3oRfgoRRlEFzC4Zqi+tsJX4mG1gouMeHHLxvDw6y 7RJ+9LhIxq/pYl0dvQCD2JfLW38XB9d++2DhmixpuDDoWPDEu/9YIdE4iUuUt5ML JZnYdTF+eIqFFWjAzZHF3rULNle1nc2urIIJ5jGrCq4LORKUjj8HL3zDCjtl3n6T t3oKfTU3gqB16OtJ2BbrISQQNohdg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvddutddguddvlecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdej ueeiiedvffegheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 13 Oct 2021 14:59:52 -0400 (EDT) From: Thomas Monjalon To: "Harris, James R" , "Walker, Benjamin" Cc: "Liu, Changpeng" , "Xia, Chenbo" , David Marchand , "dev@dpdk.org" , Aaron Conole , "Zawadzki, Tomasz" Date: Wed, 13 Oct 2021 20:59:49 +0200 Message-ID: <3045344.l62tAgFhRq@thomas> In-Reply-To: References: <20210910022402.26620-1-chenbo.xia@intel.com> <2268633.u4cMhumtpX@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" 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.