netdev
[Top] [All Lists]

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

To: Lennert Buytenhek <buytenh@xxxxxxx>
Subject: Re: 802.1q Was (Re: Plans for 2.5 / 2.6 ???
From: Andrey Savochkin <saw@xxxxxxxxxxxxx>
Date: Wed, 7 Jun 2000 11:31:35 +0800
Cc: Mitchell Blank Jr <mitch@xxxxxxxxxx>, Ben Greear <greearb@xxxxxxxxxxxxxxx>, rob@xxxxxxxxxxx, netdev@xxxxxxxxxxx, Gleb Natapov <gleb@xxxxxxxxxxxxxxxxxxxxx>, jamal <hadi@xxxxxxxxxx>
In-reply-to: <Pine.LNX.4.21.0006062103570.17520-100000@mara.math.leidenuniv.nl>; from "Lennert Buytenhek" on Tue, Jun 06, 2000 at 09:09:51PM
References: <20000605102627.A8473@saw.sw.com.sg> <Pine.LNX.4.21.0006062103570.17520-100000@mara.math.leidenuniv.nl>
Sender: owner-netdev@xxxxxxxxxxx
On Tue, Jun 06, 2000 at 09:09:51PM +0200, Lennert Buytenhek wrote:
> On Mon, 5 Jun 2000, Andrey Savochkin wrote:
> > I think that the current VLAN implementation slightly abuses the
> > notion of device.  And it doesn't relate to the number of devices and
> > the efficiency of search algorithms.  The current VLAN implementation
> > is a pure packet-mangling code.  It misses one of the most important
> > properties of network devices - flow control.  Any code that doesn't
> > provide flow control isn't a device, but a code just manipulating of
> > packet contents.
> 
> From this I may conclude that current (2.3) bridging is broken too as it
> works as a device?

Packet switching inside a bridge group doesn't need the bridge device.

In my opinion, bridge virtual interface (in Cisco terms) may be
considered as a network device.  It provides (or should provide) very
non-trivial hard_header(), hard_header_cache() and similar functions
determining what link to use for output of the packet.  Bridge doesn't touch
packets, but, instead, it provides a virtual link which has it's own notion
of peer addressing (selection for device from the bridge group plus link
level address) and transmission.  When it comes to flow control, this notion
can't be easily applied to bridges.

VLANs are opposite to bridges.  They use very simple hard header building
methods (essentially, eth_header), and their flow control is directly based on
the flow control of underlying device.  Whether you just requeue packets or set
__LINK_STATE_XOFF just in accordance to the underlying device, it doesn't
matter.  It's the underlying device which does flow control for you.

Best regards
                                        Andrey V.
                                        Savochkin

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