Date: Thu, 19 Apr 2012 23:27:03 +0200 From: Andre Oppermann <andre@freebsd.org> To: "K. Macy" <kmacy@freebsd.org> Cc: Luigi Rizzo <rizzo@iet.unipi.it>, current@freebsd.org, net@freebsd.org Subject: Re: Some performance measurements on the FreeBSD network stack Message-ID: <4F908327.5070905@freebsd.org> In-Reply-To: <CAHM0Q_NwvLVFgeE3xsaf8nO1Nusm4QBp7eRuMn=UuNWWFp0vnw@mail.gmail.com> References: <20120419133018.GA91364@onelab2.iet.unipi.it> <4F907011.9080602@freebsd.org> <20120419204622.GA94904@onelab2.iet.unipi.it> <CAHM0Q_M4wcEiWGkjWxE1OjLeziQN0vM%2B4_EYS_WComZ6=j5xhA@mail.gmail.com> <4F907FB4.3080400@freebsd.org> <CAHM0Q_NwvLVFgeE3xsaf8nO1Nusm4QBp7eRuMn=UuNWWFp0vnw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 19.04.2012 23:17, K. Macy wrote: >>> This only helps if your flows aren't hitting the same rtentry. >>> Otherwise you still convoy on the lock for the rtentry itself to >>> increment and decrement the rtentry's reference count. >> >> >> The rtentry lock isn't obtained anymore. While the rmlock read >> lock is held on the rtable the relevant information like ifp and >> such is copied out. No later referencing possible. In the end >> any referencing of an rtentry would be forbidden and the rtentry >> lock can be removed. The second step can be optional though. > > Can you point me to a tree where you've made these changes? It's not in a public tree. I just did a 'svn up' and the recent pf and rtsocket changes created some conflicts. Have to solve them before posting. Timeframe (early) next week. >>>> i was wondering, is there a way (and/or any advantage) to use the >>>> fastforward code to look up the route for locally sourced packets ? >>>> >>> >>> If the number of peers is bounded then you can use the flowtable. Max >>> PPS is much higher bypassing routing lookup. However, it doesn't scale >>> to arbitrary flow numbers. >> >> >> In theory a rmlock-only lookup into a default-route only routing >> table would be faster than creating a flow table entry for every >> destination. It a matter of churn though. The flowtable isn't >> lockless in itself, is it? > > It is. In a steady state where the working set of peers fits in the > table it should be just a simple hash of the ip and then a lookup. Yes, but the lookup requires a lock? Or is every entry replicated to every CPU? So a number of concurrent CPU's sending to the same UDP destination would content on that lock? -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F908327.5070905>