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

[Ricardo Labiaga]

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?

For example, the locking policy differs significantly between the client
and the server:

In v4.1, the callback can arrive over an existing open connection.  A
reply over the same connection needs to obey the existing client locking
policy for the transport in order to avoid clobbering other accesses to
the connection.  This involves calling xprt_reserve_xprt() to serialize
write access.  After it is done transmitting, it calls
xprt_release_xprt.  We serialize on the state field of the rpc_xprt
structure. This locking policy is very different from that of the
server.

The server uses nfssvc.c:svc_process() to reply to RPC requests.  This
serializes access to the socket by grabbing the sk_mutex of the
svc_sock. As a side note, the v4 callback mechanism was able to reuse
the server's  nfssvc.c:svc_process() because it has exclusive access to
the connection.

The solution we took in 2.6.18 mirrors some of the logic in the server
but uses the client's transport mechanism and locking policies.  This
could be cleaned up to allow other transports to be used and moved
forward to 2.6-latest.  Obviously this perpetuates the differences
accessing the underlying transport by client and server.  Is this a
problem we want/ need to fix?  Is there interest in merging the
transport mechanisms?  Ideas on how this can be done?

Thanks,

- ricardo