All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Eads, Gage" <gage.eads@intel.com>
To: Ola Liljedahl <Ola.Liljedahl@arm.com>,
	Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>,
	"Richardson, Bruce" <bruce.richardson@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Cc: nd <nd@arm.com>
Subject: Re: [dpdk-dev] [RFC,v2] lfring: lock-free ring buffer
Date: Tue, 18 Jun 2019 17:06:35 +0000	[thread overview]
Message-ID: <9184057F7FC11744A2107296B6B8EB1E68CFBA4C@FMSMSX108.amr.corp.intel.com> (raw)
In-Reply-To: <f5223d64b70733ffd56869b8c8e140776bcfea81.camel@arm.com>



> -----Original Message-----
> From: Ola Liljedahl [mailto:Ola.Liljedahl@arm.com]
> Sent: Saturday, June 15, 2019 4:00 PM
> To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>; Richardson,
> Bruce <bruce.richardson@intel.com>; Eads, Gage <gage.eads@intel.com>;
> dev@dpdk.org
> Cc: nd <nd@arm.com>
> Subject: Re: [RFC,v2] lfring: lock-free ring buffer
> 
> On Wed, 2019-06-05 at 18:21 +0000, Eads, Gage wrote:
> > Hi Ola,
> >
> > Is it possible to add burst enqueue and dequeue functions as well, so
> > we can plug this into a mempool handler?
> Proper burst enqueue is difficult or at least not very efficient.
> 
> >  Besides the mempool handler, I think the all-or-nothing semantics
> > would be useful for applications. Besides that, this RFC looks good at a high
> level.
> >
> > For a complete submission, a few more changes are needed:
> > - Builds: Need to add 'lfring' to lib/meson.build and mk/rte.app.mk
> > - Documentation: need to update release notes, add a new section in
> > the programmer's guide, and update the doxygen configuration files
> > - Tests: This patchset should add a set of lfring tests as well
> >
> > Code comments follow.
> Thanks for the review comments, I only had time to look at a few of them. I
> will return with more complete answers and a new version of the patch.
> 

Sounds good.

<snip>

> > +/* search a ring from its name */
> > +struct rte_lfring *
> > +rte_lfring_lookup(const char *name)
> > +{
> > +	struct rte_tailq_entry *te;
> > +	struct rte_lfring *r = NULL;
> > +	struct rte_lfring_list *ring_list;
> > +
> > +	ring_list = RTE_TAILQ_CAST(rte_lfring_tailq.head, rte_lfring_list);
> > +
> > +	rte_rwlock_read_lock(RTE_EAL_TAILQ_RWLOCK);
> > +
> > +	TAILQ_FOREACH(te, ring_list, next) {
> > +		r = (struct rte_lfring *) te->data;
> > +		if (strncmp(name, r->name, RTE_LFRING_NAMESIZE) == 0)
> >
> > Missing a NULL pointer check before dereferencing 'name'
> Why shouldn't the program crash if someone passes a NULL pointer
> parameter?
> Callers will be internal, external users should be able to control whether
> NULL is passed instead of a valid pointer.
> A crash and a core dump is the best way to detect and debug errors.

If you think crashing is the appropriate response, rte_panic() with a descriptive error string would be better than a segfault alone.

<snip>

> > +/**
> > + * Return the number of elements which can be stored in the lfring.
> > + *
> > + * @param r
> > + *   A pointer to the lfring structure.
> > + * @return
> > + *   The usable size of the lfring.
> > + */
> > +static inline unsigned int
> > +rte_lfring_get_capacity(const struct rte_lfring *r) {
> > +	return r->size;
> >
> > I believe this should return r->mask, to account for the one unusable
> > ring entry.
> 
> I think this is a mistake, all ring entries should be usable.

Ok, then do these comments from elsewhere in the header need to be corrected?

"The real usable lfring size is *count-1* instead of *count* to differentiate a free lfring from an empty lfring."

  reply	other threads:[~2019-06-18 17:06 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-30 16:36 [RFC,v2] lfring: lock-free ring buffer Ola Liljedahl
2019-06-05 18:21 ` [dpdk-dev] " Eads, Gage
2019-06-15 21:00   ` Ola Liljedahl
2019-06-18 17:06     ` Eads, Gage [this message]
2023-06-09 17:10 ` Stephen Hemminger

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=9184057F7FC11744A2107296B6B8EB1E68CFBA4C@FMSMSX108.amr.corp.intel.com \
    --to=gage.eads@intel.com \
    --cc=Honnappa.Nagarahalli@arm.com \
    --cc=Ola.Liljedahl@arm.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=nd@arm.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.