From: Chuck Lever <chucklever@gmail.com>
To: Robbert Eggermont <R.Eggermont@tudelft.nl>
Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: RPC UDP message size limit
Date: Mon, 4 Jun 2018 11:49:16 -0400 [thread overview]
Message-ID: <347E80FE-C62C-4724-9187-650EEBBE6AE0@gmail.com> (raw)
In-Reply-To: <776808b0-82d2-18ae-8abb-471db6d6e02d@tudelft.nl>
> On Jun 4, 2018, at 11:26 AM, Robbert Eggermont =
<R.Eggermont@tudelft.nl> wrote:
>=20
>> 8KB seems to be a documented limit for UDP.
>=20
> I tried to find documentation for this limit, but all I found was one =
reference to SunOS (of course), because of incompatible network =
hardware.
The text I quoted you is from the Linux man page for clnt_create(3).
> The real limit (based on the 16-bit length field defined in RFC 768, =
1980) is 65507 bytes (plus headers, for UDP over IPv4).
That's the architectural limit. There's also a practical limit
that is much lower.
UDP datagrams have to be re-assembled from smaller frames. The IP
layer does that using a 16-bit ID header field and verifies the
re-assembly with a weak checksum. It's pretty easy to fool the
checksum by assembling the frames out of order, which can happen
if the ID header value wraps.
There are other problems that make UDP problematic for any RPC
program that relies on the datagram to contain the correct data
in the correct order.
To mitigate these problems, the maximum size of UDP frames is
reduced. IMO 8KB + a handful is about as large as we ever want to
go in the general case.
>> However, using TCP would immediately work around the UDP message size
>> limit. But perhaps the filer is not allowing a TCP connection for the
>> MNT service?
>=20
> TCP is not working for us at this moment (because of firewalling), so =
UDP is used as the fallback (as designed).
>=20
> In our case, I'ld rather have the fallback fail because of a real =
hardware incompatibility than of an artificial software limit... ;-)
Making a library change that impacts all RPC consumers is IMO
quite inappropriate, for the reason explained above. The
preferred way to address this is to increase the UDP message
size limit only for showmount.
>> IIUC showmount could use the clnt_{vc,dg}_create(3) APIs instead of
>> the generic clnt_create(3) API to specify a larger message size =
limit.
Can you try this suggestion and let us know if it's effective?
--
Chuck Lever
chucklever@gmail.com
prev parent reply other threads:[~2018-06-04 15:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-01 12:07 RPC UDP message size limit Robbert Eggermont
2018-06-01 16:11 ` Chuck Lever
2018-06-04 15:26 ` Robbert Eggermont
2018-06-04 15:49 ` Chuck Lever [this message]
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=347E80FE-C62C-4724-9187-650EEBBE6AE0@gmail.com \
--to=chucklever@gmail.com \
--cc=R.Eggermont@tudelft.nl \
--cc=linux-nfs@vger.kernel.org \
/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).