[PATCH v3 1/4] nvmet-rdma: +1 to *queue_size from hsqsize/hrqsize

[J Freyensee]

On Wed, 2016-08-17 at 21:36 +0300, Sagi Grimberg wrote:
> > 
> > > 
> > > > 
> > > >  	/*
> > > > -	 * req->hsqsize corresponds to our recv queue size
> > > > -	 * req->hrqsize corresponds to our send queue size
> > > > +	 * req->hsqsize corresponds to our recv queue size
> > > > plus 1
> > > > +	 * req->hrqsize corresponds to our send queue size
> > > > plus 1
> > > >  	 */
> > > > -	queue->recv_queue_size = le16_to_cpu(req->hsqsize);
> > > > -	queue->send_queue_size = le16_to_cpu(req->hrqsize);
> > > > +	queue->recv_queue_size = le16_to_cpu(req->hsqsize) +
> > > > 1;
> > > > +	queue->send_queue_size = le16_to_cpu(req->hrqsize) +
> > > > 1;
> > > 
> > > I brought this up on the nvme-technical list and the consensus is
> > > that hrqsize doesn't use the one off notation.  hsqsize refers to
> > > the sqsize which is marked as "0's based", while hrqsize only
> > > has a short and not very meaningful explanation, which implies
> > > that
> > > it's '1's based' in NVMe terms (which, btw I think are utterly
> > > misleading).
> > 
> > OK, so what is the final verdict then?  Resurrect patch five again
> > and
> > resubmit the series?  It makes hrqsize 1-based on both the host and
> > target.
> > http://lists.infradead.org/pipermail/linux-nvme/2016-August/005804.
> > html
> 
> I think you can just make the target take hrqsize as is in patch 1
> and have the host send hrqsize = queue->queue_size.
> 
> One more respin should do it (sorry for the exhaustion ;))

No worries, doesn't help when the spec isn't clear on something :-).