From: Jens Axboe <axboe@suse.de>
To: Pat LaVarre <p.lavarre@ieee.org>
Cc: linux-scsi@vger.kernel.org
Subject: Re: bytes/CDB of SCSI pass thru grossly limited maybe
Date: Mon, 23 Aug 2004 19:08:27 +0200 [thread overview]
Message-ID: <20040823170827.GC24089@suse.de> (raw)
In-Reply-To: <4D36722F-F51E-11D8-BFA2-00039398BB5E@ieee.org>
On Mon, Aug 23 2004, Pat LaVarre wrote:
> Jens A:
>
> >>Is there an ide-cd option to allow more bytes/CDB?
> >...
> >ATAPI cannot do more than 128KiB per command. And
> >that is what q->max_sectors is set to, if you try and submit more than
> >this through SG_IO, bio_add_user() will complain and command will be
> >failed as you experienced.
>
> Wow.
>
> Please reply to confirm - you are saying 128 KiB data bytes per command
> is a Linux PATAPI design limit?
>
> I know even twelve-byte-packet PATAPI itself as defined at t13.org and
> t10.org can do xFFFF = (64 Ki - 1) LBA's via such ten-byte per CDB ops
> as x28 "READ (10)" and x2A "WRITE (10)". At 2 KiB/LBA, that's 128 MiB
> minus 2 KiB. That's the kind of limit I expected, when instead in
> Linux I saw limits like 120 KiB in SCSI over USB. Also I hear
> sixteen-byte-packet PATAPI can itself pass xFFFF:FFFF data blocks per
> command.
What you can shove into the cdb is of lesser interest than the fact that
ATAPI itself cannot do more than 128KiB _per command_.
> In parallel, I'll click thru to bio_add_user to read the limits there.
There are no extra limits there, it's just in the queue itself
(max_sectors, segments, etc).
> >As I'm sure you know,
>
> I didn't know, thank you, sorry I have no clue, I'm not trying to
> pretend I do, I got into this at the request of a friend who needs 256
> KiB data per command.
??? You must have some clue on the actual hardware, if you have been
working on the hardware side for many years :-)
> I specifically have Not yet tried patching the Linux kernel to persuade
> PATAPI to allow more data bytes per command. I did try USB. So far
> I've failed. At:
>
> Subject: [usb-storage] faq max_sectors
> https://lists.one-eyed-alien.net/pipermail/usb-storage/2004-August/
> 000680.html
>
> I have reported that raising SCSI_DEFAULT_MAX_SECTORS alone does not
> actually allow more data bytes per command in USB.
Ok, let me try to explain. There are several factors that limit how big
a command you can send to a device - some of these are hardware, some of
these are just imposed by the driver. If you look inside the
request_queue structure in blkdev.h, you'll find such things as:
unsigned short max_sectors;
unsigned short max_phys_segments;
unsigned short max_hw_segments;
unsigned int max_segment_size;
which are set by the driver and limit how big a request you can submit
through SG_IO.
--
Jens Axboe
next prev parent reply other threads:[~2004-08-23 17:08 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-30 23:04 bytes/CDB of SCSI pass thru grossly limited maybe Pat LaVarre
2004-07-31 14:12 ` Jens Axboe
2004-08-16 17:55 ` Pat LaVarre
2004-08-17 18:07 ` Pat LaVarre
2004-08-23 15:46 ` Jens Axboe
2004-08-23 16:05 ` Pat LaVarre
2004-08-23 17:08 ` Jens Axboe [this message]
2004-08-23 17:28 ` Pat LaVarre
2004-08-23 18:17 ` Jens Axboe
2004-08-26 23:20 ` Pat LaVarre
2004-08-23 16:06 ` Jeff Garzik
2004-08-23 17:05 ` Pat LaVarre
2004-08-23 18:48 ` Luben Tuikov
2004-08-23 19:06 ` Jeff Garzik
2004-08-23 19:14 ` Luben Tuikov
[not found] <A8E06BE4-F7BA-11D8-AC6B-00039398BB5E@ieee.org>
[not found] ` <Pine.LNX.4.44L0 .0408271100590.1238-100000@ida.rowland.org>
2004-08-27 15:09 ` Alan Stern
2004-08-28 14:31 ` Jens Axboe
2004-08-28 15:14 ` Alan Stern
2004-08-28 15:36 ` Jens Axboe
2004-08-28 17:51 ` James Bottomley
2004-08-28 17:55 ` Jens Axboe
2004-08-28 18:20 ` James Bottomley
2004-08-28 18:41 ` Jens Axboe
2004-08-29 13:34 ` James Bottomley
2004-08-29 13:45 ` Jens Axboe
2004-08-30 18:15 ` Pat LaVarre
2004-09-01 15:20 ` Pat LaVarre
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=20040823170827.GC24089@suse.de \
--to=axboe@suse.de \
--cc=linux-scsi@vger.kernel.org \
--cc=p.lavarre@ieee.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.