netdev
[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: Tue, 6 Jun 2000 07:49:01 -0400 (EDT)
Cc: Andrey Savochkin <saw@xxxxxxxxxxxxx>, Ben Greear <greearb@xxxxxxxxxxxxxxx>, rob@xxxxxxxxxxx, buytenh@xxxxxxx, netdev@xxxxxxxxxxx, gleb@xxxxxxxxxxxxxxxxxxxxx
In-reply-to: <20000605053533.C77216@sfgoth.com>
Sender: owner-netdev@xxxxxxxxxxx

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



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