Re: [PATCH 0/2] AF_PACKET fanout support

Le mardi 05 juillet 2011 à 20:19 -0700, David Miller a écrit :

From: Tom Herbert <redacted>
Date: Tue, 5 Jul 2011 20:13:27 -0700

quoted

quoted

quoted

Also, another useful mode of steering would be to steer packets to a
socket which was recently processed by a thread running on the same
CPU; somewhat analogous to RFS (cc'ed WIllem Bruijn who is already
working on this I believe).

This sounds like a good way to overload a local socket and prevent
pushing the work to lesser used sockets on other cpus.

Sure, it you're not using RPS or RSS!  These should already be
distributing the RX work amongst CPUs.

One idea I did have while working on the PACKET_FANOUT bits was
to allow a packet socket to be bound to a particular cpu.  And
to implement this we'd have a per-cpu list of packet_type taps.

But in order for the user to make sure he gets all the traffic,
he'd have to make sure he bound one AF_PACKET socket to every
online cpu and then listened for all cpu hotplug events.

It doesn't really work.

It is working right now if you dont have too many cpus, adding as many
sockets as possible cpus, and convenient BPF filter (matching CPU X) per
packet socket. Of course, if a cpu is offlined, the corresponding socket
wont receive any packet.

Currently, with a multiqueue NIC, the two policies you have might be in
conflict with NIC flow distribution among its queues.

In the end, lot of different cpus will access all the sockets.

I suspect this can be solved adding a third policy : hash by CPU only