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 41D1EA0613 for ; Mon, 23 Sep 2019 18:36:07 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id F24941BF21; Mon, 23 Sep 2019 18:36:05 +0200 (CEST) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id A39E61BEF8 for ; Mon, 23 Sep 2019 18:36:03 +0200 (CEST) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Sep 2019 09:36:02 -0700 X-IronPort-AV: E=Sophos;i="5.64,541,1559545200"; d="scan'208";a="179185242" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.95]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Sep 2019 09:35:59 -0700 Date: Mon, 23 Sep 2019 18:35:56 +0200 From: Bruce Richardson To: Ray Kinsella Cc: dpdk-dev , Jerin Jacob Kollanukkaran , Hemant Agrawal , Thomas Monjalon , Stephen Hemminger , "Yigit, Ferruh" , "Ananyev, Konstantin" , maxime.coquelin@redhat.com, David Marchand , Marcin Zapolski Message-ID: <20190923163556.GA2009@bricha3-MOBL.ger.corp.intel.com> References: <980083c6-130a-9658-f82b-0c9ddc7cc0cc@ashroe.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <980083c6-130a-9658-f82b-0c9ddc7cc0cc@ashroe.eu> User-Agent: Mutt/1.11.4 (2019-03-13) Subject: Re: [dpdk-dev] RFC: hiding struct rte_eth_dev 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" On Mon, Sep 23, 2019 at 05:19:27PM +0100, Ray Kinsella wrote: > Hi folks, > > The ABI Stability proposals should be pretty well known at this point. > The latest rev is here ... > > http://inbox.dpdk.org/dev/1565864619-17206-1-git-send-email-mdr@ashroe.eu/ > > As has been discussed public data structure's are risky for ABI > stability, as any changes to a data structure can change the ABI. As a > general rule you want to expose as few as possible (ideally none), and > keep them as small as possible. > > One of the key data structures in DPDK is `struct rte_eth_dev`. In this > case, rte_eth_dev is exposed public-ally, as a side-effect of the > inlining of the [rx,tx]_burst functions. > > Marcin Zapolski has been looking at what to do about it, with no current > consensus on a path forward. The options on our table is:- > > 1. Do nothing, live with the risk to DPDK v20 ABI stability. > > 2. Pad rte_eth_dev, add some extra bytes to the structure "in case" we > need to add a field during the v20 ABI (through to 20.11). > > 3. Break rte_eth_dev into public and private structs. > - See > http://inbox.dpdk.org/dev/20190906131813.1343-1-marcinx.a.zapolski@intel.com/ > - This ends up quiet an invasive patch, late in the cycle, however it > does have no performance penalty. > > 4. Uninline [rx,tx]_burst functions > - See > http://inbox.dpdk.org/dev/20190730124950.1293-1-marcinx.a.zapolski@intel.com/ > - This has a performance penalty of ~2% with testpmd, impact on a "real > workload" is likely to be in the noise. > > We need to agree an approach for v19.11, and that may be we agree to do > nothing. My personal vote is 4. as the simplest with minimal impact. > Thanks for calling out these potential options, Ray. #4, uninlining, would also be my preference, though I think #1, do nothing, is probably ok and could live with #2, adding padding, if others like the idea. While #3, splitting structures, has advantages, I just dislike how invasive it is, and don't think it's a good candidate for 19.11. /Bruce