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

[Ananyev, Konstantin]

> 
> On Fri, 15 Feb 2019 20:38:59 +0100
> Thomas Monjalon <thomas at monjalon.net> wrote:
> 
> > 15/02/2019 19:42, Ananyev, Konstantin:
> > > >>> From: dev [mailto:dev-bounces at 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.

It doesn't allow to return individual error value for each packet.
Though if we stop after first error happens - it is sufficient.

> 
> 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)

It sounds too expensive to check that HW is in healthy state and link is up for every tx_burst
operation. 

> or mbuf which has parameters which can not be handled.

Right now it is responsibility of different function - tx_prepare().

> In either case, the packet
> must be dropped by driver and oerrors incremented.  

Right now tx_burst() only cares - is there enough free TX descriptors to submit packet or not.
>From my perspective - it is better to keep it that way.
If the user would like to drop packets if the link is down,
or if the packet is malformed -  there should be no problem to create a wrapper on
top of tx_burst() that would do all these extra checking and packet freeing.

>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.