netdev - Re: [PATCH 0/2] AF_PACKET fanout support

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Wed, 06 Jul 2011 06:07:46 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	David Miller <davem@...emloft.net>
Cc:	therbert@...gle.com, victor@...iniac.net, netdev@...r.kernel.org,
	willemb@...gle.com
Subject: Re: [PATCH 0/2] AF_PACKET fanout support

Le mardi 05 juillet 2011 à 20:19 -0700, David Miller a écrit :
> From: Tom Herbert <therbert@...gle.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




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