From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: Long Li <longli@microsoft.com>
Cc: Tom Yan <tom.ty89@gmail.com>,
"James E.J. Bottomley" <jejb@linux.vnet.ibm.com>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] sd: remove redundant check for BLK_DEF_MAX_SECTORS
Date: Mon, 06 Jun 2016 23:42:05 -0400 [thread overview]
Message-ID: <yq1vb1lmzqq.fsf@sermon.lab.mkp.net> (raw)
In-Reply-To: <BLUPR0301MB19724E7E002D1E47719D262CCE5A0@BLUPR0301MB1972.namprd03.prod.outlook.com> (Long Li's message of "Sat, 4 Jun 2016 15:18:43 +0000")
>>>>> "Long" == Long Li <longli@microsoft.com> writes:
Long,
Long> The reason is that, max_sectors already has value at this point,
Long> the default value is SCSI_DEFAULT_MAX_SECTORS
Long> (include/scsi/scsi_host.h). The lower layer host driver can change
Long> this value in its template.
The LLD sets max_hw_sectors which indicates the capabilities of the
controller DMA hardware. Whereas the max_sectors limit is set by sd to
either follow advise by the device or--if not provided--use the block
layer default. max_sectors governs the size of READ/WRITE requests and
do not reflect the capabilities of the DMA hardware.
Long> I think the drivers care about this value have already set it. So
Long> it's better not to change it again. If they want max_sectors to be
Long> set by sd, they can use BLOCK LIMITS VPD to tell it to do so.
Most drivers don't have the luxury of being able to generate VPDs for
their attached target devices :)
--
Martin K. Petersen Oracle Linux Engineering
next prev parent reply other threads:[~2016-06-07 3:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-04 3:57 [PATCH] sd: remove redundant check for BLK_DEF_MAX_SECTORS Long Li
2016-06-04 8:41 ` Tom Yan
2016-06-04 15:18 ` Long Li
2016-06-05 5:16 ` Tom Yan
2016-06-07 3:42 ` Martin K. Petersen [this message]
2016-06-08 4:22 ` Long Li
2016-06-09 3:29 ` 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=yq1vb1lmzqq.fsf@sermon.lab.mkp.net \
--to=martin.petersen@oracle.com \
--cc=jejb@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=longli@microsoft.com \
--cc=tom.ty89@gmail.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;
as well as URLs for NNTP newsgroup(s).