linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Boaz Harrosh <boaz@plexistor.com>
To: Christoph Hellwig <hch@infradead.org>,
	Bart Van Assche <bart.vanassche@sandisk.com>
Cc: "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH 0/17] Clear up bidi command confusion
Date: Thu, 29 Jan 2015 15:00:15 +0200	[thread overview]
Message-ID: <54CA2EDF.7060405@plexistor.com> (raw)
In-Reply-To: <20150123131249.GA8045@infradead.org>

On 01/23/2015 03:12 PM, Christoph Hellwig wrote:
> On Fri, Jan 23, 2015 at 01:05:30PM +0100, Bart Van Assche wrote:
>> There is some confusion in the SCSI core and in SCSI LLDs around the
>> meaning of sc_data_direction and whether or not this member can have the
>> value DMA_BIDIRECTIONAL. Clear up this confusion. The patches in this
>> series are:
> 
> I wonder if we should change the code to set DMA_BIDIRECTIONAL for
> bidi commands.  That seems a lot more logical than the current
> version.
> 

You cannot do this. Because a Bidi Command is actually two commands
one for the WRITE side (DMA_TO_DEVICE) which is this one, and another
command for the READ side (DMA_FROM_DEVICE).

The DMA_XXX_ enum must not to be confused with the t10-scsi Bidi commands.
In DMA world the enum means: What are the allowed access on the memory buffer,
is Device allowed to read-from-memory-only or write-to-memory-only or both
simultaneously "on the same buffer".
It is a flag to the IO-mmu on the direction of its mappings.

A t10-scsi bidi command is "two buffers". The command caries two distinct
buffers one is only-written-to 2nd only-read-from. But these are two distinct
buffers each his proper direction.

If you ask me you need to remove sc_data_direction all together and just
go directly to the READ/WRITE flag at request level. SCSI has no business
duplicating the same information in another member another way.

In any way t10-scsi has no use in the entire of its STD of the DMA_BIDIRECTIONAL
sense. ie. same buffer, two directional access. So DMA_BIDIRECTIONAL is just
dead code for sc_data_direction. It could be imagined but t10-scsi does not
have a use for it.

Again Not to be confused with one-command two buffers, which is exactly the opposite.

> Also I don't think all the debug checks for bidi commands that you
> change should stay at all - driver need to set the QUEUE_FLAG_BIDI to
> ever see a bidi command.
> 

Exactly just remove the all checks.

> It would also nice to add a host template flag for bidi support instead
> of having to poke into the block layer request_queue while we're at it.

Cheers
Boaz



  parent reply	other threads:[~2015-01-29 13:00 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-23 12:05 [PATCH 0/17] Clear up bidi command confusion Bart Van Assche
2015-01-23 12:06 ` [PATCH 01/17] Clear up sc_data_direction documentation Bart Van Assche
2015-01-23 12:06 ` [PATCH 02/17] Clean up scsi_ioctl_reset() Bart Van Assche
2015-01-23 12:07 ` [PATCH 03/17] sg: Remove an unused variable Bart Van Assche
2015-01-23 12:30   ` Douglas Gilbert
2015-01-23 12:07 ` [PATCH 04/17] dpt_i2o: Fix bidi command test Bart Van Assche
2015-01-23 12:08 ` [PATCH 05/17] aachba: " Bart Van Assche
2015-01-23 12:08 ` [PATCH 06/17] eata: Remove dead code Bart Van Assche
2015-01-23 12:09 ` [PATCH 07/17] sbp2: Fix bidi command test Bart Van Assche
2015-01-23 14:05   ` Stefan Richter
2015-01-23 12:10 ` [PATCH 08/17] ibmvscsi: " Bart Van Assche
2015-01-27 22:10   ` Tyrel Datwyler
2015-01-28  7:57     ` Bart Van Assche
2015-01-28 22:42       ` Tyrel Datwyler
2015-01-23 12:10 ` [PATCH 09/17] cciss: Remove dead code Bart Van Assche
2015-01-23 12:11 ` [PATCH 10/17] hpsa: " Bart Van Assche
2015-01-23 12:11 ` [PATCH 11/17] 3w-9xxx: " Bart Van Assche
2015-01-23 12:12 ` [PATCH 12/17] ncr53c8xx: Fix bidi command support Bart Van Assche
2015-01-23 12:13 ` [PATCH 13/17] qla1280: " Bart Van Assche
2015-01-23 12:13 ` [PATCH 14/17] 53c700: Remove dead code Bart Van Assche
2015-01-23 12:14 ` [PATCH 15/17] mvumi: " Bart Van Assche
2015-01-23 12:15 ` [PATCH 16/17] sym_glue: Fix bidi command test Bart Van Assche
2015-01-23 12:17 ` [PATCH 17/17] IB/srp: Detect bidi commands properly Bart Van Assche
2015-01-25 16:58   ` Sagi Grimberg
2015-01-23 13:12 ` [PATCH 0/17] Clear up bidi command confusion Christoph Hellwig
2015-01-26  9:58   ` Bart Van Assche
2015-01-29 13:07     ` Boaz Harrosh
2015-01-29 13:20       ` Bart Van Assche
2015-01-29 14:43         ` Boaz Harrosh
2015-01-29 13:00   ` Boaz Harrosh [this message]
2015-01-29 14:41     ` James Bottomley
2015-01-29 14:56       ` Boaz Harrosh

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=54CA2EDF.7060405@plexistor.com \
    --to=boaz@plexistor.com \
    --cc=bart.vanassche@sandisk.com \
    --cc=hch@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).