Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 20 Jan 2005 17:39:48 +0300 (MSK)
From:      Maxim Konovalov <maxim@macomnet.ru>
To:        Robert Watson <rwatson@freebsd.org>
Cc:        Charlie Schluting <charlie@schluting.com>
Subject:   Re: vlans changed?
Message-ID:  <20050120173819.Q62580@mp2.macomnet.net>
In-Reply-To: <Pine.NEB.3.96L.1050120102946.84093B-100000@fledge.watson.org>
References:  <Pine.NEB.3.96L.1050120102946.84093B-100000@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 20 Jan 2005, 10:33-0000, Robert Watson wrote:

>
> On Wed, 19 Jan 2005, Charlie Schluting wrote:
>
> > Now, in 5.3, the only thing I can get working is to configure the em0
> > int with the IP, and set the trunk to have the native vlan corresponding
> > to that IP. Weird.
> >
> > Also, is there a way to stop em(4) from stripping dot1q tags in
> > hardware? I'd like to see them with tcpdump. What kind of a performance
> > hit does this involve?
>
> Try "ifconfig em0 -vlanhwtag" and see if that helps.  If not, take a look

Yep, it works for Alex (CC'ed), thanks for the tip.

> in if_em.c:em_setup_interface(), and you'll see two lines like this:
>
> #if __FreeBSD_version >= 500000
>         ifp->if_capabilities |= IFCAP_VLAN_HWTAGGING | IFCAP_VLAN_MTU;
>         ifp->if_capenable |= IFCAP_VLAN_HWTAGGING | IFCAP_VLAN_MTU;
> #endif
>
> Delete the contents "|FCAP_VLAN_HWTAGGING |" from each line, and that
> should disable support for hardware vlan tagging and stripping in the
> driver.  There are several bugs relating to the handling of hardware vlan
> tagging and promiscuous mode in both if_re and if_em.  I had hoped to have
> a chance to resolve them over the past couple of months but have not as
> yet been able to do so.  I measured a small performance hit last time I
> tried disabling the hardware tagging, perhaps a couple of percent, but
> mileage may vary -- for in-bound packets, there's a small amount
> additional work, but for outgoing packets you may see an extra memory
> allocation for each encapsulated packet (it depends a bit on what you
> send).  If this appears to work properly for you, we should probably
> commit the change so that what's in the tree works properly, even if it's
> slightly slower.

IMO this is a good idea.

-- 
Maxim Konovalov



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050120173819.Q62580>