Hi Konstantin, On 02/09/2015 04:43 PM, Ananyev, Konstantin wrote: >> The ring library was designed with the assumption that the code is not >> preemptable. The code is lock-less but not wait-less. Actually, if the >> code is preempted at a bad moment, it can spin forever until it's >> unscheduled. >> >> I wonder if adding a sched_yield() may not penalize the current >> implementations that only use one pthread per core? Even if there >> is only one pthread in the scheduler queue for this CPU, calling >> the scheduler code may cost thousands of cycles. >> >> Also, where does this value "RTE_RING_PAUSE_REP 0x100" comes from? >> Why 0x100 is better than 42 or than 10000? > > The idea was to have something few times bigger than actual number > active cores in the system, to minimise chance of a sched_yield() being > called > for the case when we have one thread per physical core. > My thought was that having that many repeats would make such chance > neglectable. > Though, right now, I don't have any data to back it up. > >> I think it could be good to check if there is a performance impact >> with this change, especially where there is a lot of contention on >> the ring. If it has an impact, what about adding a compile or runtime >> option? > > Good idea, probably we should make RTE_RING_PAUSE_REP configuration option > and let say avoid emitting ' sched_yield();' at all, if RTE_RING_PAUSE_REP > == 0.
Yes, it looks like a good compromise. Olivier
