Date: Fri, 25 Aug 2006 11:38:19 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Gleb Smirnoff <glebius@FreeBSD.org> Cc: Ian FREISLICH <if@hetzner.co.za>, freebsd-current@FreeBSD.org, yar@FreeBSD.org Subject: Re: 802.1Q vlan performance. Message-ID: <20060825113658.D40887@fledge.watson.org> In-Reply-To: <20060825101053.GU76666@FreeBSD.org> References: <E1GGWGA-000C6D-7d@hetzner.co.za> <20060825101053.GU76666@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 25 Aug 2006, Gleb Smirnoff wrote: > As said before by Andrew. It consumes memory. And looks like a regression on > a system with small number of vlans. > > However, after your email I see that we need to document this option in > vlan(4) and encourage people to try it, when they are building a system with > a huge number of vlans. > > And here are some more performance thoughts on vlan(4) driver. When we are > processing an incoming VLAN tagged frame, we need either hash or the array > to determine which VLAN does this frame belong to. When we are sending a > VLAN frame outwards, we don't need this lookup. I've made some tests and it > looks like that the performance decrease that is observed between bare > Ethernet interface and vlan(4) interface, is mostly caused by the transmit > part. The packet is put twice on interface queues. I hope, this will be > optimized after Robert Watson finishes his if_start_mbuf work. Ideally, it will also be possible to remove the m_tag allocation/free from the path once I'm done, which should help also. Is it possible to make the hash table decision a run-time decision? Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060825113658.D40887>