From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 32F4414EC for ; Wed, 16 Jan 2019 19:21:07 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jan 2019 10:21:06 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,487,1539673200"; d="scan'208";a="136342817" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by fmsmga004.fm.intel.com with ESMTP; 16 Jan 2019 10:21:06 -0800 Received: from fmsmsx161.amr.corp.intel.com (10.18.125.9) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 16 Jan 2019 10:21:06 -0800 Received: from fmsmsx108.amr.corp.intel.com ([169.254.9.99]) by FMSMSX161.amr.corp.intel.com ([169.254.12.181]) with mapi id 14.03.0415.000; Wed, 16 Jan 2019 10:21:05 -0800 From: "Eads, Gage" To: Stephen Hemminger CC: "dev@dpdk.org" , "olivier.matz@6wind.com" , "arybchenko@solarflare.com" , "Richardson, Bruce" , "Ananyev, Konstantin" Thread-Topic: [PATCH] doc: announce ring ABI and API changes Thread-Index: AQHUrTNEqL2T/nLE+k+NWTEPY7tArKWyMwtA Date: Wed, 16 Jan 2019 18:21:05 +0000 Message-ID: <9184057F7FC11744A2107296B6B8EB1E541C7C11@FMSMSX108.amr.corp.intel.com> References: <20190115235934.16065-1-gage.eads@intel.com> <20190115163422.01c0becb@shemminger-XPS-13-9360> In-Reply-To: <20190115163422.01c0becb@shemminger-XPS-13-9360> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOTViMzU4NWYtYzM4Mi00NmJiLWJjZTUtNzRmMDY2NjU3NWJiIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoidERWMmtqZDloZFgxYWNqMk5TcUdnbDhWUlluK0o2c3pXcmRQTlpySDlUbW5qanVXajkrVW1mTjI0ZG1KQUwrUCJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [10.1.200.108] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] doc: announce ring ABI and API changes 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: , X-List-Received-Date: Wed, 16 Jan 2019 18:21:07 -0000 > -----Original Message----- > From: Stephen Hemminger [mailto:stephen@networkplumber.org] > Sent: Tuesday, January 15, 2019 6:34 PM > To: Eads, Gage > Cc: dev@dpdk.org; olivier.matz@6wind.com; arybchenko@solarflare.com; > Richardson, Bruce ; Ananyev, Konstantin > > Subject: Re: [PATCH] doc: announce ring ABI and API changes >=20 > On Tue, 15 Jan 2019 17:59:34 -0600 > Gage Eads wrote: >=20 > > In order to support the non-blocking ring[1], one ABI change and one > > API change are required in librte_ring. This commit updates the > > deprecation notice to pave the way for their inclusion in 19.05. > > > > [1] http://mails.dpdk.org/archives/dev/2019-January/123475.html > > > > Signed-off-by: Gage Eads > > --- > > doc/guides/rel_notes/deprecation.rst | 11 +++++++++++ > > 1 file changed, 11 insertions(+) > > > > diff --git a/doc/guides/rel_notes/deprecation.rst > > b/doc/guides/rel_notes/deprecation.rst > > index d4aea4b46..d74cff467 100644 > > --- a/doc/guides/rel_notes/deprecation.rst > > +++ b/doc/guides/rel_notes/deprecation.rst > > @@ -83,3 +83,14 @@ Deprecation Notices > > - The size and layout of ``rte_cryptodev_qp_conf`` and syntax of > > ``rte_cryptodev_queue_pair_setup`` will change to to allow to use > > two different mempools for crypto and device private sessions. > > + > > +* ring: two changes are planned for rte_ring in v19.05: > > + > > + - The ring head and tail values are planned to be changed from ``uin= t32_t`` > > + to ``size_t``. This reduces the likelihood of wrap-around to effec= tively > > + zero for 64-bit builds, which is important in avoiding the ABA pro= blem in > > + the upcoming non-blocking ring implementation. (32-bit builds are > > + unaffected by this change.) > > + - rte_ring_get_memsize() will get a new ``flags`` parameter, so it c= an > > + calculate the memory required for rings that require more than 8B = per > entry > > + (such as the upcoming non-blocking ring). >=20 >=20 > Would it be possible to support new and old ring types, either through na= ming > tricks and/or new ring flag? Changing things like ring buffer and mbuf a= re > basically a flag day for all users. >=20 > I admit to having a personal interest in this since the API/ABI churn is = this project > causes vendors to stay on older code. And older code does not correctly s= upport > newer networks. Fair enough -- I appreciate the additional context wrt avoiding churn. This might be doable with the following change:=20 " @@ -70,6 +70,15 @@ struct rte_ring_headtail { uint32_t single; /**< True if single prod/cons */ }; =20 +/* 64-bit version of rte_ring_headtail, for use by rings that need to avoi= d + * head/tail wrap-around. + */ +struct rte_ring_headtail_64 { + volatile uint64_t head; /**< Prod/consumer head. */ + volatile uint64_t tail; /**< Prod/consumer tail. */ + uint32_t single; /**< True if single prod/cons */ +}; + /** * An RTE ring structure. * @@ -97,11 +106,19 @@ struct rte_ring { char pad0 __rte_cache_aligned; /**< empty cache line */ =20 /** Ring producer status. */ - struct rte_ring_headtail prod __rte_cache_aligned; + RTE_STD_C11 + union { + struct rte_ring_headtail prod __rte_cache_aligned; + struct rte_ring_headtail_64 prod_64 __rte_cache_aligned; + }; char pad1 __rte_cache_aligned; /**< empty cache line */ =20 /** Ring consumer status. */ - struct rte_ring_headtail cons __rte_cache_aligned; + RTE_STD_C11 + union { + struct rte_ring_headtail cons __rte_cache_aligned; + struct rte_ring_headtail_64 cons_64 __rte_cache_aligned; + }; char pad2 __rte_cache_aligned; /**< empty cache line */ }; " The ABI compatibility hinges on the fact that today's prod and cons are bot= h padded out to a full cache line, and the 64-bit version fits within a sin= gle cache line. (Confirmed with pahole.) abi-compliance-checker reports two issues, but both appear to be false posi= tives: 1. "Field cons has been removed from this type" 2. "Field prod has been removed from this type" I need to do more work to see whether/how the ring functions are affected b= y such a change, but I first want to check if the community agrees with thi= s approach. Note that I don't see any way to avoid the API change to rte_ri= ng_get_memsize, but I doubt that would have near the impact of a ring data = structure change. Thanks, Gage