> i see some people have been working with rx, so i thought i would > ask (again) why RX_MAX_FRAGS cant be increased to 6 instead of 4. > as it stands, with RX_MAX_FRAGS = 4, the largest datagram will be > about 5688. on our network, the physical mtu is 9234.
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 is already 9234, so maxMTU will be capped by RX_MAX_PACKET_SIZE, which is 16384, rather than by RX_MAX_FRAGS*ifMTU = 36936. And since RX_MAX_DGRAM_PACKETS is 6 by default, with 3.5 jumbograms you should get ~1444*6=8664 bytes of payload per packet, which is pretty close to your MTU. 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. To actually answer your question, I think the current version of Rx should deal properly with an increased RX_MAX_FRAGS. (The ifMTU/maxMTU values are exchanged in Ack packets, and that code claims to have been there since 3.3.) -- kolya _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
