DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Mauricio Vásquez" <mauricio.vasquezbernal@studenti.polito.it>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] Ring PMD: why are stats counters atomic?
Date: Mon, 16 May 2016 15:12:10 +0200	[thread overview]
Message-ID: <CAPwdgqgdTpjPsSfwUygbd1wfVat0hhjgd+qDbwr4kUdcCcFcjg@mail.gmail.com> (raw)
In-Reply-To: <20160510093629.GA1508@bricha3-MOBL3>

Hello Bruce,

Although having this support does not harm anyone, I am not convinced that
it is useful, mainly because there exists the single-thread limitation in
other PMDs. Then, if an application has to use different kind of NICs (i.e,
different PMDs) it has to implement the locking strategies. On the other
hand, if an application  only uses rte_rings, it could just use the
rte_ring library.

Thanks, Mauricio V

On Tue, May 10, 2016 at 11:36 AM, Bruce Richardson <
bruce.richardson@intel.com> wrote:

> On Tue, May 10, 2016 at 11:13:08AM +0200, Mauricio Vásquez wrote:
> > Hello,
> >
> > Per-queue stats counters are defined as rte_atomic64_t, in the tx/rx
> > functions, they are atomically increased if the rings have the multiple
> > consumers/producer flag enabled.
> >
> > According to the design principles, the application should not invoke
> those
> > functions on the same queue on different cores, then I think that atomic
> > increasing is not necessary.
> >
> > Is there something wrong with my reasoning?, If not, I am willing to
> send a
> > patch.
> >
> > Thank you very much,
> >
> Since the rte_rings, on which the ring pmd is obviously based, have
> multi-producer
> and multi-consumer support built-in, I thought it might be useful in the
> ring
> PMD itself to allow multiple threads to access the ring queues at the same
> time,
> if the underlying rings are marked as MP/MC safe. When doing enqueues and
> dequeue
> from the ring, the stats are either incremented atomically, or
> non-atomically,
> depending on the underlying queue type.
>
>         const uint16_t nb_rx = (uint16_t)rte_ring_dequeue_burst(r->rng,
>                         ptrs, nb_bufs);
>         if (r->rng->flags & RING_F_SC_DEQ)
>                 r->rx_pkts.cnt += nb_rx;
>         else
>                 rte_atomic64_add(&(r->rx_pkts), nb_rx);
>
> If people don't think this behaviour is worthwhile keeping, I'm ok with
> removing
> it, since all other PMDs have the restriction that the queues are
> single-thread
> only.
>
> Regards,
> /Bruce
>

  reply	other threads:[~2016-05-16 13:12 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-10  9:13 Mauricio Vásquez
2016-05-10  9:36 ` Bruce Richardson
2016-05-16 13:12   ` Mauricio Vásquez [this message]
2016-05-16 13:16     ` Bruce Richardson
2016-08-15 20:41       ` Mauricio Vásquez

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=CAPwdgqgdTpjPsSfwUygbd1wfVat0hhjgd+qDbwr4kUdcCcFcjg@mail.gmail.com \
    --to=mauricio.vasquezbernal@studenti.polito.it \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.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).