All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: James Bottomley <James.Bottomley@SteelEye.com>
Cc: Tejun Heo <htejun@gmail.com>,
	SCSI Mailing List <linux-scsi@vger.kernel.org>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: Regarding posted scsi midlyaer patchsets
Date: Tue, 19 Apr 2005 16:33:26 +0200	[thread overview]
Message-ID: <20050419143325.GL2827@suse.de> (raw)
In-Reply-To: <20050419142959.GK2827@suse.de>

On Tue, Apr 19 2005, Jens Axboe wrote:
> On Tue, Apr 19 2005, James Bottomley wrote:
> > On Tue, 2005-04-19 at 14:34 +0200, Jens Axboe wrote:
> > > On Mon, Apr 18 2005, Tejun Heo wrote:
> > > >  And, James, regarding REQ_SOFTBARRIER, if the REQ_SOFTBARRIER thing can
> > > > be removed from SCSI midlayer, do you agree to change REQ_SPECIAL to
> > > > mean special requests?  If so, I have three proposals.
> > > > 
> > > >  * move REQ_SOFTBARRIER setting to right after the allocation of
> > > > scsi_cmnd in scsi_prep_fn().  This will be the only place where
> > > > REQ_SOFTBARRIER is used in SCSI midlayer, making it less pervasive.
> > > >  * Or, make another API which sets REQ_SOFTBARRIER on requeue.  maybe
> > > > blk_requeue_ordered_request()?
> > > >  * Or, make blk_insert_request() not set REQ_SPECIAL on requeue.  IMHO,
> > > > this is a bit too subtle.
> > > > 
> > > >  I like #1 or #2.  Jens, what do you think?  Do you agree to remove
> > > > requeue feature from blk_insert_request()?
> > > 
> > > #2 is the best, imho. We really want to maintain ordering on requeue
> > > always, marking it softbarrier automatically in the block layer means
> > > the io schedulers don't have to do anything specific to handle it.
> > 
> > This is my preference too.  In general, block is the only one that
> > should care what the REQ_SOFTBARRIER flag actually means.  SCSI only
> > cares that it submits a non mergeable request.
> > 
> > I'm happy to separate the meaning of REQ_SPECIAL from req->special.
> 
> Isn't it just duplicate information anyways? I mean, just clear
> ->special if it isn't valid anymore. Having a seperate flag to indicate
> this seems a little suboptimal. It made more sense when ->cmd was a
> integer being READ, WRITE, etc. But as a seperate state now it doesn't.

Oh, and this is only true of SCSI, btw. REQ_SPECIAL should not be seen
outside of driver code, its meaning is defined solely by the driver.
SCSI ties it to ->special, but that is not necessarily true for any
other driver.

-- 
Jens Axboe


      reply	other threads:[~2005-04-19 14:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20050417224101.GA2344@htj.dyndns.org>
     [not found] ` <1113833744.4998.13.camel@mulgrave>
2005-04-18 14:58   ` Regarding posted scsi midlyaer patchsets Tejun Heo
2005-04-19 12:34     ` Jens Axboe
2005-04-19 14:18       ` James Bottomley
2005-04-19 14:30         ` Jens Axboe
2005-04-19 14:33           ` Jens Axboe [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050419143325.GL2827@suse.de \
    --to=axboe@suse.de \
    --cc=James.Bottomley@SteelEye.com \
    --cc=htejun@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.