All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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.