[OpenAFS-devel] RX_MAX_FRAGS (yet again)

[chas williams]

In message <200109281919.PAA08698@pepsi-one.mit.edu>,Nickolai Zeldovich writes:
>I'm not sure RX_MAX_FRAGS is what you want to raise in this case.
>As far as I can tell, RX_MAX_FRAGS tells Rx that it can send packets
>that many times larger than the interface MTU.  In your case the MTU

i believe RX_MAX_FRAGS is the number of 'datagrams' to put in a 
jumbogram (a jumbogram just contains a bunch of 'regular' datagrams)

>is already 9234, so maxMTU will be capped by RX_MAX_PACKET_SIZE, which
>is 16384, rather than by RX_MAX_FRAGS*ifMTU = 36936.

RX_MAX_PACKET_SIZE is one of the limiting factors; however, not the
one that is in my way (now).

>Of course, if you have ethernet cards in those machines too, your
>global rx_maxReceiveSize will be reduced to ~4*1444 and you'll only
>advertise a 5692 maxMTU.  Similarly, any hosts talking to your ATM
>fileservers from an ethernet network will only advertise a 5692 maxMTU.

i really dont think that this is the case with the rx code as is.
just checking with rxdebug, one of the peers that doesnt have an active
ethernet (it has an ethernet, its never configed up) shows:

Peer at host 134.207.10.21, port 7001
        ifMTU 8524      natMTU 1444     maxMTU 5692

the native lane mtu is 9234 and ideally maxMTU would be ifMTU.
and even on a linux host, which doesnt even have an ethernet 
interface in the kernel table shows:

Peer at host 134.207.10.8, port 7001
        ifMTU 8524      natMTU 1444     maxMTU 5692

so, by observation, maxMTU seems to be limited to rx_maxReceiveSize even
WITHOUT an ethernet interface. 

rx_maxReceiveSize could grow to beyond ~4*1444, but the rx code seems
to take the min of max_packet_size or maxmtu and maxmtu is constructed
from rxi_nRecvFrags which is initialized to RX_MAX_FRAGS:

	maxmtu = rxmtu * rxi_nRecvFrags + ((rxi_nRecvFrags-1) * UDP_HDR_SIZE);

again, i will say RX_MAX_FRAGS is limiting my maxMTU size.  after
recompiling with RX_MAX_FRAGS = 6 the maxMTU is righteous.