[openib-general] Re: [RFC] IB_AT_MOST

[Michael S. Tsirkin]

Quoting r. Fab Tillier <ftillier at silverstorm.com>:
> Subject: RE: [RFC] IB_AT_MOST
> 
> Hi Michael,
> 
> > From: Michael S. Tsirkin [mailto:mst at mellanox.co.il]
> > Sent: Friday, December 16, 2005 5:58 AM
> > 
> > Hi!
> > I recently noted that some middleware seems to use the "as much
> > as possible" approach, for example, using maximum possible value
> > for max_rd_atomic or other fields, in create/modify qp.
> > 
> > An obvious thing could be to perform query_device and use max.
> > values from there. However, it turns out that hardware max supported
> > values might not be easy to express in terms of a single constant.
> > Consider for example the max number of s/g entries supported per
> > WQE: mellanox HCAs support different number of these for RC and UD
> > QPs. So whatever single number query device reports, using it will
> > never achieve what the user wants for all QP types.
> > 
> > Rather than extending the device query for all thinkable hardware
> > weirdness, I'd like to propose, instead, the following API extension
> > (below): passing a negative value in e.g. qp attribute would have the
> > meaning: let hardware use at most the specified value.
> > This, as opposed to the usual "at least the specified value" meaning
> > for positive values.
> > 
> > How does the following work, for an API? Please comment.
> 
> I don't understand the IB_AT_MOST macro.  If someone uses IB_AT_MOST( 1) and
> the hardware supports 4, they will get 4, which is definitely not "at most 1".

Yes, but we could easily fix this in the hardware provider so that they get 1.

> I would rename it to IB_MAX, and define it a -1 or something like that.

This is an option, too.

-- 
MST