Date: Thu, 20 Oct 2005 16:10:43 +0400 From: Yar Tikhiy <yar@comp.chem.msu.su> To: Andrew Thompson <thompsa@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: vlan patch Message-ID: <20051020121043.GA47217@comp.chem.msu.su> In-Reply-To: <20051020091934.GA50908@heff.fud.org.nz> References: <20051019102559.GA45909@heff.fud.org.nz> <20051020070054.GZ59364@cell.sick.ru> <20051020091934.GA50908@heff.fud.org.nz>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Oct 20, 2005 at 10:19:34PM +1300, Andrew Thompson wrote: > On Thu, Oct 20, 2005 at 11:00:54AM +0400, Gleb Smirnoff wrote: > > Andrew, > > > > 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. > > I agree. Did you see the revised patch that sets a threshold before > allocating the memory? do you think thats sufficient? I'm afraid that the simple approach of setting a threshold isn't much better than no such threshold at all. The number of vlans in use tends to grow in time in most cases, but it still will be several times less than the maximum, 4096, which defines the full tag table size. I believe we should keep this in mind. -- Yar
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051020121043.GA47217>