cvs commit: src/sys/net if_ethersubr.c

[Ruslan Ermilov]

On Tue, Feb 15, 2005 at 09:42:26AM +0200, Ruslan Ermilov wrote:
> On Mon, Feb 14, 2005 at 12:06:31PM -0800, Sam Leffler wrote:
> > Ruslan Ermilov wrote:
> > >On Mon, Feb 14, 2005 at 11:13:13AM -0800, Sam Leffler wrote:
> > >
> > >>>>This also has the potential to noticeably 
> > >>>>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) != NULL", and this doesn't look like a huge
> > >>>performance downgrade to me, if at all.
> > >>
> > >>The intent was/is that if_nvlans be the definitive check for whether or 
> > >>not one should inspect the tag chain for vlan tags.  This effectively 
> > >>renders that assumption invalid.  I think it would better to discard 
> > >>these frames in the driver rather than allocate a tag, pass it up, then 
> > >>discard it in ether_demux.  I think you could encapsulate the check in 
> > >>VLAN_INPUT_TAG.
> > >>
> > >
> > >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.
> > 
> > And when you said this before my reply was: don't penalize non-netgraph 
> > use of the system.  If netgraph truly needs to violate this underlying 
> > assumption of the vlan code then please do it with an ifdef.  Otherwise 
> > let's find a better solution.  And if that's not possible then we should 
> > rethink having if_nvlans at all as this change renders it meaningless.
> > 
> Netgraph worked before and after this change, because Netgraph
> (ng_ether) processing happens earlier.  What this change does
> is to fix a bug where stripped VLAN frames are passed to the
> parent interface when they shouldn't be (i.e., when no vlan(4)
> interfaces are configured on this Ethernet).  Given that there
> may be more than just vlan(4) consumers of VLANs in the system,
> if you really think this change pessimizes performance, a better
> solution is needed, but this solution shouldn't hurt Netgraph
> either, and if we used an if_nvlans to indicate whether we
> should accept VLANs, this would break it.  I don't know at
> this point what a better solution could be.  If you have ideas,
> let's discuss them.  So far, the solutions proposed don't seem
> to work well.
> 
How about if we mark mbuf as having a VLAN mtag, in VLAN_INPUT_TAG()
macro, with a simple bit flag?


Cheers,
-- 
Ruslan Ermilov
ru at FreeBSD.org
FreeBSD committer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20050215/ae9af291/attachment.bin