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

[Oliver Hartkopp <socketcan@hartkopp.net>]

On 13.07.2015 06:57, Eric Dumazet wrote:
> On Sun, 2015-07-12 at 21:15 +0200, Oliver Hartkopp wrote:
>
>> 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.
>
> I doubt your skb_set_hash() makes any difference.
>
> RPS prefers a L4 hash anyway (skb_get_hash()), so flow dissection
> happens.
>

Please take a look into netif_rx_internal() in net/core/dev.c

http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/net/core/dev.c?id=v4.2-rc1#n3486

with CONFIG_RPS netif_rx() takes care about the rps cpu and puts the skb into 
the correct hash specific queue.

As we usually have several PF_CAN sockets which get CAN frames from a specific 
CAN interface it makes no sense to enqueue packets into queues sorted by 
receiving sockets or L4 hash (we don't have L4 addressing on CAN).

The skb_set_hash(skb, dev->ifindex, PKT_HASH_TYPE_L2) makes sure that the skbs 
from a specific CAN netdev are always processed in the same queue.

When this is not wanted in 'fastpath netif_rx()' why is the CONFIG_RPS section 
in there?

What is the advantage of implementing NAPI and a 'private sk_buf queue' 
suggested by Tom in http://marc.info/?l=linux-can&m=143681458003381&w=2 to set 
the hash as shown and enable rps_cpus?

The latter just looks just like a complexity boost to have a functionality 
that already exists in netif_rx(). I just want to understand it.

Regards,
Oliver