Netdev 2018 day 2

Posted Aug 29, 2018 18:44 UTC (Wed) by mtaht (subscriber, #11087)
In reply to: Netdev 2018 day 2 by mtaht
Parent article: Netdev 2018 day 2

so I went looking...

this can device is noqueue. I don't know what that means, device has a lot of internal buffering?

http://docs.automotivelinux.org/docs/apis_services/en/dev...

this on the other hand might be a problem

https://github.com/lxc/lxc/issues/2474

but this suggests it isn't though a correct fq_codel target setting would be well above 50ms in this case

https://github.com/GBert/openwrt-misc/tree/master/mcp2515...

Netdev 2018 day 2

Posted Aug 29, 2018 18:45 UTC (Wed) by mtaht (subscriber, #11087) [Link] (1 responses)

on the other other hand the mtu on a can bus is 16???

Netdev 2018 day 2

Posted Aug 29, 2018 19:39 UTC (Wed) by mtaht (subscriber, #11087) [Link]

I knew nothing about CAN before 3 hours ago. In particular I retract what I was saying about ecn (that was an IP specific bus). It looks like the FQ part in fq_codel, would "work" if there was a dissector for it. As the MTU is tiny the codelly bit would "work" also at the 5ms default - but (after reading up on it) both FQ and codel seem very dangerous to deploy in a CAN environment as anything other than a test of the robustness of the system. FQ (DRR) could deliver messages de-interleaved to various devices, and the HOL blocking in the media access force drops in codel.

Thanks for pointing this out. For the first time in years I'm led to conclude strict fifo is better in a given system. Not that I don't see CAN has problems, mind you, but they aren't fq_codels domain to solve.

I'll have to write this up somewhere, maybe discuss on the can list.