> On Jun 8, 2021, at 3:36 AM, Stefan Metzmacher <metze@xxxxxxxxx> wrote: > > Am 08.06.21 um 05:04 schrieb Steve French: >> On Mon, Jun 7, 2021 at 11:45 AM Aurélien Aptel <aaptel@xxxxxxxx> wrote: >>> >>> Alexander Ahring Oder Aring <aahringo@xxxxxxxxxx> writes: >>>> 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. >> 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. >> 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
