Date: Thu, 20 Oct 2005 12:57:21 +0400 From: Yar Tikhiy <yar@comp.chem.msu.su> To: Gleb Smirnoff <glebius@FreeBSD.org> Cc: freebsd-net@FreeBSD.org, ru@FreeBSD.org, Andrew Thompson <thompsa@FreeBSD.org> Subject: Re: vlan patch Message-ID: <20051020085721.GC27114@comp.chem.msu.su> In-Reply-To: <20051020070054.GZ59364@cell.sick.ru> References: <20051019102559.GA45909@heff.fud.org.nz> <20051020070054.GZ59364@cell.sick.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Oct 20, 2005 at 11:00:54AM +0400, Gleb Smirnoff wrote: > > On Wed, Oct 19, 2005 at 11:25:59PM +1300, Andrew Thompson wrote: > A> It has always bugged me how the vlan code traverses the linked-list for > A> each incoming packet to find the right ifvlan, I have this patch which > A> attempts to fix this. > A> > A> What it does is replace the linear search for the vlan with a constant > A> time lookup. It does this by allocating an array for each vlan enabled > A> parent interface so the tag can be directly indexed. > A> > A> This has an overhead of ~16kb on 32bit, this is not too bad as there is > A> usually only one physical interface when using a large number of vlans. > A> > A> I have measured a 1.6% pps increase with 100 vlans, and 8% with 500, and > A> yes, some people use this many in production. > A> > A> It also has the benefit of enforcing unique vlan tags per parent which > A> the current code doesn't do. > > Although the memory overhead is not noticable on modern i386 and amd64 > PCs I don't think that we should waste so much memory. We should keep > in mind the existence of embedded architectures with little memory. Agreed. On amd64 or another 64-bit platform each physical interface carrying vlans will consume 32k of wired kernel memory, which is a rather valuable resource. We may not spend memory in the kernel as generously as in userland programs because it is usually physical memory spent in this case, not virtual one. > In most cases people use 10 - 30 VLANs. I suggest to use a hash, like it I'd rather not limit our consideration by 10-30 VLANs. People are running networks with hundreds of VLANs terminated at a FreeBSD gateway. Perhaps, the hash table should be roughly adjustable to the current number of configured VLANs. > is already done in ng_vlan(4). This hash makes every sixteenth VLAN to fall > into same slot. Since most people allocate VLAN ids contiguously the hash > distribution should be good. Apropos, XOR-folding used in ng_vlan isn't that dumb, it doesn't make every 16th VLAN fall into the same slot. Of course, you will start getting collisions at most on the 16th VLAN added since 16 is the size of the hash table. > Moreover, I suggest Yar and Ruslan to work together and make the hash code > shared between vlan(4) and ng_vlan(4), not copy-and-pasted. The hash code consists of literally a couple of #define's. And the difference between ng_vlan(4) and vlan(4) is that each ng_vlan node gets its own instance of the hash table. OTOH, in vlan(4) we need to decide if the hash table will be per parent interface or a single global instance. In the latter case we could hash by a combination of the VLAN tag and parent's ifindex. Perhaps this approach will yield more CPU cache hits during hash table lookups. In addition, it will be thriftier in using memory. Locking the global hash table should not be an issue as we can use an sx lock in this case for optimal read access. -- Yar
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051020085721.GC27114>