[OpenAFS-devel] Bad AFS performance over wide area due to packet fragmentation problems

[Derrick Brashear]

On Mon, Aug 25, 2008 at 5:56 PM, Harald Barth <haba@kth.se> wrote:
>> > I run with -nojumbo and with RX_MAX_FRAG patched to 1.
>>
>> The fact that you had to set RX_MAX_FRAG to 1 in order to make -nojumbo
>> work was a bug that has now been fixed.
>
> If that is what "-nojumbo" was supposed to do, what is it called when you
> stuff (or do not stuff) serveral (small) rx-packets into one UDP packet?

Well, the issue was the number of fragments allowed in a packet (which
for n > 1 is a jumbogram) was initialized from a macro, always,
instead of to the reduced value set in global (rx) variables when
-nojumbo was given.

Effectively this meant in those cases -nojumbo did not disable jumbograms.

What I would like to see is simple large packet support; Regardless of
path mtu, doing so would be no less likely to work (note that I did
not say no worse) than today. However, I feel that unless we can work
out path mtu discovery on more platforms, allowing this would be
detrimental. The only compromise would be to rework the "mtu
advertising" code we have now:

Default behavior: no jumbograms, no large datagrams.
Override with -jumbo: allow jumbograms, fall back to old behavior
Supported pmtu discovery: allow large datagrams up to max mtu if
discovered mtu is same or greater than the max advertised mtu.

Note that this would potentially allow one side supporting pmtu to
transmit large datagrams while the other side might need to transmit
only non-jumbogram single fragment packets in reply.