[pnfs] Should v4.1 callbacks share NFS server code?

[Trond Myklebust]

On Thu, 2007-11-08 at 16:00 -0800, Labiaga, Ricardo wrote:
> Although it sounds like a good time to consider sharing code, it also
> sounds like a project onto itself.  It also would delay the v4.1
> callback functionality considerably.
> 
> Does a callback implementation that does not share code make sense as a
> first step? 

Yes.

Trond

> - ricardo
> 
> 
> > -----Original Message-----
> > From: Myklebust, Trond 
> > Sent: Thursday, November 08, 2007 2:17 PM
> > To: Labiaga, Ricardo
> > Cc: bfields at citi.umich.edu; Chuck.lever at oracle.com; pnfs at linux-nfs.org
> > Subject: Re: Should v4.1 callbacks share NFS server code?
> > 
> > 
> > On Thu, 2007-11-08 at 13:53 -0800, Ricardo Labiaga wrote:
> > > I've been looking at how we could reuse some or most of the server's
> > > nfssvc.c:svc_process() and friends in the processing of 
> > v4.1 callbacks
> > > in the client.  This seems to require non-trivial changes to the
> > > transport access and locking mechanisms in the client and/or server.
> > > 
> > > Are there any plans or has there been any talk about 
> > providing a common
> > > layer/ API to the server and client to access the transport 
> > through a
> > > common mechanism?
> > 
> > I haven't seen any serious proposals for it yet. I wouldn't be against
> > sharing more code between the client and server in this area, but do
> > realise that the current differences in design reflect the differences
> > in the priorities of the tasks they have to perform.
> > 
> > In essence, the goal of the client is to act as an asynchronous i/o
> > module. It attempts to shovel as much data to the socket from the NFS
> > layer and then shovel the reply back as fast as possible. Hence the
> > emphasis is on never blocking, and on being able to switch to handling
> > another RPC call if ever we need to block.
> > 
> > OTOH, the server is more concerned with being able to 
> > guarantee service.
> > It won't even process a request until it knows that it has enough send
> > buffer space on that particular socket in order to be able to return a
> > reply.
> > 
> > Trond
> >