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
| ||
|
Message-ID: <571661E5.7010304@solarflare.com> Date: Tue, 19 Apr 2016 17:50:45 +0100 From: Edward Cree <ecree@...arflare.com> To: Eric Dumazet <eric.dumazet@...il.com> CC: <netdev@...r.kernel.org>, David Miller <davem@...emloft.net>, "Jesper Dangaard Brouer" <brouer@...hat.com>, <linux-net-drivers@...arflare.com> Subject: Re: [RFC PATCH net-next 7/8] net: ipv4: listified version of ip_rcv On 19/04/16 15:50, Eric Dumazet wrote: > The main problem in UDP stack today is having to lock the socket because > of the dumb forward allocation problem. I'm not quite sure what you're referring to here, care to educate me? > Are you really going to provide > a list of skbs up to _one_ UDP socket ? In principle we should be able to take it that far, yes. AFAICT the socket already has a receive queue that we end up appending the packet to (and which I presume the recvmsg() syscall pulls from), I don't see why we couldn't just splice a list of skbs on the end rather than appending them one by one. Thus amortising looking up the socket.
Powered by blists - more mailing lists