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 at dpdk.org] De la part de Sambath Kumar > Balasubramanian > Envoy??: mercredi 4 d?cembre 2013 12:47 > ??: dev at 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
