From: Flavio Baronti <f.baronti-ngIpsMLAhaq41k5uCYKmRQ@public.gmane.org>
To: "linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: ibv_req_notify_cq and multithreading
Date: Fri, 13 Jan 2012 09:10:01 +0100 [thread overview]
Message-ID: <4F0FE6D9.4050403@list-group.com> (raw)
In-Reply-To: <1828884A29C6694DAF28B7E6B8A8237325676B8F-P5GAC/sN6hmkrb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
Il 1/12/2012 16:52 PM, Hefty, Sean ha scritto:
>> I'm trying to have N threads reading from the same completion channel, bounded
>> to M completion queues. I would like to
>> have N<< M, and to ensure that only a single thread at time can call
>> ibv_poll_cq() on a given queue, to process the
>> events in the same order they were put in the queue.
>>
>> I can't understand how to properly achieve this, since:
>> 1- If I call ibv_req_notify_cq() before ibv_poll_cq(), I might end up with two
>> threads polling the same queue.
>> 2- If I call ibv_req_notify_cq() after ibv_poll_cq(), I could end up with
>> events in the cq not being notified in the
>> channel (I read this on the IBTA 11.4.2.2, and I *think* I actually
>> experienced this under load).
>>
>> I can use option 1 with an additional lock before ibv_req_notify_cq(), but I
>> would like to know if there is a simpler
>> way which I can't see.
>
> I can't think of a simpler way. You just don't have any idea which CQ will be returned from the completion channel. Does your traffic pattern work to create N completion channels and distributed the CQs among them?
> --
Each CQ is related to a separate connection; putting two on the same channel, and making a single thread read the
channel, would force an arbitrary coupling between connections which I'm trying to avoid.
Point 2 is correct though? ibv_req_notify_cq() should be called before ibv_poll_cq()?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2012-01-13 8:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-12 11:34 ibv_req_notify_cq and multithreading Flavio Baronti
[not found] ` <4F0EC562.2040709-ngIpsMLAhaq41k5uCYKmRQ@public.gmane.org>
2012-01-12 15:52 ` Hefty, Sean
[not found] ` <1828884A29C6694DAF28B7E6B8A8237325676B8F-P5GAC/sN6hmkrb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
2012-01-13 8:10 ` Flavio Baronti [this message]
[not found] ` <4F0FE6D9.4050403-ngIpsMLAhaq41k5uCYKmRQ@public.gmane.org>
2012-01-13 16:37 ` Hefty, Sean
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F0FE6D9.4050403@list-group.com \
--to=f.baronti-ngipsmlahaq41k5ucykmrq@public.gmane.org \
--cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.