Re: [PATCH] spraid: initial commit of Ramaxel spraid driver

[Bart Van Assche <bvanassche@acm.org>]

On 11/5/21 6:02 AM, Yanling Song wrote:
> We've studied BSG and in general it can work.
> 
> The following is our draft design, please give your comments:
> 1. Applications from user space send commands to driver thru struct
> sg_io_v4, the private data(used by driver) is saved in sg_io_v4->request
> and the data length is saved in sg_io_v4->request_len.
> 
> 2. SG_IO is used in bsg_ioctl(), the following has to be set because
> bsg_transport_check_proto() will check the fields:
>      sg_io_v4->protocol = BSG_PROTOCOL_SCSI;
>      sg_io_v4->subprotocol = BSG_SUB_PROTOCOL_SCSI_TRANSPORT;
> 
> Does the above match the BSG design?

I think so. Sample user space code that submits to a BSG interface is
available e.g. here:
https://github.com/westerndigitalcorporation/ufs-utils/blob/dev/scsi_bsg_util.c

> And one question:
> The number of queue and queue depth are hardcoded in bsg_setup_queue().
>         set->nr_hw_queues = 1;
>         set->queue_depth = 128;
> 
> Any reason to do it? how about it does not match the chip's capability?
> for example, the chip supports 8 hardware queues and each queue depth
> is 4096?

Will BSG commands be processed internally by the spraid driver or will these
be sent to the hardware queues?

If there is a need in the spraid driver for concurrent processing of BSG
commands, feel free to make nr_hw_queues and/or queue_depth configurable.
I recommend to do this by introducing a new structure (bsg_creation_params?)
and by passing a pointer to that data structure to bsg_setup_queue().

Thanks,

Bart.