Skip site navigation (1)Skip section navigation (2)
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>