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. > 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. > 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
