[OpenAFS-devel] datagrams really arent big enough?

[Default]

> In message <200011080134.UAA22208@oo.yi.org>,Default writes:
> i wouldnt call using adb tunable.  i believe increasing MAX_RX_FRAGS would
> solve my packet size problem and not cause any problems with older clients.
> rx wont negotiate a packet sizer bigger than your interface mtu.  and i 
> will say it again, with MAX_RX_FRAGS set to 4, you wont see packets bigger
> than ~5700.  if should be safe to increase MAX_RX_FRAGS -- i believe it
> was an oversite when 'jumbograms' were implemented.  no one could possibly
> have a an mtu larger than fddi right?

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?

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.

That said, do I think it's a good idea to add heuristic not to trash the cache 
when sequentially reading a file > cache size.  The way to do it is to add a 
couple of bits in the afs inode to represent the number of contiguous chunks 
read to date, and the identity of the last chunk read. Then for chunks > "n", 
you add the chunk into the LRU queue at some offset from the "wrong" end of 
the queue, where the offset varies by what the chunk number is (so you do 
still get some locality of reference for small-scale hunting around within a 
chunk).

I even dimly recall some mention of exactly this functionality already being 
present in the NT client.