jumbo (was Re: [OpenAFS] Documenting the recommended fileserver options)
Dan Pritts
danno@internet2.edu
Mon, 28 Feb 2011 12:46:59 -0500
Thanks for the explanation, Simon. The man page wasn't entirely clear =
on that point.
A jumbogram is a
large-size packet composed of 2 to 4 normal Rx data packets =
that
share the same header. The fileserver does not use jumbograms =
by
default, as some routers are not capable of properly breaking =
the
jumbogram into smaller packets and reassembling them.
can we add this from your message to the man page? I'll send a patch to =
the bugs address if
you think it's a good idea.
> jumbograms deliberately exceed the MTU of the path, typically by 4 =
times, in order to get better performance. Fragmented packets are =
actually more efficient in our RX implementation than having to process =
more single packets.=20
Jumbograms=20
On Feb 28, 2011, at 11:07 AM, Simon Wilkinson wrote:
>=20
> On 28 Feb 2011, at 14:31, Dan Pritts wrote:
>=20
>> On Feb 24, 2011, at 8:03 PM, Jason Edgecombe wrote:
>>> fileserver -L -udpsize 131071 -sendsize 131071 -rxpck 700 -p 128 -b =
600 -nojumbo -cb 1500000
>>=20
>> I was curious about jumbogram support so i went to read the man page.
>>=20
>> The man page suggests that if your router does not support =
fragmenting of packets, jumbo won't work for clients without jumbo =
support. Does this mean there is no path mtu discovery support in the =
fileserver? not that that is without issues, of course.
>=20
> 1.6 has path discovery for some operating systems. Derrick can say =
more about how complete it is, but I think there are issues for some of =
our cache managers.
>=20
> However, path MTU discovery doesn't actually buy you that much. It can =
only tell you the maximum packet size that can be passed unfragmented =
between the RX endpoints. jumbograms deliberately exceeds the MTU of the =
path, typically by 4 times, in order to get better performance =
(fragmented packets are actually more efficient in our RX implementation =
than having to process more single packets). Path discovery doesn't tell =
you anything about whether these packets will be successfully passed, or =
dropped on the floor.
danno
--
Dan Pritts, Sr. Systems Engineer
Internet2
office: +1-734-352-4953 | mobile: +1-734-834-7224