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
next prev parent 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).