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

[Labiaga, Ricardo]

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? 

- 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
>