diff mbox series

tcm_loop: Increase maximum request size

Message ID 20220929115504.23806-1-ntsironis@arrikto.com (mailing list archive)
State New, archived
Headers show
Series tcm_loop: Increase maximum request size | expand

Commit Message

Nikos Tsironis Sept. 29, 2022, 11:55 a.m. UTC
Increase the maximum request size for tcm_loop, by setting sg_tablesize
to SG_MAX_SEGMENTS.

The current value of 256 for sg_tablesize limits the request size to
PAGE_SIZE * 256, which for 4K pages is 1MiB.

Signed-off-by: Nikos Tsironis <ntsironis@arrikto.com>
---
 drivers/target/loopback/tcm_loop.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Bart Van Assche Oct. 2, 2022, 9:09 p.m. UTC | #1
On 9/29/22 04:55, Nikos Tsironis wrote:
> Increase the maximum request size for tcm_loop, by setting sg_tablesize
> to SG_MAX_SEGMENTS.
> 
> The current value of 256 for sg_tablesize limits the request size to
> PAGE_SIZE * 256, which for 4K pages is 1MiB.
> 
> Signed-off-by: Nikos Tsironis <ntsironis@arrikto.com>
> ---
>   drivers/target/loopback/tcm_loop.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/target/loopback/tcm_loop.c b/drivers/target/loopback/tcm_loop.c
> index 4407b56aa6d1..6d7c3ebd8613 100644
> --- a/drivers/target/loopback/tcm_loop.c
> +++ b/drivers/target/loopback/tcm_loop.c
> @@ -308,7 +308,7 @@ static struct scsi_host_template tcm_loop_driver_template = {
>   	.eh_device_reset_handler = tcm_loop_device_reset,
>   	.eh_target_reset_handler = tcm_loop_target_reset,
>   	.this_id		= -1,
> -	.sg_tablesize		= 256,
> +	.sg_tablesize		= SG_MAX_SEGMENTS,
>   	.max_sectors		= 0xFFFF,
>   	.dma_boundary		= PAGE_SIZE - 1,
>   	.module			= THIS_MODULE,

There is more that can be improved for this driver, namely removal of 
the dma_boundary parameter and increasing max_sectors.

Thanks,

Bart.
Nikos Tsironis Oct. 12, 2022, 2:19 p.m. UTC | #2
On 10/3/22 00:09, Bart Van Assche wrote:
> On 9/29/22 04:55, Nikos Tsironis wrote:
>> Increase the maximum request size for tcm_loop, by setting sg_tablesize
>> to SG_MAX_SEGMENTS.
>>
>> The current value of 256 for sg_tablesize limits the request size to
>> PAGE_SIZE * 256, which for 4K pages is 1MiB.
>>
>> Signed-off-by: Nikos Tsironis <ntsironis@arrikto.com>
>> ---
>>   drivers/target/loopback/tcm_loop.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/target/loopback/tcm_loop.c b/drivers/target/loopback/tcm_loop.c
>> index 4407b56aa6d1..6d7c3ebd8613 100644
>> --- a/drivers/target/loopback/tcm_loop.c
>> +++ b/drivers/target/loopback/tcm_loop.c
>> @@ -308,7 +308,7 @@ static struct scsi_host_template tcm_loop_driver_template = {
>>       .eh_device_reset_handler = tcm_loop_device_reset,
>>       .eh_target_reset_handler = tcm_loop_target_reset,
>>       .this_id        = -1,
>> -    .sg_tablesize        = 256,
>> +    .sg_tablesize        = SG_MAX_SEGMENTS,
>>       .max_sectors        = 0xFFFF,
>>       .dma_boundary        = PAGE_SIZE - 1,
>>       .module            = THIS_MODULE,
> 
> There is more that can be improved for this driver, namely removal of the dma_boundary parameter and increasing max_sectors.
> 
Hi Bart,

Thanks for the feedback!

Should I make these changes as part of this patch, or can I leave them for a
follow up patch?

Thanks,
Nikos
Bart Van Assche Oct. 12, 2022, 4:32 p.m. UTC | #3
On 10/12/22 07:19, Nikos Tsironis wrote:
> Should I make these changes as part of this patch, or can I leave them for a
> follow up patch?

A (thoroughly tested) follow-up patch is probably better.

Thanks,

Bart.
Nikos Tsironis Dec. 7, 2022, 10:29 a.m. UTC | #4
Hello,

This is a kind reminder for this patch. Do you require any changes to
merge it?

Nikos
Mike Christie Dec. 7, 2022, 6:29 p.m. UTC | #5
On 9/29/22 6:55 AM, Nikos Tsironis wrote:
> Increase the maximum request size for tcm_loop, by setting sg_tablesize
> to SG_MAX_SEGMENTS.
> 
> The current value of 256 for sg_tablesize limits the request size to
> PAGE_SIZE * 256, which for 4K pages is 1MiB.
> 
> Signed-off-by: Nikos Tsironis <ntsironis@arrikto.com>
> ---
>  drivers/target/loopback/tcm_loop.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/target/loopback/tcm_loop.c b/drivers/target/loopback/tcm_loop.c
> index 4407b56aa6d1..6d7c3ebd8613 100644
> --- a/drivers/target/loopback/tcm_loop.c
> +++ b/drivers/target/loopback/tcm_loop.c
> @@ -308,7 +308,7 @@ static struct scsi_host_template tcm_loop_driver_template = {
>  	.eh_device_reset_handler = tcm_loop_device_reset,
>  	.eh_target_reset_handler = tcm_loop_target_reset,
>  	.this_id		= -1,
> -	.sg_tablesize		= 256,
> +	.sg_tablesize		= SG_MAX_SEGMENTS,
>  	.max_sectors		= 0xFFFF,
>  	.dma_boundary		= PAGE_SIZE - 1,
>  	.module			= THIS_MODULE,

I think you need to make this configurable.

If you use loop with pscsi, then the sgl that loop now gets might be too
big for the backend device so we now fail in:

pscsi_map_sg -> blk_rq_append_bio -> ll_back_merge_fn

So some users might be relying on the smaller limit.
Christoph Hellwig Dec. 7, 2022, 6:35 p.m. UTC | #6
On Wed, Dec 07, 2022 at 12:29:56PM -0600, Mike Christie wrote:
> I think you need to make this configurable.
> 
> If you use loop with pscsi, then the sgl that loop now gets might be too
> big for the backend device so we now fail in:
> 
> pscsi_map_sg -> blk_rq_append_bio -> ll_back_merge_fn
> 
> So some users might be relying on the smaller limit.

Note that this could happen even now, you just need sufficiently
horrible hardware to pass through for it.  But yes, for pscsi
this needs to look at the underlying device, and increasing the
limit might be a good point to do that.  I'm not sure it's worth
to add user configuration, though.
Nikos Tsironis Dec. 19, 2022, 2:39 p.m. UTC | #7
On 12/7/22 20:35, Christoph Hellwig wrote:
> On Wed, Dec 07, 2022 at 12:29:56PM -0600, Mike Christie wrote:
>> I think you need to make this configurable.
>>
>> If you use loop with pscsi, then the sgl that loop now gets might be too
>> big for the backend device so we now fail in:
>>
>> pscsi_map_sg -> blk_rq_append_bio -> ll_back_merge_fn
>>
>> So some users might be relying on the smaller limit.
> 
> Note that this could happen even now, you just need sufficiently
> horrible hardware to pass through for it.  But yes, for pscsi
> this needs to look at the underlying device, and increasing the
> limit might be a good point to do that.  I'm not sure it's worth
> to add user configuration, though.

Thanks for the feedback.

What should I do? Change pscsi to look at the underlying device limits?

Nikos
Mike Christie Dec. 19, 2022, 6:49 p.m. UTC | #8
On 12/19/22 8:39 AM, Nikos Tsironis wrote:
> On 12/7/22 20:35, Christoph Hellwig wrote:
>> On Wed, Dec 07, 2022 at 12:29:56PM -0600, Mike Christie wrote:
>>> I think you need to make this configurable.
>>>
>>> If you use loop with pscsi, then the sgl that loop now gets might be too
>>> big for the backend device so we now fail in:
>>>
>>> pscsi_map_sg -> blk_rq_append_bio -> ll_back_merge_fn
>>>
>>> So some users might be relying on the smaller limit.
>>
>> Note that this could happen even now, you just need sufficiently
>> horrible hardware to pass through for it.  But yes, for pscsi
>> this needs to look at the underlying device, and increasing the
>> limit might be a good point to do that.  I'm not sure it's worth
>> to add user configuration, though.
> 
> Thanks for the feedback.
> 
> What should I do? Change pscsi to look at the underlying device limits?

Yes. I think there might be 2 things to do here:

1. SCSI VPD values.

I think we would do something similar to iblock_configure_device
where when we setup the device we look at the underlying device's limits
and then set the se_device's limits. Those values then get reported to
the initiator in the VPD info, so that would be useful for normal drivers
like iscsi and FC.

For the max segments there's not a SCSI VPD value, but we have this code:

        /*
         * Set MAXIMUM TRANSFER LENGTH
         *
         * XXX: Currently assumes single PAGE_SIZE per scatterlist for fabrics
         * enforcing maximum HW scatter-gather-list entry limit
         */
        if (cmd->se_tfo->max_data_sg_nents) {
                mtl = (cmd->se_tfo->max_data_sg_nents * PAGE_SIZE) /
                       dev->dev_attrib.block_size;
        }
        put_unaligned_be32(min_not_zero(mtl, dev->dev_attrib.hw_max_sectors), &buf[8]);

which would limit the IO size. max_data_sg_nents is only currently a fabric
driver (front end drivers like iscsi, fc, etc) limit, so we would need to make
that more generic so backends like pscsi can set it.


2. For loop we have the sg_tablesize setting like you saw, but the problem is
that it's host level and we don't know the devices when we add the host.

I think we would have to modify tcm_loop_port_link so if adds the device
successfully, we call blk_queue_max_segments.

Christoph is that what you were thinking?
Christoph Hellwig Dec. 21, 2022, 8:30 a.m. UTC | #9
> Christoph is that what you were thinking?

Yes.
diff mbox series

Patch

diff --git a/drivers/target/loopback/tcm_loop.c b/drivers/target/loopback/tcm_loop.c
index 4407b56aa6d1..6d7c3ebd8613 100644
--- a/drivers/target/loopback/tcm_loop.c
+++ b/drivers/target/loopback/tcm_loop.c
@@ -308,7 +308,7 @@  static struct scsi_host_template tcm_loop_driver_template = {
 	.eh_device_reset_handler = tcm_loop_device_reset,
 	.eh_target_reset_handler = tcm_loop_target_reset,
 	.this_id		= -1,
-	.sg_tablesize		= 256,
+	.sg_tablesize		= SG_MAX_SEGMENTS,
 	.max_sectors		= 0xFFFF,
 	.dma_boundary		= PAGE_SIZE - 1,
 	.module			= THIS_MODULE,