netdev
[Top] [All Lists]

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

To: Gleb Natapov <gleb@xxxxxxxxxxx>
Subject: Re: 802.1q Was (Re: Plans for 2.5 / 2.6 ???
From: Ben Greear <greearb@xxxxxxxxxxxxxxx>
Date: Wed, 07 Jun 2000 08:29:45 -0700
Cc: Mitchell Blank Jr <mitch@xxxxxxxxxx>, jamal <hadi@xxxxxxxxxx>, Andrey Savochkin <saw@xxxxxxxxxxxxx>, rob@xxxxxxxxxxx, buytenh@xxxxxxx, netdev@xxxxxxxxxxx, gleb@xxxxxxxxxxxxxxxxxxxxx
Organization: Candela Technologies
References: <20000605053533.C77216@sfgoth.com> <Pine.GSO.4.20.0006050852550.18252-100000@shell.cyberus.ca> <20000607045935.G7740@sfgoth.com> <393E596F.1BD16F5D@nbase.co.il>
Sender: owner-netdev@xxxxxxxxxxx
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)  http://www.candelatech.com
Author of ScryMUD:  scry.wanfear.com 4444        (Released under GPL)
http://scry.wanfear.com               http://scry.wanfear.com/~greear

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