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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html