jamal wrote:
> [ A lot of arguement on how anything which can do IP is a device, deleted]
> Yes people, what is net device? ;-> It routes, it ARPs, it cooks ... it
> must be a net device.
Yes, that's pretty much the point.
> > I think a reasonable goal for VLAN support would be that a machine
> > with one ethernet card on two VLANs should be able to do pretty much
> > the same as a machine with two seperate ethernet cards, with similar
> > configuration commands. That is, after all, the promise of VLANs.
>
> 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.
> > Flow control might not be perfect in VLANs, but that's really the
> > least of its problems. The linux model of handling flow control
> > only can really handle simple devices that can be modeled as a FIFO
> > queue.
>
> 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".
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.
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.
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.
-Mitch
|