Re: [RFC,PATCH 5/14] knfsd: max_payload per transport

[Greg Banks <gnb@sgi.com>]

On Thu, May 17, 2007 at 08:34:10PM +1000, Neil Brown wrote:
> On Thursday May 17, gnb@sgi.com wrote:
> > 
> > Make svc_max_payload() delegate to a new method in svc_sock_ops
> > instead of reaching into the socket (beause later the NFS/RDMA
> > transport will not even have a socket).
> > 
> > Signed-off-by: Greg Banks <gnb@melbourne.sgi.com>
> > Signed-off-by: Peter Leckie <pleckie@melbourne.sgi.com>
> ..
> >  
> > +static u32 svc_tcp_max_payload(struct svc_sock *svsk)
> > +{
> > +	return RPCSVC_MAXPAYLOAD_TCP;
> > +}
> > +
> 
> Seeing these are implementation (or protocol) defined constants, do we
> really need a function call?  How about a
> 	int max_payload;
> in struct svc_sock_ops?? 

These ones are indeed constants, as is RDMA's.

> Or is it tacky to put an integer in a *_ops
> structure? 

No tackier than putting a string name like I did, or the things done
in tcp_congestion_ops or sock_request_ops.  It comes down to whether
you want to allow future protocols to have variable limits, and right
now that seems unnecesssary.

I'll change the field to an int.

Greg.
-- 
Greg Banks, R&D Software Engineer, SGI Australian Software Group.
Apparently, I'm Bedevere.  Which MPHG character are you?
I don't speak for SGI.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs