[ofa-general] infiniband multicast (libibverbs)

[Devesh Sharma]

Correction in my post :  I mean you are not considering it as non-blocking
call (not taking care of this behaviour) and just going ahead with the
sequence number check?

On 11/5/08, Devesh Sharma <devesh28 at gmail.com> wrote:
>
> are you taking care that ibv_poll_cq is not a blocking call, I mean you are
> not considering it as blocking call and just going ahead with the sequence
> number check?
>
> On 11/5/08, Kelly Burkhart <kelly at tradebotsystems.com> wrote:
>>
>>
>>
>> > -----Original Message-----
>> > From: Roland Dreier [mailto:rdreier at cisco.com]
>> >
>> >  > If I specify more than about 6500 messages/sec, I skip
>> > some sequences
>> >  > and receive others multiple times.  I always receive the
>> > same number of
>> >  > messages the client sent.  It appears as though all of the
>> > messages come
>> >  > through, but I'm missing some and reading others twice.
>> >
>> > Sounds like a bug in your code -- I don't know why you would see
>> > duplicate messages unless you are somehow processing the same receive
>> > buffer twice or something like that.
>>
>> I am (or was) processing the same buffer over and over.  I ripped
>> from ib_send_lat which does the same thing.  The difference is
>> send_lat waits for a reply before sending a second message.  I'm
>> sending rapidly without waiting for a reply.  The surprising thing
>> to me was that my recv buffer received data ahead of me waiting on
>> the cq.
>>
>> I modified my code to read into a circular list of buffers which
>> appears to have solved the problem at the cost of more memory usage.
>>
>> Thanks,
>>
>> -K
>> _______________________________________________
>> general mailing list
>> general at lists.openfabrics.org
>> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
>>
>> To unsubscribe, please visit
>> http://openib.org/mailman/listinfo/openib-general
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20081105/477214b0/attachment.html>