[openib-general] max_send_sge < max_sge
Michael S. Tsirkin
mst at mellanox.co.il
Wed Jun 28 07:51:02 PDT 2006
Quoting r. Pete Wyckoff <pw at osc.edu>:
> Subject: Re: max_send_sge < max_sge
>
> mst at mellanox.co.il wrote on Wed, 28 Jun 2006 01:38 +0300:
> > If this works for you, great. I was just trying to point out query device
> > can not guarantee that QP allocaton will always succeed even if you stay
> > within limits it reports.
> >
> > For example, are you using a large number of WRs per QP as well? If so
> > after alocating a couple of QPs you might run out of locked memory limit
> > allowed per-user, depending on your system setup. QP allocation will then
> > fail, even if you use the hcacap - 1 heuristic.
>
> Thanks for all the comments. I'm not specifically trying to be a
> pain here. The bit I was failing to notice was that when
> considering many QP allocations, the resource demands add up faster
> when using more SGEs each. Still find it odd that the very first
> QP created can not achieve the maximum-reported values, but
> understand your general argument.
Yea, that's because the API only can report 1 max value. But when
this was considered the concensus was its not worth extending the API
because of the other issues you mention.
> Regarding the API, some interfaces I've seen will do the equivalent
> of putting the "max currently available" values in ibv_qp_init_attr
> so userspace can reconsider and try again. I never liked that very
> much, and it doesn't help much in this multi-dimensional space where
> WRs and SGEs apparently share the same overall constraints. Plus
> the returned values aren't guaranteed to be valid next time an
> attempt is made anyway, so don't do that. :)
Yep. We could have an option to have the stack scale the requested values down
to some legal set instead of failing an allocation. But we couldn't come up
with a clean way to tell the stack e.g. what should it round down: the SGE or
WR value. Do you think selecting something arbitrarily might still be a good
idea?
So in the end we are back to either using low numbers that just work
empirically, or starting with some value and going down till it succeeds.
--
MST
More information about the general
mailing list