That article had a number of flaws and many concluded it was more of a defensive marketing piece than anything else.
In any case, as noted you can share a CQ to reduce the number of CQ being managed but it isn't free. Whenever you share something, it comes with a price and in the case of CQs, one must design the software to understand the degree of sharing and how post completion processing must comprehend. There are pros and cons for non-shared and shared CQ just as there is another set for regular QP and SRQ. The value to use one over the other is entirely application specific.
Mike
At 12:19 PM 8/28/2008, Dotan Barak wrote:
On Thu, Aug 28, 2008 at 10:13 PM, Adrien Guillon <[EMAIL PROTECTED]> wrote:
> I still allocate a separate CQ for each QP right?
You may use a separate CQ for each QP, if this is what you want (or
you can use one CQ for all of those QPs).
>
> Also, I read
>
> http://www.hpcwire.com/features/17886984.html
>
> the author mentions doom and gloom for scalability. Is this just fear
> mongering, or is this a real problem? If I use SRQ's am I in the
> clear for scalability?
Sorry, but i didn't read this article before and i don't have the time
to do it now. But SRQ is an object which helps you create more
scalable SW:
if you have N QPs, and every QP may get M messages; in the past you
had to post N*M WRs (M WRs to every QP). When using a SRQ, you can
post much less WRs and SRQ is easier to manage because you can use the
LIMIT event to know how many RR there are in the SRQ (QP don't have
this feature).
Dotan
>
> Thanks.
>
> AJ
>
_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
_______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
