From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sambath Kumar Balasubramanian Subject: Re: Question on the Ring Library Date: Wed, 4 Dec 2013 13:49:12 -0800 Message-ID: References: <03b201cef0f7$5fba0d20$1f2e2760$@com> <03ee01cef12b$c56d85a0$504890e0$@com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "dev-VfR2kkLFssw@public.gmane.org" To: =?ISO-8859-1?Q?Fran=E7ois=2DFr=E9d=E9ric_Ozog?= Return-path: In-Reply-To: <03ee01cef12b$c56d85a0$504890e0$@com> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" Thanks Fran=E7ois-Fr=E9d=E9ric. Trying to embark on a small prototype and s= ee the results. Thanks for the timing data. Really helpful. Regards, Sambath On Wed, Dec 4, 2013 at 12:02 PM, Fran=E7ois-Fr=E9d=E9ric Ozog = wrote: > You are welcome ! > > > > Even if you insert packets in batch into a fifo, the mutex is still > unpredictable. If one pthread_lock costs 1ms, you are going to lose > packets, regardless of the number of RSS queues and ring sizes=85 Batchin= g > comes with another issue: need to flush a batch after a certain timeout i= f > you do not have packets. Userland timer resolution is such that you are > introducing port to port latency quite a lot: DPDK native, you can manage > to get a 2=B5s latency (including PCI express), while with batch it may b= e > 1ms=85 You may find smarter algorithms but still you will be an order of > magnitude higher than DPDK. > > > > Hope this helps. > > > > Fran=E7ois-Fr=E9d=E9ric > > > > *De :* Sambath Kumar Balasubramanian [mailto: > sambath.balasubramanian-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org] > *Envoy=E9 :* mercredi 4 d=E9cembre 2013 15:01 > *=C0 :* Fran=E7ois-Fr=E9d=E9ric Ozog > *Cc :* dev-VfR2kkLFssw@public.gmane.org > *Objet :* Re: [dpdk-dev] Question on the Ring Library > > > > Thanks Fran=E7ois-Fr=E9d=E9ric. That puts real good perspective on the co= st for > the vent assuming each packet in the fast will result > > in an event. If event rate is orders of magnitude less than the packet > rate, then I guess we can still achieve 10G since the "extra cost" will b= e > in the event thread and not in the fast path thread. > > > > Regards, > > Sambath >