From: Oliver Hartkopp <socketcan@hartkopp.net>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Tom Herbert <tom@herbertland.com>,
Linux Kernel Network Developers <netdev@vger.kernel.org>,
"linux-can@vger.kernel.org" <linux-can@vger.kernel.org>,
Sunil Kovvuri <sunil.kovvuri@gmail.com>,
Jonathon Reinhart <jonathon.reinhart@gmail.com>
Subject: Re: Fighting out-of-order reception with RPS?
Date: Sun, 12 Jul 2015 21:15:36 +0200 [thread overview]
Message-ID: <55A2BCD8.4020303@hartkopp.net> (raw)
In-Reply-To: <1436589345.24939.56.camel@edumazet-glaptop2.roam.corp.google.com>
Hello Eric,
On 07/11/2015 06:35 AM, Eric Dumazet wrote:
> On Fri, 2015-07-10 at 22:36 +0200, Oliver Hartkopp wrote:
>> Hm. Doesn't sound like a good solution when there's a difference between NAPI
>> and non-NAPI drivers in matters of OOO, right?
>
> Isn't OOO a problem for you ? Then you either have to :
>
> 1) Use a single CPU to handle IRQ from the device
> 2) Use NAPI
>
See below ...
>> What about checking in netif_rx() if the non-NAPI driver has set a hash (aka
>> the driver is OOO sensitive)?
>> And if so we could automatically set rps_cpus for this interface in a way that
>> all CPUs are enabled to take skbs following the hash.
>
> Wow, netif_rx() is packet processing fast path, certainly not the place
> to add controlling path decisions.
My only requirement is to be able to pick CAN frames (contained in skbs) from
the socket in the same order they have been received.
> Please convert your driver to NAPI. You might then even benefit from
> GRO.
Just some remarks about CAN and CAN frames as you suggest GRO which is
completely pointless for CAN.
CAN frames have a 11 or 29 bit CAN Identifier (no MAC but content addressing)
and 0 to 64 bytes of payload. Therefore the MTU for CAN interfaces is 16 or 72
byte (see struct can(fd)_frame). Each skbuff contains a single CAN frame.
There are CAN controllers which have a FIFO for up to 32 CAN frames, e.g.
flexcan.c which also implements NAPI. Others (e.g. sja1000.c) don't have any
FIFO and the reading of the CAN frame from the memory mapped registers needs
to be processed in the irq context instantly. So 'fast path' netif_rx() is
reasonable, right?
So why is it not possible to pass netif_rx() skbs from a specific CAN network
interface to whatever queue where they are processed in order?
E.g. with
skb_set_hash(skb, dev->ifindex, PKT_HASH_TYPE_L2);
and
echo f > /sys/class/net/can0/queues/rx-0/rps_cpus
I get properly ordered CAN frames - even with netif_rx() processed skbs. I
just want to have this stuff to be enabled by default for CAN interfaces to
kill the OOO frame issue.
Regards,
Oliver
next prev parent reply other threads:[~2015-07-12 19:15 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-08 17:49 Fighting out-of-order reception with RPS? Oliver Hartkopp
2015-07-08 21:17 ` Tom Herbert
2015-07-09 5:55 ` Oliver Hartkopp
2015-07-10 2:48 ` Tom Herbert
2015-07-10 20:36 ` Oliver Hartkopp
2015-07-11 4:35 ` Eric Dumazet
2015-07-12 19:15 ` Oliver Hartkopp [this message]
2015-07-13 3:22 ` David Miller
2015-07-13 4:57 ` Eric Dumazet
2015-07-14 17:09 ` Oliver Hartkopp
2015-07-14 18:02 ` Tom Herbert
2015-07-14 19:03 ` David Miller
2015-07-14 19:05 ` Oliver Hartkopp
2015-07-13 19:08 ` Tom Herbert
2015-07-09 6:34 ` Holger Schurig
2015-07-09 8:48 ` Oliver Hartkopp
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=55A2BCD8.4020303@hartkopp.net \
--to=socketcan@hartkopp.net \
--cc=eric.dumazet@gmail.com \
--cc=jonathon.reinhart@gmail.com \
--cc=linux-can@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=sunil.kovvuri@gmail.com \
--cc=tom@herbertland.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).