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
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.
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
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).