From: Dmitriy Bogdanov <d.bogdanov@yadro.com>
To: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>,
Chris Leech <cleech@redhat.com>, Lee Duncan <lduncan@suse.com>
Cc: open-iscsi <open-iscsi@googlegroups.com>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
Konstantin Shelekhin <k.shelekhin@yadro.com>,
"linux@yadro.com" <linux@yadro.com>
Subject: RE: Antw: [EXT] Re: [PATCH] scsi: iscsi: prefer xmit of DataOut before new cmd
Date: Fri, 10 Jun 2022 10:12:19 +0000 [thread overview]
Message-ID: <09cecc56ea2041dd8ccfafcba180f907@yadro.com> (raw)
In-Reply-To: <62A2E054020000A10004ACA8@gwsmtp.uni-regensburg.de>
Hi Ulrich,
> In my primitive point of view iSCSI is just "another type of cable", making me wonder:
> Is iSCSI allowed to reorder the requests at all? Shouldn't the block layer or initiator do
> so, or the target doing out-of order processing (tagged queueing)?
iSCSI RFC does not require to serialize a commands flow. It's just an "iSCSI user" feature -
to send some set of SCSI commands in an unbreakable batch to a device.
But, as far as I understood, the problem, Mike described, is not a reorder but an increasing
of time between full data transmission of the commands from the batch.
> I mean: If there is a problem that occurs even without using iSCSI, should iSCSI try to fix it?
Since that is software iSCSI specific issue it could be fixed/improved in software. How it's handled in
HW offloaded implementation is unknown for me.
BR,
Dmitry
next prev parent reply other threads:[~2022-06-10 10:12 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-07 13:19 [PATCH] scsi: iscsi: prefer xmit of DataOut before new cmd Dmitry Bogdanov
2022-06-07 15:55 ` Mike Christie
2022-06-07 16:06 ` Mike Christie
2022-06-08 14:16 ` Dmitriy Bogdanov
2022-06-08 15:36 ` Mike Christie
2022-06-09 6:56 ` Antw: [EXT] " Ulrich Windl
2022-06-09 9:02 ` Dmitriy Bogdanov
2022-06-09 20:58 ` Mike Christie
2022-06-10 6:10 ` Antw: [EXT] " Ulrich Windl
2022-06-10 10:12 ` Dmitriy Bogdanov [this message]
2022-06-10 11:52 ` Dmitriy Bogdanov
2022-06-15 15:37 ` Mike Christie
2022-06-15 18:57 ` Adam Hutchinson
2022-06-17 5:54 ` Antw: [EXT] " Ulrich Windl
2022-06-22 2:10 ` Martin K. Petersen
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=09cecc56ea2041dd8ccfafcba180f907@yadro.com \
--to=d.bogdanov@yadro.com \
--cc=Ulrich.Windl@rz.uni-regensburg.de \
--cc=cleech@redhat.com \
--cc=k.shelekhin@yadro.com \
--cc=lduncan@suse.com \
--cc=linux-scsi@vger.kernel.org \
--cc=linux@yadro.com \
--cc=open-iscsi@googlegroups.com \
/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