[Top] [All Lists]

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

To: Mitchell Blank Jr <mitch@xxxxxxxxxx>
Subject: Re: 802.1q Was (Re: Plans for 2.5 / 2.6 ???
From: jamal <hadi@xxxxxxxxxx>
Date: Thu, 8 Jun 2000 08:57:52 -0400 (EDT)
Cc: Andrey Savochkin <saw@xxxxxxxxxxxxx>, Ben Greear <greearb@xxxxxxxxxxxxxxx>, rob@xxxxxxxxxxx, buytenh@xxxxxxx, netdev@xxxxxxxxxxx, gleb@xxxxxxxxxxxxxxxxxxxxx
In-reply-to: <>
Sender: owner-netdev@xxxxxxxxxxx

On Wed, 7 Jun 2000, Mitchell Blank Jr wrote:

> jamal wrote:
> > 
> > And you can do this just fine with VLANS abstracted on top of devices.
> OK, explain how.  I've enumerated a dozen or more places either in
> protocol support or in the user-kernel interface where the
> configuration or functionality depends on a named device per individual
> vlan.  You keep ignoring them when I point them out, but they are
> still there.  For instance, if both the VLANs are called "eth0", how
> do I set individual settings in /proc/sys/net/ipv4/conf/ for the two
> different VLANs?  Or any of the other ones I pointed out - take your
> pick.

I dont think if i would call both VLANS "eth0"; VLANS would be just
circuits on top of eth0.
I would think something like VLAN would require its own config
tool. ifconfig is probably not the best tool to configure VLANS
and definetly no close to a swiss army knife; pointing to ifconfig or
route as reason to set a vlan as a device is a bad excuse. 
'nuf said.

Here's what i would have done:

"vlantool attach to eth0 VLAN10 IP a.b.c.d priority x ... blablah"

The tool would:
- use netlink or ioctl to add the IP as another alias to eth0;
- my own private table inside the kernel would take the rest vlan info;
searchable by vlanid primarily etc put all your funky search algorithms 
there. I see the ACL stored there as well.
You might need to maintain some daemon in user space ("vland")

* Incoming packets get looked up on the table for demuxing, ACL get
applied etc; they might be dropped right here for example
-switching happens based on the VLAN table details; or things may be
sent up to IP; 
* outgoing packets: 
-not a problem if you are switching; just replace VLAN headers;off you go
ACL rules apply.
-coming down the stack; extend dst output to be specialized for 
your specific routes entered for your VLANs. This is a little tricky but
well done by James Leu's MPLS code. 
- add notification on VLAN adds/deletes, device deletes maps to "all vlans
have been deleted" and Zebra or whatever your favorite Route daemon is
happy. How the route daemon abstracts things is its own problem;it should
not force how the kernel should implement things.

The moral of this:
- ARP and routing both work .. 
- Your packet mungling (header replacements/adds) work just fine

Did i miss anything?

I think Jim has done a great job in design in MPLS with a much more
complex problem. Lookup his code.

> > What "linux model of handling flow control"?
> > What would the other model be? FIFOs are the basic building blocks.
> Yes, FIFOs are the basic building blocks.  The current model is "a
> net_device must be modeled as a single FIFO before the xmit".

I am either still confused or you are. The simplest FIFO scheme on
transmit is a 3 band one.

> This isn't right.
> Some devices don't have any FIFO associated with them.  Either they
> don't need one because they are trivial (dummy, lo) or they just feed
> something else that _does_ have a FIFO (ethernet bridge device,
> anything that tunnels L2-in-L2 like PPPoE, or these proposed VLAN
> devices).  It doesn't really _hurt_ much to have these modeled with
> an unused FIFO in front, other than some TC stuff can't work right
> since there's no backpressure.

You have some form of backpressure that no-one is using at the moment;
Look at the NET_XMIT_*;
The packet requeing schemes could also be considered as backpressure if
you choose to use them.

> The other case is worse - things that have multiple FIFOs.  As
> I pointed out, the obvious one is any ATM protocol that uses
> multiple VCs.  Since each VC is an individual FIFO you can't
> tell if you're supposed to queue a packet until you've already
> looked at the header and determined which VC to route out.
> Doing a netif_stop_queue() causes all the VCs to stop being
> fed.

And you dont like the concept of classifiers?
You can set a classifier whose match action is to feed things
into a blackhole/noop while other VCs happily send away. 

> Really we need a new structure "net_fifo?" in order to divorce
> the queuing from the concept of a net_device.  Anything that
> wants to look to userland and the protocol stacks as a net_device
> should, wheteher or not you feel they are just a packet mangler
> or not.

I think we already have "net_fifos" if you choose to use them; no need in
re-inventing the wheel (rule number 100).


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