On Wed, Mar 16, 2022 at 12:57:27PM +0530, Kanchan Joshi wrote:
> So what is the picture that you have in mind for struct io_uring_cmd?
> Moving meta fields out makes it look like this -
> @@ -28,7 +28,10 @@ struct io_uring_cmd {
> u32 cmd_op;
> u16 cmd_len;
> u16 unused;
> - u8 pdu[28]; /* available inline for free use */
> + void __user *meta_buffer; /* nvme pt specific */
> + u32 meta_len; /* nvme pt specific */
> + u8 pdu[16]; /* available inline for free use */
> +
> };
> And corresponding nvme 16 byte pdu - struct nvme_uring_cmd_pdu {
> - u32 meta_len;
> union {
> struct bio *bio;
> struct request *req;
> };
> void *meta; /* kernel-resident buffer */
> - void __user *meta_buffer;
> } __packed;
No, I'd also move the meta field (and call it meta_buffer) to
struct io_uring_cmd, and replace the pdu array with a simple
void *private;
> We would still need to use/export that even if we somehow manage to move
> task-work trigger from nvme-function to blk_mq_complete_request.
> io_uring's task-work infra is more baked than raw task-work infra.
> It would not be good to repeat all that code elsewhere.
> I tried raw one in the first attempt, and Jens suggested to move to baked
> one. Here is the link that gave birth to this interface -
> https://lore.kernel.org/linux-nvme/6d847f4a-65a5-bc62-1d36-52e222e3d142@xxxxxxxxx/
Ok. I can't say I'm a fan of where this is going.
