| Message ID | 20211123115333.624335-1-mailhol.vincent@wanadoo.fr (mailing list archive) |
|---|---|
| Headers | show |
| Series | fix statistics for CAN RTR and Error frames | expand |
On 23.11.21 12:53, Vincent Mailhol wrote: > There are two common errors which are made when reporting the CAN RX > statistics: > > 1. Incrementing the "normal" RX stats when receiving an Error > frame. Error frames is an abstraction of Socket CAN and does not > exist on the wire. > > 2. Counting the length of the Remote Transmission Frames (RTR). The > length of an RTR frame is the length of the requested frame not the > actual payload. In reality the payload of an RTR frame is always 0 > bytes long. > > This patch series fix those two issues for all CAN drivers. > > Vincent Mailhol (2): > can: do not increase rx statistics when receiving CAN error frames > can: do not increase rx_bytes statistics for RTR frames I would suggest to upstream this change without bringing it to older (stable) trees. It doesn't fix any substantial flaw which needs to be backported IMHO. Btw. can you please change 'error frames' to 'error message frames'? We had a discussion some years ago that the 'error frames' are used as term inside the CAN protocol. Thanks, Oliver > > drivers/net/can/at91_can.c | 9 ++------- > drivers/net/can/c_can/c_can_main.c | 8 ++------ > drivers/net/can/cc770/cc770.c | 6 ++---- > drivers/net/can/dev/dev.c | 4 ---- > drivers/net/can/dev/rx-offload.c | 7 +++++-- > drivers/net/can/grcan.c | 3 ++- > drivers/net/can/ifi_canfd/ifi_canfd.c | 8 ++------ > drivers/net/can/janz-ican3.c | 3 ++- > drivers/net/can/kvaser_pciefd.c | 8 ++------ > drivers/net/can/m_can/m_can.c | 10 ++-------- > drivers/net/can/mscan/mscan.c | 10 ++++++---- > drivers/net/can/pch_can.c | 6 ++---- > drivers/net/can/peak_canfd/peak_canfd.c | 7 ++----- > drivers/net/can/rcar/rcar_can.c | 9 +++------ > drivers/net/can/rcar/rcar_canfd.c | 7 ++----- > drivers/net/can/sja1000/sja1000.c | 5 ++--- > drivers/net/can/slcan.c | 3 ++- > drivers/net/can/spi/hi311x.c | 3 ++- > drivers/net/can/spi/mcp251x.c | 3 ++- > drivers/net/can/sun4i_can.c | 10 ++++------ > drivers/net/can/usb/ems_usb.c | 5 ++--- > drivers/net/can/usb/esd_usb2.c | 5 ++--- > drivers/net/can/usb/etas_es58x/es58x_core.c | 7 ------- > .../net/can/usb/kvaser_usb/kvaser_usb_core.c | 2 -- > .../net/can/usb/kvaser_usb/kvaser_usb_hydra.c | 14 ++++---------- > .../net/can/usb/kvaser_usb/kvaser_usb_leaf.c | 7 ++----- > drivers/net/can/usb/mcba_usb.c | 3 ++- > drivers/net/can/usb/peak_usb/pcan_usb.c | 5 ++--- > drivers/net/can/usb/peak_usb/pcan_usb_fd.c | 11 ++++------- > drivers/net/can/usb/peak_usb/pcan_usb_pro.c | 11 +++++------ > drivers/net/can/usb/ucan.c | 7 +++++-- > drivers/net/can/usb/usb_8dev.c | 10 ++++------ > drivers/net/can/xilinx_can.c | 17 ++++++----------- > 33 files changed, 86 insertions(+), 147 deletions(-) >
On Wed. 24 Nov. 2021 at 06:10, Oliver Hartkopp <socketcan@hartkopp.net> wrote: > On 23.11.21 12:53, Vincent Mailhol wrote: > > There are two common errors which are made when reporting the CAN RX > > statistics: > > > > 1. Incrementing the "normal" RX stats when receiving an Error > > frame. Error frames is an abstraction of Socket CAN and does not > > exist on the wire. > > > > 2. Counting the length of the Remote Transmission Frames (RTR). The > > length of an RTR frame is the length of the requested frame not the > > actual payload. In reality the payload of an RTR frame is always 0 > > bytes long. > > > > This patch series fix those two issues for all CAN drivers. > > > > Vincent Mailhol (2): > > can: do not increase rx statistics when receiving CAN error frames > > can: do not increase rx_bytes statistics for RTR frames > > I would suggest to upstream this change without bringing it to older > (stable) trees. > > It doesn't fix any substantial flaw which needs to be backported IMHO. I fully agree. Bringing it to the stable trees would be a considerable effort and was not my intent either (thus the absence of "Fixes" tags). > Btw. can you please change 'error frames' to 'error message frames'? > > We had a discussion some years ago that the 'error frames' are used as > term inside the CAN protocol. ACK. Thanks for the clarification on the vocabulary. Yours sincerely, Vincent Mailhol