DPDK patches and discussions
 help / color / mirror / Atom feed
From: Neil Horman <nhorman@tuxdriver.com>
To: "Venkatesan, Venky" <venky.venkatesan@intel.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] Bulk dequeue of packets and the returned values, question
Date: Sun, 28 Sep 2014 18:36:08 -0400	[thread overview]
Message-ID: <20140928223607.GA4810@localhost.localdomain> (raw)
In-Reply-To: <54288A70.9020902@intel.com>

On Sun, Sep 28, 2014 at 03:23:44PM -0700, Venkatesan, Venky wrote:
> Keith,
> 
> On 9/28/2014 11:04 AM, Wiles, Roger Keith wrote:
> >I am also looking at the bulk dequeue routines, which the ring can be fixed or variable. On fixed  < 0 on error is returned and 0 if successful. On a variable ring < 0 on error or n on success, but I think n can be zero in the variable case, correct?
> >
> >If these are true then why not have the routines return  < 0 on error and >= 0 on success. Which means a dequeue from a fixed ring would return only ’requested size n’ or < 0 if you error off the 0 case. The 0 case could be OK, if you allow zero to be return on a empty ring for the fixed ring case.
> >
> >Does this make sense to anyone?
> It won't make sense unless you're aware of the history behind these
> functions. The original functions that were implemented for the ring were
> only the bulk functions (i.e. FIXED). They would return exactly the number
> of items requested for dequeue (0 if success, negative if error), and not
> return any if the required number were not available.
> 
> The burst (i.e. VARIABLE) functions came in much later (think it was r1.3
> where we introduced them), and by that time, there were already quite a
> number of deployments of DPDK in the field using the legacy ring functions.
> Therefore we made the decision to keep the legacy behavior intact & not
> impacting deployed code - and merging the burst functions into the code.
> Given that there was no "versioning" of the API/ABI in those releases :).
> 
Hehe :)

Yes, API versioning would be a great benefit to this sort of problem.  If only
there were a patchset available to create that ability ;)

Neil

  reply	other threads:[~2014-09-28 22:29 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-28 18:04 Wiles, Roger Keith
2014-09-28 20:44 ` Neil Horman
2014-09-28 22:23 ` Venkatesan, Venky
2014-09-28 22:36   ` Neil Horman [this message]
2014-09-28 23:06   ` Wiles, Roger Keith
2014-09-29 12:10     ` Bruce Richardson
2014-09-29 12:26       ` Neil Horman
2014-09-29 12:30       ` Ananyev, Konstantin
2014-09-29 14:57         ` Wiles, Roger Keith

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=20140928223607.GA4810@localhost.localdomain \
    --to=nhorman@tuxdriver.com \
    --cc=dev@dpdk.org \
    --cc=venky.venkatesan@intel.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).