[openib-general] Re: [PATCH] [SRP] support for it_iu length negotiation

[Ken Jeffries]

Roland,

It's not clear to me which part(s) of the patch you don't like so I apologize
if some of this is not relevant.

The SRP-1 spec calls for iu size negotiation during login so not allowing
iu size negotiation would be a bug in terms of spec compliance. I think there
are valid reasons why iu size negotiation should be in the spec.

I am sure that for a particular application and network that there is an optimum
iu size (a Goldilocks size, neither too small nor too large). I suspect that a
small iu will be better for small file or maybe small record database i/o and
a large iu will be better for video serving. A server that has lots of cheap
memory and perhaps an aversion to implementing the full indirect memory
descriptor capability may be happy with very large iu's. An embedded system
server with only modest memory may really need to not waste memory in
permanently allocated big iu's that go largely unused.  

While I'm sure that there will be an optimum size iu for any particular application'
and network I'm equally sure I don't know what that size is right now and I won't
know what it is before we do considerable performance testing.  

Any particular srp client may connect to more than one srp server and those servers
(and applications) may have different needs. One might be a video server and
another might be a db server. 

Having the iu size set in a compile time variable in the srp client is less flexible
than what we, at least, would like to see.

When we were considering how to get both smaller iu's and to implement the real
indirect memory descriptor capability it occurred to us that allowing the Linux side
iu's to be sized by the existing compile time variable but making the on-the-wire
iu size set by negotiation was an almost trivial extension to the existing code.

By doing that applications can see a potentially large scatter/gather list length (a
function of the client internal iu size) but the srp target also gets only what it wants. Since
the indirect table memory descriptor just points to the descriptor list in the client
side iu and since the "partial" list of descriptors in the on-the-wire iu is just a
copy of the first descriptors in the client side iu, indirect descriptor setup and 
operation is easy.  

Regards,
Ken Jeffries


----- Original Message ----- 
From: "Roland Dreier" <rolandd at cisco.com>
To: "John Kingman" <kingman at storagegear.com>
Cc: <openib-general at openib.org>
Sent: Monday, October 31, 2005 11:00 PM
Subject: [openib-general] Re: [PATCH] [SRP] support for it_iu length negotiation


> Thanks for the patch.  However, I would like to hold off on new
> features for the SRP driver to get it merged into 2.6.15.  There's
> about another week in the 2.6.15 merge window, so either way the delay
> shouldn't be too long.
> 
> With that said I don't think I like this patch.  I don't think it's a
> win to allocate 1 KB IUs when we'll almost never have gather/scatter
> lists that big.  Even the 256 byte IUs that the current driver uses
> seem on the borderline of being too big.
> 
> Also, is it really a win to have the target fetch a large indirect
> buffer list?  It seems like it would be better for performance to give
> the SCSI layer a limit on the size of the gather/scatter list we
> support so that our indirect buffer lists always fit in the IUs we send.
> 
>  - R.
> _______________________________________________
> openib-general mailing list
> openib-general at openib.org
> http://openib.org/mailman/listinfo/openib-general
> 
> To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general