From: "Morten Brørup" <mb@smartsharesystems.com>
To: "Konstantin Ananyev" <konstantin.ananyev@huawei.com>,
"Bruce Richardson" <bruce.richardson@intel.com>
Cc: <honnappa.nagarahalli@arm.com>, <konstantin.v.ananyev@yandex.ru>,
<jerinj@marvell.com>, <dev@dpdk.org>, <olivier.matz@6wind.com>
Subject: RE: Bug in non-power-of-2 rings?
Date: Mon, 21 Aug 2023 11:36:13 +0200 [thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D87B23@smartserver.smartshare.dk> (raw)
In-Reply-To: <f036ba2cef9d43a8aab75733469d2d41@huawei.com>
+CC Olivier, referring to your review of the original patch.
> From: Konstantin Ananyev [mailto:konstantin.ananyev@huawei.com]
> Sent: Monday, 21 August 2023 11.29
>
> Hi everyone,
>
> > On Sun, Aug 20, 2023 at 11:07:33AM +0200, Morten Brørup wrote:
> > > Bruce, Honnappa, Konstantin,
> > >
> > > Back in 2017, Bruce added support for non-power-of-2 rings with this
> patch [1].
> > >
> > > [1]:
> https://git.dpdk.org/dpdk/commit/lib/librte_ring/rte_ring.h?id=b74461155
> 543430f5253e96ad6d413ebcad36693
> > >
> > > I think that the calculation of "entries" in
> __rte_ring_move_cons_head() [2][3] is incorrect when the ring capacity
> is not power-of-2,
> > because it is missing the capacity comparison you added to
> rte_ring_count() [4]. Please review if I'm mistaken.
> > >
> > > [2]:
> https://elixir.bootlin.com/dpdk/v23.07/source/lib/ring/rte_ring_c11_pvt.
> h#L159
> > > [3]:
> https://elixir.bootlin.com/dpdk/v23.07/source/lib/ring/rte_ring_generic_
> pvt.h#L150
> > > [4]:
> https://elixir.bootlin.com/dpdk/v23.07/source/lib/ring/rte_ring.h#L502
>
> Just to confirm you suggest something like that:
> - *entries = (r->prod.tail - *old_head);
> + count = (r->prod.tail - *old_head);
> + entries = (count > r->capacity) ? r->capacity : count;
> right?
Yes, since rte_ring_count() does it, it might be required here too.
>
> > >
> > thanks for flagging this inconsistency, but I think we are ok.
> >
> > For consumer, I think this is correct, because we are only ever
> reducing
> > the number of entries in the ring, and the calculation of the number
> of
> > entries is made in the usual way using modulo arithmetic. We should
> never
> > have more than capacity entries in the ring so the check in ring count
> I
> > believe is superflous. [The exception would be if someone bypassed the
> > inline functions and accessed the ring directly themselves - at which
> point
> > "all bets are off", to use the English phrase]
I have now found the comments to the original patch [5]. It seems that Olivier flagged this as a risk for rte_ring_free_count(), which reads r->prod.tail and r->cons.tail without synchronization.
However, since __rte_ring_move_cons_head() uses synchronization, I guess that such a risk is not present here.
[5]: https://patchwork.dpdk.org/project/dpdk/patch/20170607133620.275801-2-bruce.richardson@intel.com/
> >
> > The producer code (__rte_ring_move_prod_head) does do a capacity
> check,
> > which is where one is required to ensure we never exceed capacity.
Agreed. Thanks for double checking.
>
> I also can't come up with the case, when current code will cause an
> issue..
> In properly operating ring, I think we should never have more then r-
> >capacity
> entries populated, so this extra check can be skipped.
> Unless you do have some particular case in mind?
No special case in mind. Just stumbled over this code looking different than similar code in rte_ring_free_count().
prev parent reply other threads:[~2023-08-21 9:36 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-20 9:07 Morten Brørup
2023-08-21 8:39 ` Bruce Richardson
2023-08-21 9:29 ` Konstantin Ananyev
2023-08-21 9:36 ` Morten Brørup [this message]
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=98CBD80474FA8B44BF855DF32C47DC35D87B23@smartserver.smartshare.dk \
--to=mb@smartsharesystems.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=honnappa.nagarahalli@arm.com \
--cc=jerinj@marvell.com \
--cc=konstantin.ananyev@huawei.com \
--cc=konstantin.v.ananyev@yandex.ru \
--cc=olivier.matz@6wind.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 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).