[OpenAFS-devel] datagrams really arent big enough?

[Chas Williams]

In message <200011080134.UAA22208@oo.yi.org>,Default writes:
>With MAX_FRAGS=1, the bottleneck is rx.  
>Better than a total cache bypass would be a more efficient cache filling 
>mechanism, so data doesn't have to get copied around all the time, and perhaps
>some way of discarding dirty UFS pages without ever writing them to the cache 
>at all.  Then you wouldn't need to hack at deciding which files should be 
>cached and which shouldn't.

it would be a worthwhile effort to fix the caching scheme.  but i see a
possible benefit to bypassing the cache completely for large files (i.e.
>> larger cache size) espc if you are just reading them once.  they tend
to flush all the other files out of the cache.  i could be wrong.  optimizing
the cache would be great but is currently beyond my understanding of afs.

>Yes, that's what I was trying to say, however ineffectively...  It does limit 
>the upper end of packet sizes, but it's tunable at runtime (well, the global 
>variable which it initializes), which was an intentional choice.  
>MAX_PACKET_SIZE is not tunable at runtime.

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?