[dpdk-dev] [PATCH 0/6] get status of Rx and Tx descriptors
Olivier Matz
olivier.matz at 6wind.com
Thu Mar 2 17:14:56 CET 2017
On Thu, 2 Mar 2017 15:32:15 +0000, Bruce Richardson <bruce.richardson at 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
More information about the dev
mailing list