On Jun 8, 2021, at 3:36 AM, Stefan Metzmacher [off-list ref] wrote:

Am 08.06.21 um 05:04 schrieb Steve French:

quoted

On Mon, Jun 7, 2021 at 11:45 AM Aurélien Aptel [off-list ref] wrote:

quoted

Alexander Ahring Oder Aring [off-list ref] writes:

quoted

as I notice there exists several quic user space implementations, is
there any interest or process of doing an in-kernel implementation? I
am asking because I would like to try out quic with an in-kernel
application protocol like DLM. Besides DLM I've heard that the SMB
community is also interested into such implementation.

Yes SMB can work over QUIC. It would be nice if there was an in-kernel
implementation that cifs.ko could use. Many firewall block port 445
(SMB) despite the newer version of the protocol now having encryption,
signing, etc. Using QUIC (UDP port 443) would allow for more reliable
connectivity to cloud storage like azure.

There are already multiple well-tested C QUIC implementation out there
(Microsoft one for example, has a lot of extra code annotation to allow
for deep static analysis) but I'm not sure how we would go about porting
it to linux.

https://github.com/microsoft/msquic

Since the Windows implementation of SMB3.1.1 over QUIC appears stable
(for quite a while now) and well tested, and even wireshark can now decode it, a
possible sequence of steps has been discussed similar to the below:

1) using a userspace port of QUIC (e.g. msquic since is one of the more tested
ports, and apparently similar to what already works well for QUIC on Windows
with SMB3.1.1) finish up the SMB3.1.1 kernel pieces needed for running over
QUIC

Instead of using userspace upcalls directly, it would be great if we could hide
behind a fuse-like socket type, in order to keep the kernel changes in fs/cifs (and other parts)
tiny and just replace the socket(AF_INET) call, but continue to use a
stream socket (likely with a few QUIC specific getsockopt/setsockopt calls).

It would also allow userspace applications like Samba's smbclient and smbd
to use it that way too.

That's interesting as a development scaffold.

However, IMO the interesting part of QUIC for us is transport
layer security. NFS already has TLS via RPC-over-TLS, and we
intend to have a full in-kernel implementation soon. Using a
user-space transport protocol implementation is likely to be
an unacceptable step backwards in terms of performance for us.
NFS connections are long-lived, no benefit at all from the
special 0-RTT mechanisms.

I hope the end goal is to have a full in-kernel implementation
of QUIC at some point, otherwise I don't see Linux QUIC ever
being on par with current TCP performance for a kernel
consumer.

quoted

2) then switch focus to porting a smaller C userspace implementation of
QUIC to Linux (probably not msquic since it is larger and doesn't
follow kernel style)
to kernel in fs/cifs  (since currently SMB3.1.1 is the only protocol
that uses QUIC,
and the Windows server target is quite stable and can be used to test against)> 3) use the userspace upcall example from step 1 for
comparison/testing/debugging etc.
since we know the userspace version is stable

With having the fuse-like socket before it should be trivial to switch
between the implementations.

Although switching QUIC implementations is a cool trick for
rapid prototyping, I'm unclear on the eventual user benefit
of it.

quoted

4) Once SMB3.1.1 over QUIC is no longer experimental, remove, and
we are convinced it (kernel QUIC port) works well with SMB3.1.1
to servers which support QUIC, then move the quic code from fs/cifs to the /net
tree

The 4th step would then finally allocate a stable PF_QUIC which would be
ABI stable.

metze

--
Chuck Lever