Re: [dpdk-dev] Question on the Ring Library

["François-Frédéric Ozog" <ff@ozog.com>]

Hi

On a 10Gbps link, there is a new packet every 650ns on average on each
direction. So handling latency is extremely important.

Traditional "fast" userland mutexes involves system call and scheduling
costs (look at the kernel code: it is "hairy"). I measured difference
between mutex controlled fifo and DPDK controlled fifo on a Xeon E5-2680v2,
1867MHz RAM: for times the performance... I consider the cost of a mutex
lock is something close to 400ns on average (well I don't say that it always
costs that, but the delays can be not predictable and extremely high - I saw
a few ms even if you use isolcpus and precise affinities-). So if you plan
to do 10Gbps stuff, I guess polling is the only way to go.

François-Frédéric


> -----Message d'origine-----
> De : dev [mailto:dev-bounces@dpdk.org] De la part de Sambath Kumar
> Balasubramanian
> Envoyé : mercredi 4 décembre 2013 12:47
> À : dev@dpdk.org
> Objet : [dpdk-dev] Question on the Ring Library
> 
> Hi,
> 
>   The ring library seems to be an excellent IPC. But looking at one use
> case where the fast path code posts events to event thread for example,
the
> event thread will spend some cycles polling the ring rather than waiting
> for the event. One approach could be a fast path code basically posts the
> event in the ring as is today and there is a background thread that polls
> the queues and wakes up the event threads. This is similar to Linux
> SOFTIRQs.The event threads are asynchronous. Is this a fair model to avoid
> extra polling CPU cycles by the event threads? Is there any other
> alternatives in dpdk?
> 
> Regards,
> Sambath