Hi Maxim,

I don't pass any flags at the moment i.e. flags=0 at the time of 
odp_ring_create.

I did check the include/helper/odp_ring.h and it mentions --
*   An OR of the following:
 *    - RING_F_SP_ENQ: If this flag is set, the default behavior when
 *      using ``odp_ring_enqueue()`` or ``odp_ring_enqueue_bulk()``
 *      is "single-producer". Otherwise, it is "multi-producers".
 *    - RING_F_SC_DEQ: If this flag is set, the default behavior when
 *      using ``odp_ring_dequeue()`` or ``odp_ring_dequeue_bulk()``
 *      is "single-consumer". Otherwise, it is "multi-consumers".

So I suppose I am using multi-producers and multi-consumers, isn't it.
At any rate, I am using the functions explicitly which are internally called by 
the normal enq/deq functions
odp_ring_mp_enqueue_bulk [I am indeed a multi producer]
odp_ring_sc_dequeue_bulk  [I am indeed a single consumer]

Regards
-Prashant



-----Original Message-----
From: [email protected] 
[mailto:[email protected]] On Behalf Of Maxim Uvarov
Sent: Friday, August 22, 2014 2:38 PM
To: [email protected]
Subject: Re: [lng-odp] Regarding ODP rings in linux-generic

Hi Prashant,

do you pass flags to odp_ring_create that it's multi consumer, multi producer?

Maxim.

On 08/22/2014 12:12 PM, Prashant Upadhyaya wrote:
>
> Hi,
>
> I have a usecase where each core has a ring associated with it.
>
> Every core dequeues from its own ring - thus each core's ring above is
> representing the single consumer mode.
>
> Every core can enqueue to every other core's ring - thus each core's
> ring above is representing the multi-producer mode.
>
> To enqueue, I use odp_ring_mp_enqueue_bulk
>
> To dequeue, I use odp_ring_sc_dequeue_bulk
>
> I try to enqueue in a loop till the enqueue succeeds, the idea being
> that the other cores will dequeue eventually to create space on the
> ring. I use fixed size rings.
>
> Now when I run my usecase, which has a lot of pipelining between
> cores, I see that sometimes the code, which is enqueueing on a ring,
> blocks in the loop i.e. its enqueue never succeeds.
>
> If I use my own locks to protect the enqueue and dequeue on a given
> core's ring, then my usecase works fine.
>
> Now then, I have not yet been able to get to the bottom of this and
> can't exactly put a finger on where the bug lies in the ring
> framework, but the fact that my own external locking vanishes the
> problem, I am inclined to believe that there seems to be some race
> condition in rings implementation when there are multi producers and a
> single consumer.
>
> I am not getting enough time to run some standalone stress tests to
> reproduce the above issue in a controlled environment for further
> debugging.
>
> If anybody on the list volunteers to test the above or has encountered
> a similar problem, we probably have a chance to debug and fix this issue.
>
> Regards
>
> -Prashant
>
>
>
> "DISCLAIMER: This message is proprietary to Aricent and is intended
> solely for the use of the individual to whom it is addressed. It may
> contain privileged or confidential information and should not be
> circulated or used for any purpose other than for what it is intended.
> If you have received this message in error, please notify the
> originator immediately. If you are not the intended recipient, you are
> notified that you are strictly prohibited from using, copying,
> altering, or disclosing the contents of this message. Aricent accepts
> no responsibility for loss or damage arising from the use of the
> information transmitted by this email including damage from virus."
>
>
> _______________________________________________
> lng-odp mailing list
> [email protected]
> http://lists.linaro.org/mailman/listinfo/lng-odp


_______________________________________________
lng-odp mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/lng-odp


"DISCLAIMER: This message is proprietary to Aricent and is intended solely for 
the use of the individual to whom it is addressed. It may contain privileged or 
confidential information and should not be circulated or used for any purpose 
other than for what it is intended. If you have received this message in error, 
please notify the originator immediately. If you are not the intended 
recipient, you are notified that you are strictly prohibited from using, 
copying, altering, or disclosing the contents of this message. Aricent accepts 
no responsibility for loss or damage arising from the use of the information 
transmitted by this email including damage from virus."

_______________________________________________
lng-odp mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/lng-odp

Reply via email to