On Mon, 5 Jun 2000, Mitchell Blank Jr wrote:
> Andrey Savochkin wrote:
> > I want to ad my $0.02.
>
> > Linux kernel do not bind IP addresses for devices.
>
[ 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.
>
> 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.
> 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.
> Take for example the current mess we have in the ATM
> stack - suppose you have an atm net_device (can be CLIP or LANE,
> doesn't matter) with two PVCs to host1 and host2. These go
> across different networks, and thus have different QoS available -
> host1 is across a frac-T1 link which host2 is right on our local
> OC-12 switch. Suppose host1 gets enough traffic that the PVC
> becomes full - what do we do?
> 1. We could netif_stop_queue, but that would shut off all
> connectivity to host2, even though we could easily get
> packets to it
> 2. We could just drop packets to host1, but then we're
> not providing the neccesary backpressure to make net
> schedulers work
>
hrm.. Unless i am totaly misunderstanding you;
You should leave this to policy management.
Repeat after me: "I shall provide the mechanism, sir". Very simple
rule of building powerful abstractions.
cheers,
jamal
|