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

[Benny Halevy]

Trond Myklebust wrote:
> 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.

I wish I had better insight into the code but I really hope
we can somehow get to the state that the code is shared
gradually rather than in an "all or nothing" project approach.

For example, even if the overall design is different on the server
vs. the client, I'd still look for opportunities to refactor the
existing server code so that the common parts can reused rather than
copied.  Of course the trade off should be weighed for each use case
but let's try to keep our minds open about it.

Benny

> 
> 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
>>>
> _______________________________________________
> pNFS mailing list
> pNFS at linux-nfs.org
> http://linux-nfs.org/cgi-bin/mailman/listinfo/pnfs