Netdev Archive on lore.kernel.org
help / color / mirror / Atom feed
* quic in-kernel implementation?
@ 2021-06-07 15:25 Alexander Ahring Oder Aring
  2021-06-07 16:45 ` Aurélien Aptel
                   ` (2 more replies)
  0 siblings, 3 replies; 17+ messages in thread
From: Alexander Ahring Oder Aring @ 2021-06-07 15:25 UTC (permalink / raw)
  To: netdev; +Cc: linux-nfs, linux-cifs, smfrench, Leif Sahlberg, Steven Whitehouse

Hi,

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.

- Alex


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: quic in-kernel implementation?
  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
  2021-06-07 17:29 ` Chuck Lever III
  2021-06-08 20:51 ` Vadim Fedorenko
  2 siblings, 1 reply; 17+ messages in thread
From: Aurélien Aptel @ 2021-06-07 16:45 UTC (permalink / raw)
  To: Alexander Ahring Oder Aring, netdev
  Cc: linux-nfs, linux-cifs, smfrench, Leif Sahlberg, Steven Whitehouse

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

Cheers,
-- 
Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München)


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: quic in-kernel implementation?
  2021-06-07 15:25 quic in-kernel implementation? Alexander Ahring Oder Aring
  2021-06-07 16:45 ` Aurélien Aptel
@ 2021-06-07 17:29 ` Chuck Lever III
  2021-06-08 20:51 ` Vadim Fedorenko
  2 siblings, 0 replies; 17+ messages in thread
From: Chuck Lever III @ 2021-06-07 17:29 UTC (permalink / raw)
  To: Alexander Ahring Oder Aring
  Cc: Linux-Net, Linux NFS Mailing List, CIFS, smfrench, Leif Sahlberg,
	Steven Whitehouse



> On Jun 7, 2021, at 11:25 AM, Alexander Ahring Oder Aring <aahringo@redhat.com> wrote:
> 
> Hi,
> 
> 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.

The NFS community has standardized RPC-over-TLS as part of an
effort to prepare for running NFS on QUIC transports.

https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpc-tls/

Towards that end, an in-kernel QUIC would need a way to perform
transport security handshakes. Tempesta has one we are looking
closely at -- it can support both TLS and QUIC.

There's more work to be done to address the ways in which QUIC
is different than existing transports (eg. its support for
streams and transactions); however if Linux were to gain an
in-kernel QUIC implementation, there is interest in seeing NFS
use it.


--
Chuck Lever




^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: quic in-kernel implementation?
  2021-06-07 16:45 ` Aurélien Aptel
@ 2021-06-08  3:04   ` Steve French
  2021-06-08  7:36     ` Stefan Metzmacher
  0 siblings, 1 reply; 17+ messages in thread
From: Steve French @ 2021-06-08  3:04 UTC (permalink / raw)
  To: Aurélien Aptel
  Cc: Alexander Ahring Oder Aring, Network Development, linux-nfs,
	CIFS, Leif Sahlberg, Steven Whitehouse

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: quic in-kernel implementation?
  2021-06-08  3:04   ` Steve French
@ 2021-06-08  7:36     ` Stefan Metzmacher
  2021-06-08 21:03       ` Alexander Aring
  2021-06-08 21:26       ` Chuck Lever III
  0 siblings, 2 replies; 17+ messages in thread
From: Stefan Metzmacher @ 2021-06-08  7:36 UTC (permalink / raw)
  To: Steve French, Aurélien Aptel
  Cc: Alexander Ahring Oder Aring, Network Development, linux-nfs,
	CIFS, Leif Sahlberg, Steven Whitehouse

Am 08.06.21 um 05:04 schrieb Steve French:
> 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

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: quic in-kernel implementation?
  2021-06-07 15:25 quic in-kernel implementation? Alexander Ahring Oder Aring
  2021-06-07 16:45 ` Aurélien Aptel
  2021-06-07 17:29 ` Chuck Lever III
@ 2021-06-08 20:51 ` Vadim Fedorenko
  2021-06-08 21:06   ` Alexander Aring
  2 siblings, 1 reply; 17+ messages in thread
From: Vadim Fedorenko @ 2021-06-08 20:51 UTC (permalink / raw)
  To: Alexander Ahring Oder Aring, netdev
  Cc: linux-nfs, linux-cifs, smfrench, Leif Sahlberg, Steven Whitehouse

On 07.06.2021 16:25, Alexander Ahring Oder Aring wrote:
> Hi,
> 
> 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.
> 
> - Alex
> 

Hi!
I'm working on test in-kernel implementation of quic. It's based on the
kernel-tls work and uses the same ULP approach to setup connection
configuration. It's mostly about offload crypto operations of short header
to kernel and use user-space implementation to deal with any other types
of packets. Hope to test it till the end of June with some help from
Jakub.
Vadim

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: quic in-kernel implementation?
  2021-06-08  7:36     ` Stefan Metzmacher
@ 2021-06-08 21:03       ` Alexander Aring
  2021-06-08 22:33         ` Stephen Hemminger
  2021-06-08 21:26       ` Chuck Lever III
  1 sibling, 1 reply; 17+ messages in thread
From: Alexander Aring @ 2021-06-08 21:03 UTC (permalink / raw)
  To: Stefan Metzmacher
  Cc: Steve French, Aurélien Aptel, Network Development,
	linux-nfs, CIFS, Leif Sahlberg, Steven Whitehouse

Hi,

On Tue, Jun 8, 2021 at 3:36 AM Stefan Metzmacher <metze@samba.org> wrote:
...
>
> > 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.

So a good starting point would be to have such a "fuse-like socket"
component? What about having a simple example for that at first
without having quic involved. The kernel calls some POSIX-like socket
interface which triggers a communication to a user space application.
This user space application will then map everything to a user space
generated socket. This would be a map from socket struct
"proto/proto_ops" to user space and vice versa. The kernel application
probably can use the kernel_FOO() (e.g. kernel_recvmsg()) socket api
directly then. Exactly like "fuse" as you mentioned just for sockets.

I think two veth interfaces can help to test something like that,
either with a "fuse-like socket" on the other end or an user space
application. Just doing a ping-pong example.

Afterwards we can look at how to replace the user generated socket
application with any $LIBQUIC e.g. msquic implementation as second
step.

- Alex


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: quic in-kernel implementation?
  2021-06-08 20:51 ` Vadim Fedorenko
@ 2021-06-08 21:06   ` Alexander Aring
  2021-06-09  0:27     ` Vadim Fedorenko
  0 siblings, 1 reply; 17+ messages in thread
From: Alexander Aring @ 2021-06-08 21:06 UTC (permalink / raw)
  To: Vadim Fedorenko
  Cc: netdev, linux-nfs, linux-cifs, smfrench, Leif Sahlberg,
	Steven Whitehouse

Hi Vadim,

On Tue, Jun 8, 2021 at 4:59 PM Vadim Fedorenko <vfedorenko@novek.ru> wrote:
>
> On 07.06.2021 16:25, Alexander Ahring Oder Aring wrote:
> > Hi,
> >
> > 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.
> >
> > - Alex
> >
>
> Hi!
> I'm working on test in-kernel implementation of quic. It's based on the
> kernel-tls work and uses the same ULP approach to setup connection
> configuration. It's mostly about offload crypto operations of short header
> to kernel and use user-space implementation to deal with any other types
> of packets. Hope to test it till the end of June with some help from
> Jakub.

Thanks, sounds interesting. Does this allow the kernel to create a quic socket?

- Alex


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: quic in-kernel implementation?
  2021-06-08  7:36     ` Stefan Metzmacher
  2021-06-08 21:03       ` Alexander Aring
@ 2021-06-08 21:26       ` Chuck Lever III
  1 sibling, 0 replies; 17+ messages in thread
From: Chuck Lever III @ 2021-06-08 21:26 UTC (permalink / raw)
  To: Stefan Metzmacher, Alexander Ahring Oder Aring
  Cc: Steve French, Aurélien Aptel, Network Development,
	Linux NFS Mailing List, CIFS, Leif Sahlberg, Steven Whitehouse



> On Jun 8, 2021, at 3:36 AM, Stefan Metzmacher <metze@samba.org> wrote:
> 
> Am 08.06.21 um 05:04 schrieb Steve French:
>> 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
> 
> 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




^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: quic in-kernel implementation?
  2021-06-08 21:03       ` Alexander Aring
@ 2021-06-08 22:33         ` Stephen Hemminger
  2021-06-09 16:48           ` Jakub Kicinski
  0 siblings, 1 reply; 17+ messages in thread
From: Stephen Hemminger @ 2021-06-08 22:33 UTC (permalink / raw)
  To: Alexander Aring
  Cc: Stefan Metzmacher, Steve French, Aurélien Aptel,
	Network Development, linux-nfs, CIFS, Leif Sahlberg,
	Steven Whitehouse

On Tue, 8 Jun 2021 17:03:16 -0400
Alexander Aring <aahringo@redhat.com> wrote:

> Hi,
> 
> On Tue, Jun 8, 2021 at 3:36 AM Stefan Metzmacher <metze@samba.org> wrote:
> ...
> >  
> > > 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.  
> 
> So a good starting point would be to have such a "fuse-like socket"
> component? What about having a simple example for that at first
> without having quic involved. The kernel calls some POSIX-like socket
> interface which triggers a communication to a user space application.
> This user space application will then map everything to a user space
> generated socket. This would be a map from socket struct
> "proto/proto_ops" to user space and vice versa. The kernel application
> probably can use the kernel_FOO() (e.g. kernel_recvmsg()) socket api
> directly then. Exactly like "fuse" as you mentioned just for sockets.
> 
> I think two veth interfaces can help to test something like that,
> either with a "fuse-like socket" on the other end or an user space
> application. Just doing a ping-pong example.
> 
> Afterwards we can look at how to replace the user generated socket
> application with any $LIBQUIC e.g. msquic implementation as second
> step.
> 
> - Alex
> 

Socket state management is complex and timers etc in userspace are hard.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: quic in-kernel implementation?
  2021-06-08 21:06   ` Alexander Aring
@ 2021-06-09  0:27     ` Vadim Fedorenko
  2021-09-05 14:09       ` Eric Curtin
  0 siblings, 1 reply; 17+ messages in thread
From: Vadim Fedorenko @ 2021-06-09  0:27 UTC (permalink / raw)
  To: Alexander Aring
  Cc: netdev, linux-nfs, linux-cifs, smfrench, Leif Sahlberg,
	Steven Whitehouse

On 08.06.2021 22:06, Alexander Aring wrote:
> Hi Vadim,
> 
> On Tue, Jun 8, 2021 at 4:59 PM Vadim Fedorenko <vfedorenko@novek.ru> wrote:
>>
>> On 07.06.2021 16:25, Alexander Ahring Oder Aring wrote:
>>> Hi,
>>>
>>> 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.
>>>
>>> - Alex
>>>
>>
>> Hi!
>> I'm working on test in-kernel implementation of quic. It's based on the
>> kernel-tls work and uses the same ULP approach to setup connection
>> configuration. It's mostly about offload crypto operations of short header
>> to kernel and use user-space implementation to deal with any other types
>> of packets. Hope to test it till the end of June with some help from
>> Jakub.
> 
> Thanks, sounds interesting. Does this allow the kernel to create a quic socket?
> 

Not exactly. It's based on top of UDP socket and is configured by setsockopt
like it's done for Kernel TLS implementation. The main point of this work is to
offload cryptography only without implementing special address family.



^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: quic in-kernel implementation?
  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
  0 siblings, 2 replies; 17+ messages in thread
From: Jakub Kicinski @ 2021-06-09 16:48 UTC (permalink / raw)
  To: Stephen Hemminger
  Cc: Alexander Aring, Stefan Metzmacher, Steve French,
	Aurélien Aptel, Network Development, linux-nfs, CIFS,
	Leif Sahlberg, Steven Whitehouse

On Tue, 8 Jun 2021 15:33:49 -0700 Stephen Hemminger wrote:
> On Tue, 8 Jun 2021 17:03:16 -0400
> > > With having the fuse-like socket before it should be trivial to switch
> > > between the implementations.    
> > 
> > So a good starting point would be to have such a "fuse-like socket"
> > component? What about having a simple example for that at first
> > without having quic involved. The kernel calls some POSIX-like socket
> > interface which triggers a communication to a user space application.
> > This user space application will then map everything to a user space
> > generated socket. This would be a map from socket struct
> > "proto/proto_ops" to user space and vice versa. The kernel application
> > probably can use the kernel_FOO() (e.g. kernel_recvmsg()) socket api
> > directly then. Exactly like "fuse" as you mentioned just for sockets.
> > 
> > I think two veth interfaces can help to test something like that,
> > either with a "fuse-like socket" on the other end or an user space
> > application. Just doing a ping-pong example.
> > 
> > Afterwards we can look at how to replace the user generated socket
> > application with any $LIBQUIC e.g. msquic implementation as second
> > step.
> 
> Socket state management is complex and timers etc in userspace are hard.

+1 seeing the struggles fuse causes in storage land "fuse for sockets"
is not an exciting temporary solution IMHO..

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: quic in-kernel implementation?
  2021-06-09 16:48           ` Jakub Kicinski
@ 2021-06-09 18:44             ` Alexander Aring
  2021-06-13 12:17             ` David Laight
  1 sibling, 0 replies; 17+ messages in thread
From: Alexander Aring @ 2021-06-09 18:44 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: Stephen Hemminger, Stefan Metzmacher, Steve French,
	Aurélien Aptel, Network Development, linux-nfs, CIFS,
	Leif Sahlberg, Steven Whitehouse

Hi,

On Wed, Jun 9, 2021 at 12:48 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Tue, 8 Jun 2021 15:33:49 -0700 Stephen Hemminger wrote:
> > On Tue, 8 Jun 2021 17:03:16 -0400
> > > > With having the fuse-like socket before it should be trivial to switch
> > > > between the implementations.
> > >
> > > So a good starting point would be to have such a "fuse-like socket"
> > > component? What about having a simple example for that at first
> > > without having quic involved. The kernel calls some POSIX-like socket
> > > interface which triggers a communication to a user space application.
> > > This user space application will then map everything to a user space
> > > generated socket. This would be a map from socket struct
> > > "proto/proto_ops" to user space and vice versa. The kernel application
> > > probably can use the kernel_FOO() (e.g. kernel_recvmsg()) socket api
> > > directly then. Exactly like "fuse" as you mentioned just for sockets.
> > >
> > > I think two veth interfaces can help to test something like that,
> > > either with a "fuse-like socket" on the other end or an user space
> > > application. Just doing a ping-pong example.
> > >
> > > Afterwards we can look at how to replace the user generated socket
> > > application with any $LIBQUIC e.g. msquic implementation as second
> > > step.
> >
> > Socket state management is complex and timers etc in userspace are hard.
>
> +1 seeing the struggles fuse causes in storage land "fuse for sockets"
> is not an exciting temporary solution IMHO..

What about an in-kernel sunrpc client which forwards "in-kernel proxy
socket syscall functions" to a user server who executes those on a
user socket? Does this sound like a better approach?
Sure there may be more problems, but maybe we could try it with
something simple at first to discover all those problems.

- Alex


^ permalink raw reply	[flat|nested] 17+ messages in thread

* RE: quic in-kernel implementation?
  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
  1 sibling, 1 reply; 17+ messages in thread
From: David Laight @ 2021-06-13 12:17 UTC (permalink / raw)
  To: 'Jakub Kicinski', Stephen Hemminger
  Cc: Alexander Aring, Stefan Metzmacher, Steve French,
	Aurélien Aptel, Network Development, linux-nfs, CIFS,
	Leif Sahlberg, Steven Whitehouse

From: Jakub Kicinski
> Sent: 09 June 2021 17:48
...
> > > I think two veth interfaces can help to test something like that,
> > > either with a "fuse-like socket" on the other end or an user space
> > > application. Just doing a ping-pong example.
> > >
> > > Afterwards we can look at how to replace the user generated socket
> > > application with any $LIBQUIC e.g. msquic implementation as second
> > > step.
> >
> > Socket state management is complex and timers etc in userspace are hard.
> 
> +1 seeing the struggles fuse causes in storage land "fuse for sockets"
> is not an exciting temporary solution IMHO..

Especially since you'd want reasonable performance for quic.

Fuse is normally used to access obscure filesystems where
you just need access, rather than something that really
needs to be quick.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: quic in-kernel implementation?
  2021-06-13 12:17             ` David Laight
@ 2021-06-13 18:08               ` Alexander Aring
  0 siblings, 0 replies; 17+ messages in thread
From: Alexander Aring @ 2021-06-13 18:08 UTC (permalink / raw)
  To: David Laight
  Cc: Jakub Kicinski, Stephen Hemminger, Stefan Metzmacher,
	Steve French, Aurélien Aptel, Network Development,
	linux-nfs, CIFS, Leif Sahlberg, Steven Whitehouse

Hi,

On Sun, Jun 13, 2021 at 8:17 AM David Laight <David.Laight@aculab.com> wrote:
>
> From: Jakub Kicinski
> > Sent: 09 June 2021 17:48
> ...
> > > > I think two veth interfaces can help to test something like that,
> > > > either with a "fuse-like socket" on the other end or an user space
> > > > application. Just doing a ping-pong example.
> > > >
> > > > Afterwards we can look at how to replace the user generated socket
> > > > application with any $LIBQUIC e.g. msquic implementation as second
> > > > step.
> > >
> > > Socket state management is complex and timers etc in userspace are hard.
> >
> > +1 seeing the struggles fuse causes in storage land "fuse for sockets"
> > is not an exciting temporary solution IMHO..
>
> Especially since you'd want reasonable performance for quic.
>
> Fuse is normally used to access obscure filesystems where
> you just need access, rather than something that really
> needs to be quick.
>

or you have library dependencies like sshfs. That is the case in quic
for some parts of TLS (see TLS socket API). Sure it will not be the
final solution, that was never the intention. It is to establish a
kernel-API which will be replaced for a final in-kernel solution later
and not trying to solve all problems at once.

- Alex


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: quic in-kernel implementation?
  2021-06-09  0:27     ` Vadim Fedorenko
@ 2021-09-05 14:09       ` Eric Curtin
  2021-09-05 23:38         ` Steve French
  0 siblings, 1 reply; 17+ messages in thread
From: Eric Curtin @ 2021-09-05 14:09 UTC (permalink / raw)
  To: vfedorenko
  Cc: aahringo, linux-cifs, linux-nfs, lsahlber, netdev, smfrench, swhiteho

Hi Guys,

Great idea, something I have been hoping to see in the kernel for a
while. How has your implementation been going @Vadim? I'd be interested
in a non-encrypted version of QUIC also in the kernel (may not be
supported in the spec but possible and I think worth having), would be
useful for cases where you don't care about network ossification
protection or data-in-transit encryption, say a trusted local network
where you would prefer the performance and reliability advantages of
going plaintext and you don't want to figure out how to deploy
certififcates. Something that could be used as a straight swap for a
TCP socket.


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: quic in-kernel implementation?
  2021-09-05 14:09       ` Eric Curtin
@ 2021-09-05 23:38         ` Steve French
  0 siblings, 0 replies; 17+ messages in thread
From: Steve French @ 2021-09-05 23:38 UTC (permalink / raw)
  To: Eric Curtin
  Cc: vfedorenko, Alexander Ahring Oder Aring, CIFS, Ronnie Sahlberg,
	Network Development, Steven Whitehouse

I am interested in this as well (encrypted and non-encrypted QUIC
cases in kernel)

Short term given that Windows is the only server than currently
support it - testing probably needs to be done via upcall with
SMB3.1.1 Linux mounts to Windows, and once that is verified to work
(as a baseline for comparison) - start work on the kernel QUIC driver

But for the initial point of comparison - would be helpful to have
example code that exposes a kernel "socket like" ("sock_sendmsg") API
for upcall ... and once we verify that that works start the work on
the kernel driver

On Sun, Sep 5, 2021 at 9:10 AM Eric Curtin <ericcurtin17@gmail.com> wrote:
>
> Hi Guys,
>
> Great idea, something I have been hoping to see in the kernel for a
> while. How has your implementation been going @Vadim? I'd be interested
> in a non-encrypted version of QUIC also in the kernel (may not be
> supported in the spec but possible and I think worth having), would be
> useful for cases where you don't care about network ossification
> protection or data-in-transit encryption, say a trusted local network
> where you would prefer the performance and reliability advantages of
> going plaintext and you don't want to figure out how to deploy
> certififcates. Something that could be used as a straight swap for a
> TCP socket.
>


-- 
Thanks,

Steve

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2021-09-05 23:38 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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

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