[dpdk-dev] [PATCH] ethdev: rte_eth_rx_burst()nb_pktsrequirements

[Thomas Monjalon]

14/10/2020 10:26, Morten Brørup:
> From: Ferruh Yigit
> > On 9/14/2020 1:42 PM, Morten Brørup wrote:
> > > From: Bruce Richardson
> > >> On Mon, Sep 14, 2020 at 01:05:11PM +0200, Morten Brørup wrote:
> > >>> Updated description of rte_eth_rx_burst() to reflect what drivers,
> > >>> when using vector instructions, expect from nb_pkts.
> > >>>
> > >>> Also discussed on the mailing list here:
> > >>>
> > >> http://inbox.dpdk.org/dev/98CBD80474FA8B44BF855DF32C47DC35C61257@smarts
> > >> erver.smartshare.dk/
> > >>>
> > >>> --- a/lib/librte_ethdev/rte_ethdev.h
> > >>> +++ b/lib/librte_ethdev/rte_ethdev.h
> > >>> @@ -4469,6 +4469,10 @@ int
> > >> rte_eth_dev_hairpin_capability_get(uint16_t port_id,
> > >>>    * burst-oriented optimizations in both synchronous and asynchronous
> > >>>    * packet processing environments with no overhead in both cases.
> > >>>    *
> > >>> + * @note
> > >>> + *   Some drivers using vector instructions require that *nb_pkts*
> > >> is
> > >>> + *   divisible by 4 or 8, depending on the driver implementation.
> > >>> + *
> > >>
> > >> Not technically true, in that the drivers will round the value down to
> > >> the
> > >> nearest multiple of 4 or 8. So how about rewording as:
> > >>
> > >> "Some drivers using vector instructions may round the *nb_pkts* driver
> > >> to
> > >> a multiple of 4 or 8 depending upon the driver implementation."
> > >>
> > >
> > > You are correct about the driver behavior.
> > >
> > > However, if you pass nb_pkts=9, the driver will return 8 packets,
> > > and thus it does not conform to the API behavior of returning nb_pkts
> > > if they are there.
> > >
> > > This is why the description in this patch differs from the description we
> > reached in the RFC discussion.
> > >
> > 
> > Hi Morten, Bruce,
> > 
> > +1 to document the this behavior.
> > 
> > But in the patch the wording is more strict:
> > "... require that *nb_pkts* is divisible by 4 or 8 ..."
> > "... The value must be divisible by 8 in order to work with any driver."
> > 
> > I am not sure the requirement is that strict. Application still provide any
> > value for 'nb_pkts', so the value doesn't "have to" be divisible 8/4.
> > 
> > But for vector PMD case it will return number of packets round down to 8/4.
> > Perhaps can add for vector PMD it must be at least 4/8?
> > 
> > Bruce's explanation sound more accurate to me, what do you think?
> > 
> 
> I aim to keep the explanation in the documentation relatively simple. Keep the parameter description short, and add the details about vector driver behavior as a note to the function.
> 
> The reason for all this is the existing documentation describing how to use the rte_eth_rx_burst() function at high level:
> 
> The rte_eth_rx_burst() function returns the number of packets actually retrieved [...]. A return value equal to nb_pkts indicates [...] that other received packets remain in the input queue. Applications implementing a "retrieve as much received packets as possible" policy can check this specific case and keep invoking the rte_eth_rx_burst() function until a value less than nb_pkts is returned.
> 
> As an alternative to my proposed solution, we could add that vector drivers round down to 4 or 8, and the application's comparison of the nb_pkts and return value must consider this. But that would make the above description strangely complex, rather than just requiring that nb_pkts for vector drivers must be divisible by 4 or 8.
> 
> And as a minor detail, keeping my proposed restriction would also eliminate the vector drivers' need to round down.
> 
> I don't see a need to be able to call rte_eth_rx_burst() with a value not divisible by 4 or 8 for a vector driver, so my proposed restriction is a tradeoff favoring simplicity over unnecessary flexibility.

It makes sense to me.