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 E17EAA0C4C; Thu, 14 Oct 2021 10:26:00 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CF0A64115E; Thu, 14 Oct 2021 10:26:00 +0200 (CEST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by mails.dpdk.org (Postfix) with ESMTP id E9B9840041 for ; Thu, 14 Oct 2021 10:25:58 +0200 (CEST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 75D2F32008FA; Thu, 14 Oct 2021 04:25:57 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Thu, 14 Oct 2021 04:25:58 -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= ycFS1Mo0wUCPtKvlWghbZUkvLC3EuB6F32QX6JIoglo=; b=r1bQ0VtdXQ32zV9g S8gQLlOMRiMIE9egnluTrXKJudwMxswbXNQLQ46clCmwPw1n9IgEk4TPJitb8wBU 3eEHIGF3+AlKkwaynTva0kZ3cNV6/688PAZvtR5g/T1FjIrxOjwEH5WmjJa8bJb6 CskYh3wzjGWy66+M6zjcwSIDpm7TDHAuLYEecwlkcPy3HMPO3gXhocd1wSm15mBM BXOG+20lyjCOvjPHL91TeO7DD1I7wS9WwA64lNfvdLNA4QYLiYkBrA88XJpolht/ niywlVrxPENXUErsi7lR8IqFlfgkLw5aRbSsNRhDIZl8HSIRDzTgWx6dyFZL1vNP LzZm4A== 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=ycFS1Mo0wUCPtKvlWghbZUkvLC3EuB6F32QX6JIog lo=; b=ed47FqWMy0rbZ9Lara38ZHSUHKtV4MuGfgb+Wmh18+fs5q5OPzi1Da7MX DLsX+A7K7iLQZ5HrdmACse//O22CuAp1R6Rx0XGy/qnQE55LBAizOt34Dlpg9KmE ZoDu2R+FyGHGkuRIxLvidb6qB9LAmPTqdwZ1etcJZ2sqSksoleA4RbaMg8uhVkvS 34aA0/TG90tPmZDcFiyCM7WXIS5jkjt4xbCGqbyClqB46G2eTtTtP59X89l/DdLe maHS4bAPnlh5Vjhl+k9cD1tT9lMt0fI9cPb+T0G+oe2Hs/ZahybWJN2ZpQPX/xmY /htBSrKkCKome+kj6lVtdivmGJ7sQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvdduvddgtddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 14 Oct 2021 04:25:55 -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 10:25:53 +0200 Message-ID: <1722442.PpsNWNFnZ4@thomas> In-Reply-To: References: <20210910022402.26620-1-chenbo.xia@intel.com> <2091995.fClCOlFDNO@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 10:07, Xia, Chenbo: > From: Thomas Monjalon > > 14/10/2021 09:00, Xia, Chenbo: > > > From: Thomas Monjalon > > > > 14/10/2021 04:21, Xia, Chenbo: > > > > > From: Thomas Monjalon > > > > > > 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. > > > > > > So the problem here is exposing some APIs to SPDK directly? Without the > > 'enable_driver_sdk' > > > option, I don't see a solution of both exposed and not-ABI. Any idea in your > > mind? > > > > No the idea is to keep using enable_driver_sdk. > > But so far, there is no compatibility guarantee for driver SDK. > > The discussion is about which basic compatibility requirement is needed for > > SPDK. > > Sorry for not understanding your point quickly, but what's the difference of > 'general compatibility' and 'basic compatibility'? Because in my mind, one > struct or function should either be ABI-compatible or not. Could you help explain > it a bit? I wonder whether we could have a guarantee for a subset of structs and functions. Anyway, this is just opening the discussion to collect some inputs first. Then we'll have to check what is possible and get a techboard approval.