fq_codel on can issues

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I was just made aware of https://marc.info/?l=linux-can&m=152785826628439&w=2

Obviously I'm biased towards fixing bufferbloat, and at the same time
not breaking CAN under any circumstance is also important.

I wanted to note first that all qdiscs (and various other parts of the
linux network subsystem) can drop packets. pfifo_fast will drop
packets when the txqueuelen is exceeded. I am curious if this test
will drop packets if you try to slam 1000+ packets in there?

CAN drivers should specify their requisite qdisc - noqueue is a good
choice if you are handling all the needed buffering yourself. The
default qdisc does not
apply over that.

I do not know how widespread this problem is (in scanning the web I
see noqueue in several CAN examples, a short txqueuelen in others, an
overlarge (for can) MTU in others)

I will go poke into the
"PEAK USB CAN" driver and this portion of the stack this week.

there's now a systemd bug:

https://github.com/systemd/systemd/issues/9194

and an openwrt bug (they don't even ship pfifo_fast anymore!)

https://bugs.openwrt.org/index.php?do=details&task_id=1759&string=CAN&type%5B0%5D=&sev%5B0%5D=&pri%5B0%5D=&due%5B0%5D=&reported%5B0%5D=&cat%5B0%5D=&status%5B0%5D=open&percent%5B0%5D=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto=

-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619




[Index of Archives]     [Automotive Discussions]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [CAN Bus]

  Powered by Linux