> On Feb 15, 2019, at 8:05 AM, Bruce Richardson <bruce.richard...@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]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.
>
> 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
