Re: [dpdk-dev] [PATCH 3/5] app/testpmd: add missing transmit errors stats

[Stephen Hemminger <stephen@networkplumber.org>]

On Fri, 15 Feb 2019 20:38:59 +0100
Thomas Monjalon <thomas@monjalon.net> wrote:

> 15/02/2019 19:42, Ananyev, Konstantin:
> > >>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of David Marchand
> > >>> I am also for option 2 especially because of this.
> > >>> A driver that refuses a packet for reason X (which is a limitation, or an
> > >>> incorrect config or whatever that is not a transient condition) but gives
> > >>> it back to the application is a bad driver.  
> >   
> > >>Why? What.s wrong to leave it to the upper layer to decide what to
> > >>do with the packets that can't be sent (by one reason or another)?  
> >   
> > >How does the upper layer know if this is a transient state or something that can't be resolved?  
> > 
> > Via rte_errno, for example.  
> 
> rte_errno is not a result per packet.
> I think it is better to "eat" the packet
> as it is done for those transmitted to the HW.
> 
> 

First off rte_errno doesn't work for a burst API.

IMHO (which matches /2) all drivers should only increment oerrors for something for
a packet which it could not transmit because of hardware condition (link down etc)
or mbuf which has parameters which can not be handled. In either case, the packet
must be dropped by driver and oerrors incremented.  The driver should also maintain
internal stats (available by xstats) for any conditions like this.

When no tx descriptors are available, the driver must not increment any counter
and return partial success to the application. If application then wants to do
back pressure or drop it should keep its own statistics.

This is close to the original model in the Intel drivers, and matches what BSD and
Linux do on the OS level for drivers. Like many driver assumptions the corner
cases were not explicitly documented and new drivers probably don't follow
the same pattern.