From owner-freebsd-pf@FreeBSD.ORG Fri Aug 14 13:55:19 2009 Return-Path: Delivered-To: pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5709106568F; Fri, 14 Aug 2009 13:55:19 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A0A838FC51; Fri, 14 Aug 2009 13:55:19 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 52F8F46B0C; Fri, 14 Aug 2009 09:55:19 -0400 (EDT) Date: Fri, 14 Aug 2009 14:55:19 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Tom Uffner In-Reply-To: <4A8484E4.6090504@uffner.com> Message-ID: References: <4A8484E4.6090504@uffner.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: pf@freebsd.org, current@freebsd.org Subject: Re: packet forwarding/firewall performance question X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 13:55:19 -0000 On Thu, 13 Aug 2009, Tom Uffner wrote: > i'm hoping a few people will give me estimates on what kind of throughput i > should theoretically expect before i provide any actual test data. > > also, any suggestions on tuning would be welcome. > > so far in preliminary tests, enabling polling on the network interfaces > reduces my performance slightly both to/from and through the box. > net.inet.ip.fastforwarding doesn't seem to make much difference either > way but i haven't done very thorough testing of it. increasing > net.inet.tcp.sendbuf_max & recvbuf_max may have helped, but again, not > sufficiently tested. I can't speak to absolute numbers, but I wouldn't expect net.inet.tcp.* changes to make any difference, as they should affect only locally terminated sockets on the firewall host, not forwarded packets. You might want to try experimenting with net.isr.direct -- try setting it to 0, as this changes the kernel dispatch model for the network stack. On a UP box, I would probably anticipate a performance loss for making that change, or similar configuration changes for multiple netisr threads using net.isr.maxthreads. If you're using firewall code, fast forwarding is unlikely to make a difference. Depending on the cache/memory/CPU trade-off, you might find turning off flowtable support helps -- net.inet.flowtable.enable=0. Robert N M Watson Computer Laboratory University of Cambridge