Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 03 Jul 2005 01:07:13 -0000
From:      Ruslan Ermilov <ru@freebsd.org>
To:        Sam Leffler <sam@errno.com>
Cc:        cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org
Subject:   Re: cvs commit: src/sys/net if_ethersubr.c
Message-ID:  <20050214195558.GD69635@ip.net.ua>
In-Reply-To: <4210F849.8060005@errno.com>
References:  <200502140829.j1E8TgDs086634@repoman.freebsd.org> <4210D210.3080700@errno.com> <20050214181431.GA69635@ip.net.ua> <4210F849.8060005@errno.com>

next in thread | previous in thread | raw e-mail | index | archive | help

--ZJcv+A0YCCLh2VIg
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 14, 2005 at 11:13:13AM -0800, Sam Leffler wrote:
> >>This also has the potential to noticeably=20
> >>affect performance so I think a better solution is needed.
> >
> >Here are my thoughts.  On a typical input path, there will be
> >either one or zero mtags, one if driver provided us with the
> >VLAN mtag, so effectively we replaced "ifp->if_nvlans" with
> >"m_tag_first(m) !=3D NULL", and this doesn't look like a huge
> >performance downgrade to me, if at all.
>=20
> The intent was/is that if_nvlans be the definitive check for whether or=
=20
> not one should inspect the tag chain for vlan tags.  This effectively=20
> renders that assumption invalid.  I think it would better to discard=20
> these frames in the driver rather than allocate a tag, pass it up, then=
=20
> discard it in ether_demux.  I think you could encapsulate the check in=20
> VLAN_INPUT_TAG.
>=20
I said this before: vlan(4) is not the only consumer of VLAN
frames in FreeBSD.  VLAN frames are also accepted by ng_vlan(4),
so using the vlan(4)-specific if_nvlans to decide whether we
should accept VLAN frames (in the driver) just isn't appropriate.


Cheers,
--=20
Ruslan Ermilov
ru@FreeBSD.org
FreeBSD committer

--ZJcv+A0YCCLh2VIg
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (FreeBSD)

iD8DBQFCEQJOqRfpzJluFF4RArqWAJ4nebCnnEqH9bY70nRcsIHBccSpygCcCgy6
iFW2jaRYMsBIImp9B4KQk0s=
=8o75
-----END PGP SIGNATURE-----

--ZJcv+A0YCCLh2VIg--




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