[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <35352ef0-86ed-aaa5-4a49-b2b08dc3674d@samba.org>
Date: Tue, 8 Jun 2021 09:36:27 +0200
From: Stefan Metzmacher <metze@...ba.org>
To: Steve French <smfrench@...il.com>,
Aurélien Aptel <aaptel@...e.com>
Cc: Alexander Ahring Oder Aring <aahringo@...hat.com>,
Network Development <netdev@...r.kernel.org>,
linux-nfs <linux-nfs@...r.kernel.org>,
CIFS <linux-cifs@...r.kernel.org>,
Leif Sahlberg <lsahlber@...hat.com>,
Steven Whitehouse <swhiteho@...hat.com>
Subject: Re: quic in-kernel implementation?
Am 08.06.21 um 05:04 schrieb Steve French:
> On Mon, Jun 7, 2021 at 11:45 AM Aurélien Aptel <aaptel@...e.com> wrote:
>>
>> Alexander Ahring Oder Aring <aahringo@...hat.com> 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
Powered by blists - more mailing lists