Re: Should queue_max_hw_sectors() always be <= max_dev_sectors?

[Jens Axboe <axboe@kernel.dk>]

On 08/30/2016 08:15 PM, Martin K. Petersen wrote:
>>>>>> "Andy" == Andy Grover <agrover@redhat.com> writes:
>
> Hey Andy,
>
> Andy> ...because limits.max_hw_sectors internally seems to be just the
> Andy> controller limit, but what users of queue_max_hw_sectors
> Andy> (including sysfs) really want is the lesser of
> Andy> limits.max_hw_sectors and limits.max_dev_sectors.
>
> max_dev_sectors is a limit reported by the target device for
> READ/WRITE/VERIFY requests. Whereas max_hw_sectors describes the DMA
> constraints of the controller.
>
> It is a requirement for SG_IO, firmware updates, tape drives, etc. that
> the controller limits are reported correctly since they do I/Os that are
> much bigger than typical filesystem requests. When we tried to conflate
> the two things broke in interesting ways.

That's crazy. If max_hw_sectors_kb is expected to be the DMA constraint,
then it makes no sense to name it 'sectors'. We currently have the one
exported constraints, and making it anything but the 'this is the
maximum IO size we can support' would be nonsensical.

> I can't remember why the max_dev_sectors sysfs export patch didn't go
> in. But instead (or in addition) we could entertain having a
> max_rw_sectors_kb file that reflects the biggest READ/WRITE/VERIFY
> request the device can consume if that's the information you're after?

Which, coincidentally, is what that file already is for most other
devices. It'd make more sense to bring SCSI into this realm, instead of
imposing this weird world view on others. We export max_segments and
max_segments_size, which are basically a window into what the DMA engine
can do.

-- 
Jens Axboe