Netdev 2018 day 2 [LWN.net]

Netdev 2018 day 2

Posted Aug 29, 2018 20:03 UTC (Wed) by Cyberax (✭ supporter ✭, #52523)
In reply to: Netdev 2018 day 2 by mtaht
Parent article: Netdev 2018 day 2

CAN devices typically are not designed to tolerate dropped packets. It's also not easy to do complicated stuff when your whole payload is 8 bytes.

Typically people just over-provision CAN networks so there's almost no contention.

to post comments

Netdev 2018 day 2

Posted Aug 29, 2018 20:29 UTC (Wed) by mtaht (guest, #11087) [Link] (2 responses)

I do my best work when frightened! I now think the best option for can devices is noqueue, and I can imagine quite a few that relied on pfifo_fast as the default suddenly breaking with any other qdisc.

Netdev 2018 day 2

Posted Aug 29, 2018 20:57 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

Noqueue might be a bit too aggressive, you don't want to drop a packet if the bus happens to be busy at the moment of transmission, pfifo_fast sounds about right.

Netdev 2018 day 2

Posted Aug 29, 2018 21:28 UTC (Wed) by mtaht (guest, #11087) [Link]

Well... my assumption would be the device driver is buffering up one or two packets... based on that whopping 3 hours of experience and googling. :)

default pfifo_fast would be buffering up 1000, which strikes me as a bit much. I did see (I think) something that set txqueuelen to 10.

I'm (sigh) going to have to go look at every "packet" interface in linux now...