[OpenAFS-devel] datagrams really arent big enough?

Default aeneous@speakeasy.org
Tue, 07 Nov 2000 20:34:43 -0500


> In message <200011071227.HAA21048@oo.yi.org>,Default writes:
> >1. try again with 3.6 - rx is summat different now.
> 
> i dont believe there is a different.  openafs clients talking to my modified
> afs servers dont use every use a packet size bigger than ~5700.

OK, I believe you.  I don't have 3.5 sources to diff against.

> >2. did you measure performance before and after?  I wouldn't think you'd see 
> >much more than a couple of percent better transfer rates.
> 
> well you wont exactly see a performance difference.  the real bottleneck
> is really the cache.  however, i would like to see my mtu size put to use.
> eventually we will take care of the cache speed problem.  we are looking
> into a 'cache bypass' for 'certain' files.  its certainly more efficient to
> recv 1 packet instead of 2.

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.

> >The reason PACKET_SIZE is apparently "too large" is to permit changing 
> >MAX_FRAGS on the fly, and still be compatible with all the other clients & 
> >servers in your network.  It wasn't an oversight.
> 
> however MAX_FRAGS isnt large enough to ever take advantage of the PACKET_SIZE
> with a value of 4, the biggest packet you will ever see if something like
> ~5700.  clients and server negotiate the size of packets to be used (based
> on the interface mtu among other things)  MAX_FRAGS seems to limit the 
> upper end of packet sizes.

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.