Date: Fri, 20 Apr 2012 11:01:03 +0200 From: Andre Oppermann <andre@freebsd.org> To: "Alexander V. Chernikov" <melifaro@FreeBSD.org> Cc: current@freebsd.org, Luigi Rizzo <rizzo@iet.unipi.it>, "K. Macy" <kmacy@freebsd.org>, net@freebsd.org Subject: Re: Some performance measurements on the FreeBSD network stack Message-ID: <4F9125CF.8090201@freebsd.org> In-Reply-To: <4F911DCD.30001@FreeBSD.org> 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> <4F911DCD.30001@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 20.04.2012 10:26, Alexander V. Chernikov wrote: > On 20.04.2012 01:12, Andre Oppermann wrote: >> On 19.04.2012 22:34, K. Macy wrote: >>> 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 > > From my experience, turning fastfwd on gives ~20-30% performance > increase (10G forwarding with firewalling, 1.4MPPS). ip_forward() uses 2 > lookups (ip_rtaddr + ip_output) vs 1 ip_fastfwd(). Another difference is the packet copy the normal forwarding path does to be able to send a ICMP redirect message if the packet is forwarded to a different gateway on the same LAN. fastforward doesn't do that. > The worst current problem IMHO is number of locks packet have to > traverse, not number of lookups. Agreed. Actually the locking in itself is not the problem. It's the side effects of cache line dirtying/bouncing and contention. However in the great majority of the cases the data protected by the lock is only read, not modified making a 'full' lock expensive. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F9125CF.8090201>