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 for Android: free password hash cracker in your pocket

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

Message-ID: <55A2BCD8.4020303@hartkopp.net>
Date:	Sun, 12 Jul 2015 21:15:36 +0200
From:	Oliver Hartkopp <socketcan@...tkopp.net>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	Tom Herbert <tom@...bertland.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?

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

--
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