Re: [PATCH 0/2] AF_PACKET fanout support

[Eric Dumazet <eric.dumazet@gmail.com>]

Le mardi 05 juillet 2011 à 20:19 -0700, David Miller a écrit :
> From: Tom Herbert <therbert@google.com>
> Date: Tue, 5 Jul 2011 20:13:27 -0700
> 
> >>> 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