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

[David Marchand]

On Fri, Feb 15, 2019 at 9:58 AM Thomas Monjalon <thomas at monjalon.net> wrote:

> 14/02/2019 19:51, David Marchand:
> > What is the purpose of oerrors ?
> >
> > Since the drivers (via rte_eth_tx_burst return value) report the numbers
> of
> > packets successfully transmitted, the application can try to retransmit
> the
> > packets that did not make it and counts this.
> > If the driver counts such "missed" packets, then it does the job the
> > application will do anyway (wasting some cycles).
> > But what is more a problem is that the application does not know if the
> > packets in oerrors are its own retries or problems that the driver can
> not
> > detect (hw problems) but the hw can.
> >
> > So the best option is that oerrors does not report the packets the driver
> > refuses (and I can see some drivers that do not comply to this) but only
> > "external" errors from the driver pov.
>
> I can see the benefit of having driver errors in the stats,
> so it is generically stored for later analysis or print.
> It could be managed at ethdev level instead of the application
> doing the computation.
>
> What about splitting the Tx errors in 2 fields? oerrors / ofull ?
> Who said it's awful? sorry Bruce for anticipating ;)
>

Summary, correct me if we are not aligned :-)

- ofull (maybe ofifoerrors?) is actually a count of SW failed transmits
- it would be handled in rte_eth_tx_burst() itself in a generic way
- the drivers do not need to track such SW failed transmits
- oerrors only counts packets HW failed transmits, dropped out of the
driver tx_pkt_burst() knowledge
- the application does not have to track SW failed transmits since the
stats is in ethdev

It sounds good to me, this means an ethdev abi breakage.

I will drop my current patch anyway.
Touching oerrors would be a separate effort.


-- 
David Marchand