Re: remove blk_queue_max_phys_segments in libata

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Linux Kernel Mailing List wrote:
Gitweb:     http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8889e3c129780cdbe15fed3c366ba3aa3026684d
Commit:     8889e3c129780cdbe15fed3c366ba3aa3026684d
Parent:     fd820f405574a30aacf9a859886e173d641f080b
Author:     FUJITA Tomonori <[email protected]>
AuthorDate: Tue Sep 18 12:16:45 2007 +0200
Committer:  Jens Axboe <[email protected]>
CommitDate: Tue Oct 16 11:24:44 2007 +0200

    remove blk_queue_max_phys_segments in libata
LIBATA_MAX_PRD is the maximum number of DMA scatter/gather elements
    permitted by the HBA's DMA engine. It's properly set to
    q->max_hw_segments via the sg_tablesize parameter.
libata shouldn't call blk_queue_max_phys_segments. Now LIBATA_MAX_PRD
    is equal to SCSI_MAX_PHYS_SEGMENTS by default (both is 128), so
    everything is fine. But if they are changed, some code (like the scsi
    mid layer, sg chaining, etc) might not work properly.
(Addition from Jens) The basic issue is that the physical segment
    setting is purely a driver issue. And since SCSI is managing the sglist,
    libata has no business changing the setting. All libata should care
    about is the hw segment setting.
Signed-off-by: FUJITA Tomonori <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>
---
 drivers/ata/libata-scsi.c |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index d63c81e..ba62d53 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -801,8 +801,6 @@ int ata_scsi_slave_config(struct scsi_device *sdev)
ata_scsi_sdev_config(sdev); - blk_queue_max_phys_segments(sdev->request_queue, LIBATA_MAX_PRD);
-
 	sdev->manage_start_stop = 1;

As I noted when this first patch was posted... this line of code existed because the difference between hw-segments and phys-segments was incredibly difficult to discern. The names say basically the same thing to me, and I could find no documentation explaining the difference?

Does such documentation exist? If not, can you please explain the difference?

Finally, some notification and coordination would have been helpful. Commit 6c08772e49622e90d39903e7ff0be1a0f463ac86 appears to have been missed, at the very least... or is it actually correct?

Inquiring minds want to know, since I wasn't CC'd or kept in the loop :)

	Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux