[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e468bcfa-db2e-7fec-0cad-229561f87cdd@grandegger.com>
Date: Wed, 14 Mar 2018 10:46:26 +0100
From: Wolfgang Grandegger <wg@...ndegger.com>
To: Marc Kleine-Budde <mkl@...gutronix.de>,
Jakob Unterwurzacher <jakob.unterwurzacher@...obroma-systems.com>
Cc: Martin Elshuber <martin.elshuber@...obroma-systems.com>,
Philipp Tomsich <philipp.tomsich@...obroma-systems.com>,
linux-can@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: rx_packets/bytes stats for error frames
Am 14.03.2018 um 10:36 schrieb Marc Kleine-Budde:
> On 03/14/2018 10:09 AM, Jakob Unterwurzacher wrote:
>> On 14.03.18 08:51, Marc Kleine-Budde wrote:
>>>> + memcpy(cf->data, m->msg.can_msg.data, cf->can_dlc);
>>>> +
>>>> + /* don't count error frames as real packets */
>>>> + if (!(canid & CAN_ERR_FLAG)) {
>>>> + stats->rx_packets++;
>>>> + stats->rx_bytes += cf->can_dlc;
>>>> + }
>>> Please count them, too.
>>
>> We do count them, as errors!
>>
>> This is what happens when you transmit a single CAN frame with nothing
>> connected: "TX errors" shoots up but "RX packets" stays zero.
>
> This is handled not consistent in the existing CAN drivers. In flexcan
> all and c_can (all but rx overflow) are counted as rx_packets and
> rx_bytes. (I haven't looked at the other drivers.)
>
> I tend to count the error frames as ordinary frames.
+1, I think we should count the packets and bytes delivered to the
network layer.
Wolfgang.
Powered by blists - more mailing lists