On 9/19/2019 9:15 AM, Matthew Wilcox wrote:
> Why is it organised this way?  I mean, yes, technically, rxrpc is a
> generic layer-6 protocol that any blah blah blah, but in practice no
> other user has come up in the last 37 years, so why bother pretending
> one is going to?  Just git mv net/rxrpc fs/afs/ and merge everything
> through your tree.
> 
> I feel similarly about net/9p, net/sunrpc and net/ceph.  Every filesystem
> comes with its own presentation layer; nobody reuses an existing one.
> Just stop pretending they're separate components.

The IBM/OpenAFS rxrpc implementation has been used for many services
other than afs3 over the past 37 years within institutions that had
source code access.  rxrpc provides a light-weight rpc layer capable of
pluggable per-service security classes.  It offers optional end-to-end
authentication, integrity protection and wire privacy.

The existence of Linux rxrpc as a socket family means that it can be
used to implement not only clients for AFS and AuriStorFS services
beyond the fileserver but also the location service, protection service,
backup service, etc.  The rxrpc socket family could also be used to
implement the servers.

The linux rxrpc implementation does not yet have all of the
functionality of the AuriStor RX implementation but it is fast.  Unlike
every other RX implementation, the Linux rxrpc doesn't process packets
through both UDP and RX.  To achieve the same performance as Linux rxrpc
the AuriStor userland RX must leverage DPDK.

It is my hope that as Linux rxrpc continues to improve and is built into
kernels by more distributions that it will see wider use.  It is a
perfect match for IoT.

Jeffrey Altman