Message-ID: <c61a60ef-fa9d-44ea-9852-ae7b18bc1ab1@lunn.ch>
Date: Fri, 18 Aug 2023 14:42:26 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Davide Rovelli <roveld@....ch>
Cc: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
	Michele Dalle Rive <dallerivemichele@...il.com>,
	Greg KH <gregkh@...uxfoundation.org>,
	Miguel Ojeda <ojeda@...nel.org>,
	Alex Gaynor <alex.gaynor@...il.com>,
	Wedson Almeida Filho <wedsonaf@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
	Björn Roy Baron <bjorn3_gh@...tonmail.com>,
	Benno Lossin <benno.lossin@...ton.me>,
	Alice Ryhl <aliceryhl@...gle.com>,
	Davide Rovelli <davide.rovelli@....ch>,
	rust-for-linux@...r.kernel.org, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, patches@...ts.linux.dev
Subject: Re: [RFC PATCH 0/7] Rust Socket abstractions

On Fri, Aug 18, 2023 at 09:50:45AM +0200, Davide Rovelli wrote:
> 
> 
> On 8/18/23 03:30, Andrew Lunn wrote:
> 
> > So you have an application in user space wanting to use this
> > protocol. I assume it is using BSD sockets to communicate with the
> > kernel and the protocol.
> 
> No, at the moment it uses procfs or a shared mmap'd chardev buffer.

O.K, so that will never be accepted. There is support for zero copy in
sockets. Look at the work Eric did. And you should look at netlink,
which might be needed for the control plane.
 
> > So you need an API below sockets to get this
> > traffic, i assume a whole new protocol family? But you have an API on
> > top of sockets for TCP/UDP. So i guess your protocol somehow
> > encapsulate the traffic and then uses the API your are proposing to
> > send over TCP or UDP?
> 
> Yes, we take a message/value from a user space app and send it to
> other nodes via UDP according to the chosen protocol. Mind that
> the term "protocol" might be misleading here as it can be confused
> with classic network protocols. Our API offers distributed services
> such as failure detectors, consensus etc.
> 
> > Which makes me think:
> > 
> > Why go through sockets twice for a low jitter networking protocol?
> 
> The idea behind the system is to be split: user space apps are
> normal apps that can present arbitrary jitter, kernel space services
> are isolated to provide low jitter. The same applies in the network
> via a SDN based protocol which prioritises our traffic. By having
> end-to-end timely communication and processing, we can achieve
> new efficient distributed services.

Having the services running in kernel space is going to limit what
services you can actually offer, if you need to go through getting
them merged every time. If you only have one or two, yes it can be
done. But anything general purpose is not going to be practical.  The
answer might be to write your services using eBPF. They can then be
loaded from user space and do pretty much anything which eBPF can do.

There is often a huge step from academic code to production
code. Academic code just needs to implement enough to prove the
concept. It can take all sort of short cuts. Production code to be
merged into the kernel needs to follow the usual development
processes, code quality guidelines, and most importantly,
architecture.

If you want to make that step to production code, we can help you, but
i don't think it makes any sense to merge API code until you have the
correct basic architecture. That architecture will define what APIs
you need, and sitting on top of sockets might not be correct.

	Andrew

Powered by blists - more mailing lists