All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Kleine-Budde <mkl@pengutronix.de>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: Jiri Pirko <jiri@resnulli.us>,
	netdev@vger.kernel.org, Dave Taht <dave.taht@gmail.com>,
	Jamal Hadi Salim <jhs@mojatatu.com>,
	kernel@pengutronix.de, Cong Wang <xiyou.wangcong@gmail.com>,
	linux-can@vger.kernel.org, davem@davemloft.net
Subject: Re: [RFC] net: sch_generic: fq_codel vs pfifo_fast
Date: Wed, 27 Mar 2019 20:24:13 +0100	[thread overview]
Message-ID: <0edf15df-b607-70f7-5fe8-2860eb663a53@pengutronix.de> (raw)
In-Reply-To: <20190327113059.6b1224ab@shemminger-XPS-13-9360>


[-- Attachment #1.1: Type: text/plain, Size: 1772 bytes --]

On 3/27/19 7:30 PM, Stephen Hemminger wrote:
>> on CAN networking hardware we (the CAN community) experience a lot silent,
>> unwanted frame drops inside the kernel. (See first patch for details.) So
>> here's a patch series to keep pfifo_fast as default scheduler for CAN hardware
>> by default.
> 
> Why do you set fq_codel as default qdisc if you know it doesn't work right for your
> environment. Is this a distro's want one value problem?

This is a many fold problem.

- Consider a random Linux developer attaching one of the mainline
supported USB-CAN adapters to his/her development laptop and doing some
random CAN test. As far a I heard all modern Linux distributions (but
not debian) enable fq_codel per kernel .config or via systemd. The user
will experiences dropped CAN frames on the first 1000 packages. This is
not a good user experience.

- From the user space point of view the sysctl net.core.default_qdisc
behaves a bit strange. Why can I enable a queuing discipline by default
that's known not to work on CAN devices. You might think the kernel
(should) know that CAN devices best work with pfifo_fast (or not
NET_SCHED at all).

- Addressing your question directly: Mixed environment. fq_codel works
great on Ethernet, but terrible on CAN. Of course I an use "tc" to
configure the way I want to. But from my point of view it would be nice,
if the kernel uses sane default...and handles the net.core.default_qdisc
default in a sane way.

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2019-03-27 19:24 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-27 16:56 [RFC] net: sch_generic: fq_codel vs pfifo_fast Marc Kleine-Budde
2019-03-27 16:56 ` [PATCH 1/2] net: sch_generic: add flag IFF_FIFO_QUEUE to use pfifo_fast as default scheduler Marc Kleine-Budde
2019-03-27 17:14   ` Cong Wang
2019-03-27 20:11     ` Marc Kleine-Budde
2019-03-27 20:53       ` Cong Wang
2019-04-02 17:22       ` Toke Høiland-Jørgensen
2019-03-27 18:53   ` Uwe Kleine-König
2019-03-27 19:27     ` Marc Kleine-Budde
2019-03-27 16:56 ` [PATCH 2/2] can: dev: let all CAN devices " Marc Kleine-Budde
2019-03-27 18:30 ` [RFC] net: sch_generic: fq_codel vs pfifo_fast Stephen Hemminger
2019-03-27 19:24   ` Marc Kleine-Budde [this message]
2019-10-22 12:47 ` [PATCH] net: sch_generic: Use pfifo_fast as fallback scheduler for CAN hardware Vincent Prince
2019-10-22 12:58   ` Marc Kleine-Budde
2019-10-22 13:23 ` [PATCH v2] " Vincent Prince
2019-10-22 14:53   ` Marc Kleine-Budde
2019-10-22 14:55     ` Marc Kleine-Budde
2019-10-22 16:42     ` Stephen Hemminger
2019-10-22 16:48       ` Marc Kleine-Budde
2019-10-22 17:28       ` Eric Dumazet
2019-10-22 18:21         ` Oliver Hartkopp
2019-10-22 15:09 ` [PATCH v3] " Vincent Prince
2019-10-23 10:52 ` [PATCH v4] " Vincent Prince
2019-10-23 11:13   ` Dave Taht
2019-10-23 13:44 ` [PATCH v5] " Vincent Prince
2019-10-26  2:20   ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0edf15df-b607-70f7-5fe8-2860eb663a53@pengutronix.de \
    --to=mkl@pengutronix.de \
    --cc=dave.taht@gmail.com \
    --cc=davem@davemloft.net \
    --cc=jhs@mojatatu.com \
    --cc=jiri@resnulli.us \
    --cc=kernel@pengutronix.de \
    --cc=linux-can@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=stephen@networkplumber.org \
    --cc=xiyou.wangcong@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.