netdev - Re: Fighting out-of-order reception with RPS?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALx6S36G1hkS+Fg5joSiMHNo+UvJ2DBsTp91kyr3eqm2vuLq0Q@mail.gmail.com>
Date:	Mon, 13 Jul 2015 12:08:26 -0700
From:	Tom Herbert <tom@...bertland.com>
To:	Oliver Hartkopp <socketcan@...tkopp.net>
Cc:	Eric Dumazet <eric.dumazet@...il.com>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	"linux-can@...r.kernel.org" <linux-can@...r.kernel.org>,
	Sunil Kovvuri <sunil.kovvuri@...il.com>,
	Jonathon Reinhart <jonathon.reinhart@...il.com>
Subject: Re: Fighting out-of-order reception with RPS?

On Sun, Jul 12, 2015 at 12:15 PM, Oliver Hartkopp
<socketcan@...tkopp.net> wrote:
> 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.
>
If you really must process the CAN FIFO in the hard interrupt then
create a private sk_buf queue. In the interrupt, dequeue from FIFO and
enqueue on the sk_buf queue. Then schedule NAPI, and when that runs
process the sk_buf queue calling call netif_receive_skb for each
enqueued skb. Pretty simple actually :-)

> Regards,
> Oliver
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html