Re: quic in-kernel implementation?
From: Alexander Aring <aahringo@redhat.com>
Date: 2021-06-13 18:08:38
Also in:
linux-cifs, linux-nfs
From: Alexander Aring <aahringo@redhat.com>
Date: 2021-06-13 18:08:38
Also in:
linux-cifs, linux-nfs
Hi, On Sun, Jun 13, 2021 at 8:17 AM David Laight [off-list ref] wrote:
From: Jakub Kicinskiquoted
Sent: 09 June 2021 17:48...quoted
quoted
quoted
I think two veth interfaces can help to test something like that, either with a "fuse-like socket" on the other end or an user space application. Just doing a ping-pong example. Afterwards we can look at how to replace the user generated socket application with any $LIBQUIC e.g. msquic implementation as second step.Socket state management is complex and timers etc in userspace are hard.+1 seeing the struggles fuse causes in storage land "fuse for sockets" is not an exciting temporary solution IMHO..Especially since you'd want reasonable performance for quic. Fuse is normally used to access obscure filesystems where you just need access, rather than something that really needs to be quick.
or you have library dependencies like sshfs. That is the case in quic for some parts of TLS (see TLS socket API). Sure it will not be the final solution, that was never the intention. It is to establish a kernel-API which will be replaced for a final in-kernel solution later and not trying to solve all problems at once. - Alex