From: Olivier Matz <olivier.matz@6wind.com>
To: "Morten Brørup" <mb@smartsharesystems.com>
Cc: dev@dpdk.org, "Ananyev,
Konstantin" <konstantin.ananyev@intel.com>,
Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
Subject: Re: [dpdk-dev] [RFC] ring: count and empty optimizations
Date: Wed, 29 Apr 2020 15:38:37 +0200 [thread overview]
Message-ID: <20200429133837.GY6327@platinum> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C60F96@smartserver.smartshare.dk>
Hi Morten,
On Tue, Apr 28, 2020 at 03:53:15PM +0200, Morten Brørup wrote:
> Olivier (maintainer of the Ring),
I'm not anymore, CC'ing Konstantin and Honnappa.
> I would like to suggest a couple of minor optimizations to the ring library.
>
>
> 1. Testing if the ring is empty is as simple as comparing the producer and consumer pointers:
>
> static inline int
> rte_ring_empty(const struct rte_ring *r)
> {
> - return rte_ring_count(r) == 0;
> + uint32_t prod_tail = r->prod.tail;
> + uint32_t cons_tail = r->cons.tail;
> + return cons_tail == prod_tail;
> }
>
> In theory, this optimization reduces the number of potential cache misses from 3 to 2 by not having to read r->mask in rte_ring_count().
This one looks correct to me.
> 2. It is not possible to enqueue more elements than the capacity of a ring, so the count function does not need to test if the capacity is exceeded:
>
> static inline unsigned
> rte_ring_count(const struct rte_ring *r)
> {
> uint32_t prod_tail = r->prod.tail;
> uint32_t cons_tail = r->cons.tail;
> uint32_t count = (prod_tail - cons_tail) & r->mask;
> - return (count > r->capacity) ? r->capacity : count;
> + return count;
> }
>
> I cannot even come up with a race condition in this function where the count would exceed the capacity. Maybe I missed something?
Since there is no memory barrier, the order in which prod_tail and
cons_tail are fetched is not guaranteed. Or the thread could be
interrupted by the kernel in between.
This function may probably return invalid results in MC/MP cases.
We just ensure that the result is between 0 and r->capacity.
next prev parent reply other threads:[~2020-04-29 13:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-28 13:53 [dpdk-dev] [RFC] ring: count and empty optimizations Morten Brørup
2020-04-29 13:38 ` Olivier Matz [this message]
2020-04-30 1:12 ` Honnappa Nagarahalli
2020-04-30 9:19 ` Morten Brørup
2020-04-30 15:36 ` Ananyev, Konstantin
2020-04-30 21:38 ` Honnappa Nagarahalli
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=20200429133837.GY6327@platinum \
--to=olivier.matz@6wind.com \
--cc=dev@dpdk.org \
--cc=honnappa.nagarahalli@arm.com \
--cc=konstantin.ananyev@intel.com \
--cc=mb@smartsharesystems.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.