]> CyberLeo.Net >> Repos - FreeBSD/FreeBSD.git/commit
Modify the way the client side krpc does soreceive() for TCP.
authorrmacklem <rmacklem@FreeBSD.org>
Sun, 21 Jun 2020 00:06:04 +0000 (00:06 +0000)
committerrmacklem <rmacklem@FreeBSD.org>
Sun, 21 Jun 2020 00:06:04 +0000 (00:06 +0000)
commitab0b2f3a9ed34b404e941622869c1a4c23f0644a
treecaa160422fce4a4af4be4dd9f1fd010ca016a831
parentcf2dc6a9cc4e424d47fe7b04063a372a189aa5c3
Modify the way the client side krpc does soreceive() for TCP.

Without this patch, clnt_vc_soupcall() first does a soreceive() for
4 bytes (the Sun RPC over TCP record mark) and then soreceive(s) for
the RPC message.
This first soreceive() almost always results in an mbuf allocation,
since having the 4byte record mark in a separate mbuf in the socket
rcv queue is unlikely.
This is somewhat inefficient and rather odd. It also will not work
for the ktls rx, since the latter returns a TLS record for each
soreceive().

This patch replaces the above with code similar to what the server side
of the krpc does for TCP, where it does a soreceive() for as much data
as possible and then parses RPC messages out of the received data.
A new field of the TCP socket structure called ct_raw is the list of
received mbufs that the RPC message(s) are parsed from.
I think this results in cleaner code and is needed for support of
nfs-over-tls.
It also fixes the code for the case where a server sends an RPC message
in multiple RPC message fragments. Although this is allowed by RFC5531,
no extant NFS server does this. However, it is probably good to fix this
in case some future NFS server does do this.
sys/rpc/clnt_vc.c
sys/rpc/krpc.h