Date: Tue, 4 Mar 2008 10:35:37 +0100
From: Jens Axboe <jens.axboe@oracle.com>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: htejun@gmail.com, tomof@acm.org, James.Bottomley@HansenPartnership.com,
       efault@gmx.de, akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
       linux-ide@vger.kernel.org, linux-scsi@vger.kernel.org,
       jgarzik@pobox.com, bzolnier@gmail.com
Subject: Re: [PATCH] block: fix residual byte count handling
Message-ID: <20080304093536.GH6704@kernel.dk>
References: <20080304175302T.fujita.tomonori@lab.ntt.co.jp> <20080304085944.GG6704@kernel.dk> <20080304180648W.fujita.tomonori@lab.ntt.co.jp> <20080304182228Z.fujita.tomonori@lab.ntt.co.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20080304182228Z.fujita.tomonori@lab.ntt.co.jp>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3318
Lines: 69

On Tue, Mar 04 2008, FUJITA Tomonori wrote:
> On Tue, 04 Mar 2008 18:06:48 +0900
> FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:
> 
> > On Tue, 4 Mar 2008 09:59:46 +0100
> > Jens Axboe <jens.axboe@oracle.com> wrote:
> > 
> > > On Tue, Mar 04 2008, FUJITA Tomonori wrote:
> > > > On Tue, 04 Mar 2008 11:32:56 +0900
> > > > Tejun Heo <htejun@gmail.com> wrote:
> > > > 
> > > > > FUJITA Tomonori wrote:
> > > > > >> Yeah, libata did its own padding and needed to add draining.  Private
> > > > > >> implementation was complex as hell and James suggested moving them to
> > > > > >> block layer.  Are you suggesting moving them back to drivers?
> > > > > > 
> > > > > > No, I'm not. I've been working on the IOMMUs to remove such
> > > > > > workarounds in LLDs.
> > > > > > 
> > > > > > What drivers need to do on this is just adding a padding length, that
> > > > > > is, drivers don't need to change the structure of the sg list (like
> > > > > > splitting a sg entry), right? And it doesn't break the SAS drivers
> > > > > > that support SATAPI, does it?
> > > > > > 
> > > > > > But I agree that drivers want to get a complete sglist so I'm fine
> > > > > > with adjusting sglist entries in the block layer with your secode
> > > > > > patch (separate out padding from alignment). As we discussed, I'm fine
> > > > > > with breaking sum(sg) == rq->data_len as long as rq->data_len means
> > > > > > the true data length.
> > > > > 
> > > > > As long as the second patch is in, what value rq->data_len indicates
> > > > > doesn't matter to drivers which don't use explicit padding or draining,
> > > > > so the situation is much more controlled.  I don't care which value
> > > > > rq->data_len would indicate.  I'd prefer it equal sum(sg) as that value
> > > > > is what IDE and libata which will be the major users of padding and/or
> > > > > draining expect in rq->data_len but fixing up that shouldn't be too
> > > > > difficult.  I guess this can be determined by Jens.  If Jens likes
> > > > > rq->data_len to contain requested transfer size, I'll post updated patches.
> > > > 
> > > > OK, I prefer rq->data_len means the true data length though you prefer
> > > > rq->data_len means the allocated buffer length (the true data length
> > > > plus padding and drain). We agree on other things. We can live with
> > > > either way.
> > > > 
> > > > Jens, what's your preference?
> > > 
> > > I completely agree with you, ->data_len meaning true data length is way
> > > cleaner imho. Only the driver should care for the padded length, all
> > > other parts of the kernel only need to know what they actually got.
> > 
> > OK, now we can fix the whole SG_IO (and bsg handler) mess.
> > 
> > Here's my patch with a proper description. which several people have
> > already tested (thanks!). Then we need an updated version of Tejun's
> > separate out padding from alignment patch.
> 
> OK, I've updated his patch. Tejun, can you audit this?

Looks excellent to me, has a variant of this been tested as OK by the
users reporting the regression?

-- 
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/