Re: [dpdk-dev] [PATCH 0/6] get status of Rx and Tx descriptors

[Olivier Matz <olivier.matz@6wind.com>]

On Thu, 2 Mar 2017 15:32:15 +0000, Bruce Richardson <bruce.richardson@intel.com> wrote:
> On Wed, Mar 01, 2017 at 06:19:06PM +0100, Olivier Matz wrote:
> > This patchset introduces a new ethdev API:
> > - rte_eth_rx_descriptor_status()
> > - rte_eth_tx_descriptor_status()
> > 
> > The Rx API is aims to replace rte_eth_rx_descriptor_done() which
> > does almost the same, but does not differentiate the case of a
> > descriptor used by the driver (not returned to the hw).
> > 
> > The usage of these functions can be:
> > - on Rx, anticipate that the cpu is not fast enough to process
> >   all incoming packets, and take dispositions to solve the
> >   problem (add more cpus, drop specific packets, ...)
> > - on Tx, detect that the link is overloaded, and take dispositions
> >   to solve the problem (notify flow control, drop specific
> >   packets)
> >   
> Looking at it from a slightly higher level, are these APIs really going
> to help in these situations? If something is overloaded, doing more work
> by querying the ring status only makes things worse. I suspect that in
> most cases better results can be got by just looking at the results of
> RX and TX burst functions. For example, if RX burst is always returning
> a full set of packets, chances are you are overloaded, or at least have
> no scope for an unexpected burst or event.
> 
> Are these really needed for real applications? I suspect our trivial
> l3fwd power example can be made to work ok without them.

The l3fwd example uses the rte_eth_rx_descriptor_done() API, which
is very similar to what I'm adding here. The differences are:

- the new lib provides a Tx counterpart
- it differentiates done/avail/hold descriptors

The alternative was to update the descriptor_done API, but
I think we agreed to do that in this thread:
http://www.dpdk.org/ml/archives/dev/2017-January/054947.html

About the usefulness of the API, I confirm it is useful: for
instance, you can detect that you ring is more than half-full, and
take dispositions to increase your processing power or select the
packets you want to drop first.

Regards
Olivier