[Stgt-devel] [PATCH 03/20] iser transport buf

[Pete Wyckoff]

tomof at acm.org wrote on Mon, 12 Nov 2007 23:14 +0900:
> On Tue, 16 Oct 2007 11:18:57 -0400
> Pete Wyckoff <pw at osc.edu> wrote:
> 
> > For RDMA, it is often nice to use data from a pool of pre-registered
> > buffers.  To do this, the transport allocates memory for a response and
> > passes it down to the devices to fill.  Some operations, though,
> > allocate their own buffers and return that new memory instead.  These
> > are usually small and the allocation is just done for convenience to
> > avoid length bounds checking.  Copy the data into the provided transport
> > buffer instead.
> 
> I killed memory allocation in scsi device code (spc, mmc, sbc, smc)
> and kill all the hacky memory management code. Now LLDs allocate and
> free buffer for data transfer.

But now you need two mallocs per command:  one for the task and one
for the (aligned) data.  Bidi needs three.  This will show up in
iser performance, but might be a worthwhile trade-off.  Maybe we
could add slabs for common sizes (ick).

I have a lot of rebasing to do after all your bidi buffer work.  It
looks like good changes so far, but I have a couple of concerns from
a brief peruse of the changes in git.

Zeroing out the data chunk for non-READ/WRITE commands.  There are
lots of OSD commands hidden inside the 0x7f extended format, and
other non-OSD non-SBC commands too.  Can we just move the zeroing to
where it is needed?  Like in each of the inquiry, etc.  This zeroing
was a major performance problem for iser.

Accessor and setter functions for scmd.  I don't see what value they
add.  Except maybe for the "(void*)(unsigned long)" ones.  Also,
building functions using cpp to glue names together breaks things
like ctags, cscope, and diff -p.  Curious to hear why you like them.

Thanks for working on this.  Bidi handling in bs_* will be much
cleaner now.  I'll be away from email until 25 nov, but will look at
your changes in detail and rebase iser after.

		-- Pete