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


Reply via email to