9fans archive / 1998 / 01 / 40 /    prev next

From: G. David Butler gdb@dbS...
Subject: [9fans] negotiation of 9P blocksize
Date: Wed, 28 Jan 1998 20:32:02 -0600

>From: beto@ncu...
>
>We are tired of people complaining, and then not wanting to use
>import/exportfs, becuase of the 8K blocksize in the plan9 9P
>implementation

What exactly is the complaint?  Too little overhead?  Too much overhead
for small messages?  Do they want to go bigger or smaller?

>we already moved exportfs into the kernel to bypass some copies), so

Do you move a lot of data between cpu/terminal systems with cpu/termianl
systems as file servers?  Why don't you have each cpu/terminal connect to
the file server itself?

You must have some special environment to move a user process into
the kernel!

>Our idea is to create two new opcodes Tnattach/Rnattach which an extra argument
>blocksize which  represents what the client wants to do a what the server is
>able to do. 
>
>          Tnattach    tag[2]  fid[2]   uid[28]   aname[28]   ticket[72] auth[13] blocksize[4]
>          Rnattach    tag[2] fid[2] qid[8] rauth[13]  rblocksize[4]

So the assumption is that the server either accepts the size the client
requests or responds with Rerror and the client has to accept 8k.  If you
are going to do it, perhaps the Tnattach should include a list?

>Any comments would be appreciate?

I can only assume that you want the blocksize larger since you could
simply configure the client kernel to send and request smaller amounts
of data.  (in 9P the counts are specified in both directions.)  So how
big do they want it?

I always assumed it was as large as 8k because of the custom fiber
interconnect bell labs created would allow it.  It would seem the
overhead so many fragments on ethernet would make a smaller size
more efficient?

David Butler
gdb@dbS...