From: Boaz Harrosh <[EMAIL PROTECTED]> Subject: Re: [PATCHSET 0/5] Peaceful co-existence of scsi_sgtable and Large IO sg-chaining Date: Tue, 24 Jul 2007 13:01:34 +0300
> FUJITA Tomonori wrote: > > From: Boaz Harrosh <[EMAIL PROTECTED]> > > Subject: [PATCHSET 0/5] Peaceful co-existence of scsi_sgtable and Large IO > > sg-chaining > > Date: Tue, 24 Jul 2007 11:47:50 +0300 > > > >> As Jens said, there is nothing common to scsi_sgtable and > >> sglists. Save the fact that it is a massive conflict at > >> scsi-ml. They touch all the same places. > >> > >> Proposed is a simple way out. Two patchsets That produce the > >> same output at the end. > >> > >> One: scsi_sgtable_than_sg-chaining > >> Two: sg-chaining_than_scsi_sgtable > > > > Hmm, I thought that I've already posted a scsi_sgtable patch working > > with sg-chaining together. > > > > http://marc.info/?l=linux-scsi&m=118519987632758&w=2 > > > > I quoted from my mail: > > > > --- > > I think that the main issue of integrating sgtable and sglist is how > > to put scatterlist to scsi_sgtable structure. > > > > If we allocate a scsi_sgtable structure and sglists separately, the > > code is pretty simple. But probably it's not the best way from the > > perspective of performance. > > > I was just answering your other mail when this came in so I'll answer > here. > This Approach is exactly the scsi_data_buffer approach we both > had solutions for. At the time I was all for that approach because it > is safer and could be kept compatible to old drivers. (Less work for > me) But it was decided against it. So suggesting it again is plain > going back. Well, the approach to shuffle the entire request setup around was rejected. But was the approach to use two data buffers for bidi completely rejected? > > If we put sglists into the scsi_sgtable structure (like Boaz's patch > > does) and allocate and chain sglists only for large I/Os, we would > > have the better performance (especially for small I/Os). But we will > > have more complicated code. > > Only that my proposed solution is more simple more elegant and more > robust than even Jens's solution without any sgtable at all. Actually > the sgtable does good to chaining. scsi_lib with sglist+sgtable is > smaller than Jens's sglist by itself. Your patch chains sgtables instead of sglists. It uses more memory for simple code. But I think that it's a nice approach. - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
