Thread (17 messages) 17 messages, 10 authors, 2021-09-05

Re: quic in-kernel implementation?

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 Kicinski
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help