Received:  by oss.sgi.com id <S42428AbQFGDb6>;
	Tue, 6 Jun 2000 20:31:58 -0700
Received: from saw.sw.com.sg ([203.120.9.98]:18304 "HELO saw.sw.com.sg")
	by oss.sgi.com with SMTP id <S42424AbQFGDbi>;
	Tue, 6 Jun 2000 20:31:38 -0700
Received: (qmail 4396 invoked by uid 577); 7 Jun 2000 03:31:35 -0000
Message-ID: <20000607113135.B4304@saw.sw.com.sg>
Date:   Wed, 7 Jun 2000 11:31:35 +0800
From:   Andrey Savochkin <saw@saw.sw.com.sg>
To:     Lennert Buytenhek <buytenh@gnu.org>
Cc:     Mitchell Blank Jr <mitch@sfgoth.com>,
        Ben Greear <greearb@candelatech.com>, rob@valinux.com,
        netdev@oss.sgi.com, Gleb Natapov <gleb@tochna.technion.ac.il>,
        jamal <hadi@cyberus.ca>
Subject: Re: 802.1q Was (Re: Plans for 2.5 / 2.6 ???
References: <20000605102627.A8473@saw.sw.com.sg> <Pine.LNX.4.21.0006062103570.17520-100000@mara.math.leidenuniv.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.93.2i
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
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

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