On Fri, 5 Nov 2021 09:13:55 -0700 Bart Van Assche <bvanassche@xxxxxxx> wrote: > 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 > Thanks. We will start coding as the above discussion. > > 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(). > We're not sure if current hardcoded queue and queue depth can meet our requirement or not now. Will update it later. > Thanks, > > Bart.
