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: Wed, 2 Mar 2011 10:39:20 +0800 From: Herbert Xu <herbert@...dor.apana.org.au> To: Eric Dumazet <eric.dumazet@...il.com> Cc: Thomas Graf <tgraf@...radead.org>, David Miller <davem@...emloft.net>, rick.jones2@...com, therbert@...gle.com, wsommerfeld@...gle.com, daniel.baluta@...il.com, netdev@...r.kernel.org Subject: Re: SO_REUSEPORT - can it be done in kernel? 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 : 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. For datagram protocols we simply use the current CPU. > We added RPS and XPS that works correctly if each socket is used by one > thread. Maybe we need to add an user API or automatically detect a > particular DGRAM socket is used by many different threads to : No we don't need that for datagram protocols at all. By definition there is no ordering guarantee across CPUs for datagram sockets. Cheers, -- Email: Herbert Xu <herbert@...dor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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