From: "Eads, Gage" <gage.eads@intel.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
"olivier.matz@6wind.com" <olivier.matz@6wind.com>,
"arybchenko@solarflare.com" <arybchenko@solarflare.com>,
"Richardson, Bruce" <bruce.richardson@intel.com>,
"Ananyev, Konstantin" <konstantin.ananyev@intel.com>
Subject: Re: [dpdk-dev] [PATCH] doc: announce ring ABI and API changes
Date: Wed, 16 Jan 2019 18:21:05 +0000 [thread overview]
Message-ID: <9184057F7FC11744A2107296B6B8EB1E541C7C11@FMSMSX108.amr.corp.intel.com> (raw)
In-Reply-To: <20190115163422.01c0becb@shemminger-XPS-13-9360>
> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Tuesday, January 15, 2019 6:34 PM
> To: Eads, Gage <gage.eads@intel.com>
> Cc: dev@dpdk.org; olivier.matz@6wind.com; arybchenko@solarflare.com;
> Richardson, Bruce <bruce.richardson@intel.com>; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>
> Subject: Re: [PATCH] doc: announce ring ABI and API changes
>
> On Tue, 15 Jan 2019 17:59:34 -0600
> Gage Eads <gage.eads@intel.com> wrote:
>
> > 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 <gage.eads@intel.com>
> > ---
> > 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 ``uint32_t``
> > + to ``size_t``. This reduces the likelihood of wrap-around to effectively
> > + zero for 64-bit builds, which is important in avoiding the ABA problem 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 can
> > + calculate the memory required for rings that require more than 8B per
> entry
> > + (such as the upcoming non-blocking ring).
>
>
> Would it be possible to support new and old ring types, either through naming
> tricks and/or new ring flag? Changing things like ring buffer and mbuf are
> basically a flag day for all users.
>
> 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 support
> newer networks.
Fair enough -- I appreciate the additional context wrt avoiding churn.
This might be doable with the following change:
"
@@ -70,6 +70,15 @@ struct rte_ring_headtail {
uint32_t single; /**< True if single prod/cons */
};
+/* 64-bit version of rte_ring_headtail, for use by rings that need to avoid
+ * 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 */
/** 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 */
/** 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 both padded out to a full cache line, and the 64-bit version fits within a single cache line. (Confirmed with pahole.)
abi-compliance-checker reports two issues, but both appear to be false positives:
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 by such a change, but I first want to check if the community agrees with this approach. Note that I don't see any way to avoid the API change to rte_ring_get_memsize, but I doubt that would have near the impact of a ring data structure change.
Thanks,
Gage
next prev parent reply other threads:[~2019-01-16 18:21 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-15 23:59 Gage Eads
2019-01-16 0:34 ` Stephen Hemminger
2019-01-16 18:21 ` Eads, Gage [this message]
2019-01-18 15:28 ` [dpdk-dev] [PATCH v2] doc: announce ring API change Gage Eads
2019-01-18 15:31 ` [dpdk-dev] [PATCH v3] " Gage Eads
2019-02-01 11:16 ` Thomas Monjalon
2019-02-01 14:18 ` Eads, Gage
2019-02-01 14:36 ` [dpdk-dev] [PATCH v4] " Gage Eads
2019-05-09 23:29 ` Thomas Monjalon
2019-05-09 23:29 ` Thomas Monjalon
2019-05-10 14:53 ` Eads, Gage
2019-05-10 14:53 ` Eads, Gage
2019-05-10 14:58 ` Stephen Hemminger
2019-05-10 14:58 ` Stephen Hemminger
2019-05-10 15:19 ` Ola Liljedahl
2019-05-10 15:19 ` Ola Liljedahl
2019-05-10 16:28 ` Eads, Gage
2019-05-10 16:28 ` Eads, Gage
2019-05-13 11:46 ` Olivier Matz
2019-05-13 11:46 ` Olivier Matz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9184057F7FC11744A2107296B6B8EB1E541C7C11@FMSMSX108.amr.corp.intel.com \
--to=gage.eads@intel.com \
--cc=arybchenko@solarflare.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=konstantin.ananyev@intel.com \
--cc=olivier.matz@6wind.com \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).