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
| ||
|
Date: Tue, 1 Mar 2011 23:12:29 -0800 From: Tom Herbert <therbert@...gle.com> To: Herbert Xu <herbert@...dor.hengli.com.au> Cc: Eric Dumazet <eric.dumazet@...il.com>, Thomas Graf <tgraf@...radead.org>, David Miller <davem@...emloft.net>, rick.jones2@...com, wsommerfeld@...gle.com, daniel.baluta@...il.com, netdev@...r.kernel.org Subject: Re: SO_REUSEPORT - can it be done in kernel? On Tue, Mar 1, 2011 at 6:39 PM, Herbert Xu <herbert@...dor.apana.org.au> wrote: > On Wed, Mar 02, 2011 at 03:00:03AM +0100, Eric Dumazet wrote: >> > >> > Think about it, a TCP socket cannot be used by a multi-threaded app >> > in a scalable way. >> >> Well... >> >> If you think about it, SO_REUSEPORT patch has exactly the same goal : > In a sense. SO_RESUSEPORT for TCP is intended to provide a scalable listener solution. Sharing an established socket is not very efficient, something like a multiplexing socket layer on top of TCP might be good. > UDP is a datagram protocol, TCP is not. > > Anyway, here is an alternate proposal. When a TCP socket transmits > for the first time (SYN or SYN-ACK), we pick a queue based on CPU and > store it in the socket. From then on we stick to that selection. > > We would only allow changes if we can ensure that all transmitted > packets have left the queue. Or we just never change it like we > do now. > XPS does all this already. > For datagram protocols we simply use the current CPU. > Probably need to set skb->ooo_okay (for UDP etc.) also so that XPS will change queues. Tom -- 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
Powered by blists - more mailing lists