[PATCH 2/2] nvme-rdma: sqsize/hsqsize/hrqsize is 0-based val

[daniel.verkamp@intel.com (Verkamp, Daniel)]

On Mon, 2016-08-08@09:06 +0200, Christoph Hellwig wrote:
> On Sun, Aug 07, 2016@10:29:08AM +0300, Sagi Grimberg wrote:
> > 
> > Did we really decide that? The spec actually explicitly says
> > that a 0 sqsize will be failed:
> > 
> > "If the size is 0h or larger than the controller supports, then a
> > status value of Connect Invalid Parameters shall be returned."
> > 
> > And then it says: "This is a 0?s based value"
> > 
> > Confusing....
> 
> Yeah, I think we'll need an errate in the TWG.??And I think the
> current Linux behavior is the sensible one.??Jay, do you want
> to drive this in the WG or I should I bring it up?

I would be happy if all of the 0's based values in the spec were
removed, but I think it's a little too late for that...

In this particular case, I'm pretty sure this is not a mistake; the
relevant text is copied directly from the NVMe base spec Create I/O
Submission Queue command's QSIZE parameter.

What does need to be clarified is the RDMA transport definition. ?The
Connect private data contains two queue size-related fields:

- HSQSIZE, which is supposed to be the RDMA QP send depth, but also says
"shall be set to the Submission Queue Size (SQSIZE)", while not saying
whether it is 0's based.
- HRQSIZE, which is the QP receive depth, which has no equivalent like
SQSIZE in the Connect command, and also does not mention being 0's
based.

These should hopefully both be 0's based or both not 0's based, but
right now, I have no idea what the intent of the spec is.

Thanks,
-- Daniel