Hi Kurt,
On 02/21/2011 09:19 AM, Kurt Van Dijck wrote:
> On Fri, Feb 18, 2011 at 05:23:38PM +0100, Wolfgang Grandegger wrote:
>>>> I want to drop incrementing the netdev stats errors. The CAN stats
>>>> should be kept, of course. Currently, we increment both stats for bus
>>>> errors, e.g.:
> I would prefer to keep netdev stats (as generic as possible), and only keep
> in CAN stats what is really different from ethernet.
>>
>> First, not all bus errors are associated with rx:
>>
>> ACK errors may happen on TX
>> CRC errors may happen on RX
>> BIT errors may happen on RX *and* TX
>> FORM errors may happen on RX *and* TX
>>
> [...]
>> Any better idea?
> I would agree most of the above.
> However, I differentiate 2 situations:
> 1)
>>>> can_stats->bus_errors++;
>>>> stats->rx_errors++;
>
> I believe these 2 structs have overlapping semantics, in the way that
> some bus_errors are rx_errors, but not all (as Wolfgang explained).
Yes, of course. If you look how most kernel drives handle RX errors you
will realized that "rx_errors" is the *sum* of the individual errors.
Anyway, the main reason why we may want to keep "rx_errors" is to make
the user aware of those, especially when he is looking to the output of
ifconfig.
> This can be addressed by eliminating overlapping struct members.
>
> I did a quick cross-comparison:
> My proposal would be:
> a) replace can_stats->arbitration_lost with stats->collisions
> b) drop can_stats->bus_errors, use appropriate stats->XXX like
> stats->tx_aborted_errors
> stats->tx_carrier_errors
> stats->rx_crc_errors
> stats->rx_frame_errors
Please *no* magic mappings. That will really confuse users. Only
rx_crc_errors and rx_over_errors could be used for the CAN stats.
> c) keep can_stats->{error_warning,error_passive,bus_off,restarts}.
> I don't think an ethernet equivalent for these exists.
>
> 2)
>> stats->rx_over_errors++;
>> stats->rx_errors++;
>
> This looks to me as bad interpretation of the netdev stats. Probably happened
> to me too.
Why, see my comment above.
Wolfgang.
_______________________________________________
Socketcan-core mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-core
