[Top] [All Lists]

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

To: Ben Greear <greearb@xxxxxxxxxxxxxxx>, Gleb Natapov <gleb@xxxxxxxxxxx>
Subject: Re: 802.1q Was (Re: Plans for 2.5 / 2.6 ???
From: "James R. Leu" <jleu@xxxxxxxxxxxxxx>
Date: Wed, 7 Jun 2000 10:02:52 -0500
Cc: Mitchell Blank Jr <mitch@xxxxxxxxxx>, jamal <hadi@xxxxxxxxxx>, Andrey Savochkin <saw@xxxxxxxxxxxxx>, rob@xxxxxxxxxxx, buytenh@xxxxxxx, netdev@xxxxxxxxxxx, gleb@xxxxxxxxxxxxxxxxxxxxx
In-reply-to: <393E6A69.2A51D6B2@xxxxxxxxxxxxxxx>; from Ben Greear on Wed, Jun 07, 2000 at 08:29:45AM -0700
Organization: none
References: <20000605053533.C77216@xxxxxxxxxx> <Pine.GSO.4.20.0006050852550.18252-100000@xxxxxxxxxxxxxxxx> <20000607045935.G7740@xxxxxxxxxx> <393E596F.1BD16F5D@xxxxxxxxxxx> <393E6A69.2A51D6B2@xxxxxxxxxxxxxxx>
Reply-to: jleu@xxxxxxxxxxxxxx
Sender: owner-netdev@xxxxxxxxxxx
I think ATM and FR would benifit from the net_fifo idea.

On Wed, Jun 07, 2000 at 08:29:45AM -0700, Ben Greear wrote:
> Gleb Natapov wrote:
> > 
> > Mitchell Blank Jr wrote:
> > >
> > > 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.
> > >
> > 
> > Excellent idea. net_device should represent physical device and provide
> > functionality of network device (hard_start_xmit, set_mac_address,
> > set_multicast_list, ...) but not functionality of second layer
> > (hard_header, hard_header_parse, ...). The functionality of ethernet
> > should be in ethernet net_fifo, functionality of vlan in vlan net_fifo,
> > bridge in bridge net_fifo. net_fifo is what user sees as network
> > interface. Third layer (ip, ipx, ...) communicates only with net_fifo
> > (and not with net_device) and each net_fifo may communicate with one or
> > more net_devices (bridging or bonding).
> > 
> > Are there problems with such architecture ?
> Not a bad idea, if there is enough that can be split out, but I see very 
> little
> that is not common between the current net_device and some net_fifo that can
> replace it.  For example, you will need some sort of hard_start_xmit in
> the net_device to send it to the lower level.  There is no particular reason
> why someone could not implement a queue in a VLAN, for example, that would
> buffer, and even provide pushback to higher levels, feeding the lower device
> (wich may be ethernet, or even be ppp/FR/ATM (think bridged)).  Just because 
> it's not real
> hardware doesn't mean it doesn't logically hard_start_xmit.
> Is multi-cast / mac_address used in anything besides ethernet?  If we're 
> trying
> to abstract all physical net_devices, then we should make sure it really fits,
> otherwise just stick with what already works.
> Also, if it becomes clear that the large majority of the net_device 
> functionality
> would need to go into the net_fifo, I would argue that it may be cleaner to
> instead create a new lower level, maybe hard_net_device, or something like 
> that
> so that we don't have to change a well understood interface (net_device)....
> -- 
> Ben Greear (greearb@xxxxxxxxxxxxxxx)
> Author of ScryMUD: 4444        (Released under GPL)

James R. Leu

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