netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steve French <smfrench@gmail.com>
To: "Aurélien Aptel" <aaptel@suse.com>
Cc: Alexander Ahring Oder Aring <aahringo@redhat.com>,
	Network Development <netdev@vger.kernel.org>,
	linux-nfs <linux-nfs@vger.kernel.org>,
	CIFS <linux-cifs@vger.kernel.org>,
	Leif Sahlberg <lsahlber@redhat.com>,
	Steven Whitehouse <swhiteho@redhat.com>
Subject: Re: quic in-kernel implementation?
Date: Mon, 7 Jun 2021 22:04:15 -0500	[thread overview]
Message-ID: <CAH2r5msMBZ5AYQcfK=-xrOASzVC0SgoHdPnyqEPRcfd-tzUstw@mail.gmail.com> (raw)
In-Reply-To: <87pmwxsjxm.fsf@suse.com>

On Mon, Jun 7, 2021 at 11:45 AM Aurélien Aptel <aaptel@suse.com> wrote:
>
> Alexander Ahring Oder Aring <aahringo@redhat.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
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
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




-- 
Thanks,

Steve

  reply	other threads:[~2021-06-08  3:04 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-07 15:25 quic in-kernel implementation? Alexander Ahring Oder Aring
2021-06-07 16:45 ` Aurélien Aptel
2021-06-08  3:04   ` Steve French [this message]
2021-06-08  7:36     ` Stefan Metzmacher
2021-06-08 21:03       ` Alexander Aring
2021-06-08 22:33         ` Stephen Hemminger
2021-06-09 16:48           ` Jakub Kicinski
2021-06-09 18:44             ` Alexander Aring
2021-06-13 12:17             ` David Laight
2021-06-13 18:08               ` Alexander Aring
2021-06-08 21:26       ` Chuck Lever III
2021-06-07 17:29 ` Chuck Lever III
2021-06-08 20:51 ` Vadim Fedorenko
2021-06-08 21:06   ` Alexander Aring
2021-06-09  0:27     ` Vadim Fedorenko
2021-09-05 14:09       ` Eric Curtin
2021-09-05 23:38         ` Steve French

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAH2r5msMBZ5AYQcfK=-xrOASzVC0SgoHdPnyqEPRcfd-tzUstw@mail.gmail.com' \
    --to=smfrench@gmail.com \
    --cc=aahringo@redhat.com \
    --cc=aaptel@suse.com \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=lsahlber@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=swhiteho@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).