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: Mon, 22 Dec 2014 12:51:57 -0800 From: Dave Taht <dave.taht@...il.com> To: Alex Gartrell <agartrell@...com> Cc: Herbert Xu <herbert@...dor.apana.org.au>, jasonwang@...hat.com, "davem@...emloft.net" <davem@...emloft.net>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "Michael S. Tsirkin" <mst@...hat.com>, herbert@...dor.apena.org.au, kernel-team@...com Subject: Re: [RFC PATCH net-next] tun: support retrieving multiple packets in a single read with IFF_MULTI_READ On Mon, Dec 22, 2014 at 12:18 PM, Alex Gartrell <agartrell@...com> wrote: > Hey Herbert, > > Thanks for getting back to me > > On 12/22/14 4:09 AM, Herbert Xu wrote: >> >> As tun already has a socket interface can we do this through >> recvmmsg? > > > This just presents an easier interface (IMHO) for accomplishing that. And I > say easier because I was unable how to figure out the recvmmsg way to do it. the recvmsg and recvmmsg calls and layers above them could use an abstraction that allows for better passing of per packet header information to applications in the QUIC and webrtc age. > While fully aware that this makes me look like an idiot, I have to admit I have lost several days of hair to *msg calls. So have the authors of multipath mosh (which is WAY cool, btw: https://github.com/boutier/mosh So, no, trying and failing does not make you an idiot. Trying at all does make you a mite crazy, however. :) > that I've tried and failed to figure out how to get a socket fd out of the > tun device. > > The regular fd doesn't work (which is obvious when you look at the > implementation sock_from_file), there's a tun_get_socket function but it's > only referenced by a single file, and none of the ioctl's jump out at me as > doing anything to enable this behavior. Additionally, tuntap.txt makes no > mention of sockets specifically. > > FWIW, I don't feel strongly that IFF_MULTI_READ is the right way to do this > either. I have been thinking about how to implement multiple ways of eliminating serialization dependencies in userspace vpns using fair queueing, and multithreading... (with splitting out the seqno + address across an entire /64) ... and excess latency with multipacket reads, and then codeling internal queues (as many vpns bottleneck on the encap and encode step allowing for packets to accumulate in the OS recv buffer) See: http://www.tinc-vpn.org/pipermail/tinc-devel/2014-December/000680.html And especially: https://plus.google.com/u/0/107942175615993706558/posts/QWPWLoGMtrm and after having just suffered through making that work with recvmsg, was dreading trying to make it work with recvmmsg. It appears that one of the core crazy ideas (listening on an entire /64) doesn´t work with the existing APIs, and this new interface would help? Or recvmmsg could be generalized? Or? -- Dave Täht http://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks -- 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