On Fri, Feb 15, 2019 at 9:58 AM Thomas Monjalon <tho...@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