[Top] [All Lists]

Re: 802.1q Was (Re: Plans for 2.5 / 2.6 ???

To: Lennert Buytenhek <buytenh@xxxxxxx>
Subject: Re: 802.1q Was (Re: Plans for 2.5 / 2.6 ???
From: Andi Kleen <ak@xxxxxx>
Date: Fri, 9 Jun 2000 10:36:20 +0200
Cc: Andi Kleen <ak@xxxxxx>, Andrey Savochkin <saw@xxxxxxxxxxxxx>, Mitchell Blank Jr <mitch@xxxxxxxxxx>, Ben Greear <greearb@xxxxxxxxxxxxxxx>, rob@xxxxxxxxxxx, netdev@xxxxxxxxxxx, Gleb Natapov <gleb@xxxxxxxxxxxxxxxxxxxxx>, jamal <hadi@xxxxxxxxxx>
In-reply-to: <>; from Lennert Buytenhek on Thu, Jun 08, 2000 at 10:24:16PM +0200
References: <> <>
Sender: owner-netdev@xxxxxxxxxxx
On Thu, Jun 08, 2000 at 10:24:16PM +0200, Lennert Buytenhek wrote:
> On Wed, 7 Jun 2000, Andi Kleen wrote:
> > > > The current kernel infrastructure for packet mangling may still need
> > > > some adjustments, but it at least exists.  I'm encouraging to consider
> > > > VLAN implementation as just a netfilter module.
> > > 
> > > "All the world is an IP net"? How should I run IPX over my VLANs then?
> > 
> > Netfilter is not an IP only thing. It is a generic framework for
> > packet mangling. Although currently only IPv4 and IPv6 netfilter
> > implementations exist it would be no big problem to add ``raw
> > ethernet'' netfilter hooks.
> Raw ethernet netfilter hooks, as are IPX netfilter hooks by the way, are
> currently a nice blue cloud in the sky.

They are not hard to add. Just so far nobody needed them. You could
either hook them into the device's hard_start_xmit function or 
as an netfilter qdisc for the devices with queue (both requires no
additional instructions in the fast path when not used) 

> As we're getting into the architectural purity business anyway, does it
> make a whole lot of sense to netfilter on two different protocol levels?

I think it does. netfilter is not a single entinity, it is a hook
infrastructure. When multi layer filtering is required it can be integrated.

That's generally.

I haven't thought hard enough about the VLAN problem to decide if it
really makes sense to implement it as netfilter module. The net_fifo 
idea seems to have some merits too (struct net_device probably does too
many things at once currently and some hash tables/trees for device management
probably couldn't hurt)  


This is like TV. I don't like TV.

<Prev in Thread] Current Thread [Next in Thread>