[PATCH 2/2] nvmet-rdma: implement get_queue_size controller op
Sagi Grimberg
sagi at grimberg.me
Wed Sep 22 02:18:15 PDT 2021
>>> So for now, as mentioned, till we have some ib_ API, lets set it to 128.
>> Please just add the proper ib_ API, it should not be a whole lot of
>> work as we already do that calculation anyway for the R/W API setup.
>
> We don't do this exact calculation since only the low level driver knows
> that number of WQEs we need for some sophisticated WR.
>
> The API we need is like ib_get_qp_limits when one provides some input on
> the operations it will issue and will receive an output for it.
>
> Then we need to divide it by some factor that will reflect the amount of
> max WRs per NVMe request (e.g mem_reg + mem_invalidation + rdma_op +
> pi_yes_no).
>
> I spoke with Jason on that and we decided that it's not a trivial patch.
Can't you do this in rdmw_rw? all of the users of it will need the
exact same value right?
> is it necessary for this submission or can we live with 128 depth for
> now ? with and without new ib_ API the queue depth will be in these sizes.
I am not sure I see the entire complexity. Even if this calc is not
accurate, you are already proposing to hard-code it to 128, so you
can do this to account for the boundaries there.
More information about the Linux-nvme
mailing list