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

[Wiles, Keith]

> On Feb 15, 2019, at 8:05 AM, Bruce Richardson <bruce.richardson at intel.com> wrote:
> 
> On Fri, Feb 15, 2019 at 10:33:47AM +0100, David Marchand wrote:
>>   On Fri, Feb 15, 2019 at 9:58 AM Thomas Monjalon
>>   <[1]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.
> 
> Hang on, why do we need ethdev to track this at all, given that it's
> trivial for apps to track this themselves. Would we not be better just to
> add this tracking into testpmd and leave ethdev and drivers alone? Perhaps
> I'm missing something?

Adding the counters to ethdev stats is a good idea to me, the number of tx full failures is a great counter as it can tell you a lot about performance of the application. if the ofull counter is high then we have a lot of re-xmit attempts which can point to the problem quicker IMO. Adding it to the PMDs is the right place for this type of information as it is a very common needed counter.
> 

Regards,
Keith