From: Marc Kleine-Budde <mkl@pengutronix.de>
To: netdev@vger.kernel.org
Cc: davem@davemloft.net, linux-can@vger.kernel.org,
kernel@pengutronix.de, Dave Taht <dave.taht@gmail.com>,
Jamal Hadi Salim <jhs@mojatatu.com>,
Cong Wang <xiyou.wangcong@gmail.com>,
Jiri Pirko <jiri@resnulli.us>,
Marc Kleine-Budde <mkl@pengutronix.de>
Subject: [PATCH 2/2] can: dev: let all CAN devices use pfifo_fast as default scheduler
Date: Wed, 27 Mar 2019 17:56:32 +0100 [thread overview]
Message-ID: <20190327165632.10711-3-mkl@pengutronix.de> (raw)
In-Reply-To: <20190327165632.10711-1-mkl@pengutronix.de>
When using fq_codel and sending raw frames over CAN, which is the common use
case, the user space thinks the package has been sent without problems, because
send() returned without an error. pfifo_fast will drop skbs, if the queue
length exceeds the maximum. But with this scheduler the skbs at the tail are
dropped, an error (-ENOBUFS) is propagated to user space. So that the user
space can slow down the package generation.
On distributions, where fq_codel is made default via CONFIG_DEFAULT_NET_SCH
during compile time, or set default during runtime with sysctl
net.core.default_qdisc (see [1]), we get a bad user experience. In my test case
with pfifo_fast, I can transfer thousands of million CAN frames without a frame
drop. On the other hand with fq_codel there is more then one lost CAN frame per
thousand frames.
This patch sets the flag IFF_FIFO_QUEUE on all CAN devices.
Cc: Dave Taht <dave.taht@gmail.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/dev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
index c05e4d50d43d..34bcabc35127 100644
--- a/drivers/net/can/dev.c
+++ b/drivers/net/can/dev.c
@@ -646,6 +646,7 @@ static void can_setup(struct net_device *dev)
/* New-style flags. */
dev->flags = IFF_NOARP;
+ dev->priv_flags = IFF_FIFO_QUEUE;
dev->features = NETIF_F_HW_CSUM;
}
--
2.20.1
next prev parent reply other threads:[~2019-03-27 16:56 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 ` Marc Kleine-Budde [this message]
2019-03-27 18:30 ` [RFC] net: sch_generic: fq_codel vs pfifo_fast Stephen Hemminger
2019-03-27 19:24 ` Marc Kleine-Budde
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=20190327165632.10711-3-mkl@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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).