[OpenAFS-devel] datagrams really arent big enough?

[Chas Williams]

In message <200011082252.RAA24509@oo.yi.org>,Default writes:
>No, ATM was already out there (heck, ATM was 10 years old by then), SONET was 
>already out there, the SP2's switch was already out there.  Oh, maybe that was
>only an 8KB MTU. Don't the comments in the .h files mention these?

how about that, there is a comment in there:

/*  some sample MTUs
           4352   what FDDI(RFC1188) uses... Larger?
           4096   VJ's recommendation for FDDI
          17914   what IBM 16MB TR  uses
           8166   IEEE 802.4
           4464   IEEE 802.5 MAX
           2002   IEEE 802.5 Recommended
           1500   what Ethernet uses
           1492   what 802.3 uses ( 8 bytes for 802.2 SAP )
           9180   Classical IP over ATM (RFC2225)
*/

we actually run lan emulation but its essentially the same size as classical ip.
i usually get a lot of strange looks when i mention that our mtu size is 9k.

>It wasn't an oversight, it just didn't matter. Perhaps it matters now, but 
>you can't jump to conclusions about performance-related issues.

i am not really jumping to conclusions.  i have run my modified version of
3.6 in a production environment for over a year w/o seeing any problems.
RX_MAX_FRAGS needs to be bigger than 4!  yes, this might use a little more
memory on your server and clients but if you are using larger mtu's i should
think that you expect this behavior.  as for one of your previous statements:

>4. kicking up the max packet size also increases the max receive window, I 
>think, increases the memory requirements of the server, and increases the 
>amount of data that must be resent in the event of a packet loss, so you might 
>(probably not, but maybe) have actually reduced performance slightly.

using a larger packet wont increase the max recv window size.  that's a 
different issue entirely.  additionally, since rx has been improved lately
(with congestion control, slow start, etc)  it should be able to throttle
back in the case that packets are lost.

and yes, this does improve performance only slightly (and only if you
have an mtu size greater than ~5k) since the bottlenecks tend to be
elsewhere but its a step forward.  RX_MAX_FRAGS need to be 11, which is
how many frags will fit into MAX_RX_PACKET_SIZE