Re: Stackable devices.
Christophe Devriese wrote:
It would however be considerable effort to do this. Is this going to end up
unapplied like my last patch, or ?
I don't get to make this decision..and when I ask such questions...they
are usually ignored unless I also post a working patch
I think you could start with just supporting bridging without too
much code.
Ben
Regards,
Christophe
On Tuesday 08 August 2006 18:36, you wrote:
Christophe Devriese wrote:
On Wed, Aug 02, 2006 at 10:50:08AM -0700, Ben Greear wrote:
Currently, the bridge hook logic is something like:
if (bridge-consumed-pkt) {
return
}
// drop through to other layers
There are several other hooks I'd like to see added (pktgen receive
processing,
mac-vlans, etc). Each of these hooks are logically similar to the bridge
hook,
ie if it consumes the pkt, return, else, drop through to the next hook
untill
we get to the regular protocol processing logic.
I would like to be able to chain layer-2 handlers, such as bridge,
mac-vlan, pktgen such that if one consumed, you break out of the
handling, else, you try the next handler. The handlers can be
dynamically registered and inserted
in any order, controllable by user-space and/or module load/unload.
For many of the handlers, the logic will re-insert the packet by
re-calling the
netif-rx logic, so there would need to be some protection to keep loops
from occurring that would recurse too much and overflow the stack.
I'm also a big fan of a generalized system like this. It would need to
catch both the vlan accelerated path and the normal path.
Well, it isn't actually needed for VLANs since VLAN's hook is a protocol
handler
Ben
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Stackable devices.
Christophe Devriese wrote: It would however be considerable effort to do this. Is this going to end up unapplied like my last patch, or ? I don't get to make this decision..and when I ask such questions...they are usually ignored unless I also post a working patch I think you could start with just supporting bridging without too much code. Ben - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Stackable devices.
It would however be considerable effort to do this. Is this going to end up
unapplied like my last patch, or ?
Regards,
Christophe
On Tuesday 08 August 2006 18:36, you wrote:
Christophe Devriese wrote:
On Wed, Aug 02, 2006 at 10:50:08AM -0700, Ben Greear wrote:
Currently, the bridge hook logic is something like:
if (bridge-consumed-pkt) {
return
}
// drop through to other layers
There are several other hooks I'd like to see added (pktgen receive
processing,
mac-vlans, etc). Each of these hooks are logically similar to the bridge
hook,
ie if it consumes the pkt, return, else, drop through to the next hook
untill
we get to the regular protocol processing logic.
I would like to be able to chain layer-2 handlers, such as bridge,
mac-vlan, pktgen such that if one consumed, you break out of the
handling, else, you try the next handler. The handlers can be
dynamically registered and inserted
in any order, controllable by user-space and/or module load/unload.
For many of the handlers, the logic will re-insert the packet by
re-calling the
netif-rx logic, so there would need to be some protection to keep loops
from occurring that would recurse too much and overflow the stack.
I'm also a big fan of a generalized system like this. It would need to
catch both the vlan accelerated path and the normal path.
Well, it isn't actually needed for VLANs since VLAN's hook is a protocol
handler
Ben
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Stackable devices.
On Wed, Aug 02, 2006 at 10:50:08AM -0700, Ben Greear wrote:
Currently, the bridge hook logic is something like:
if (bridge-consumed-pkt) {
return
}
// drop through to other layers
There are several other hooks I'd like to see added (pktgen receive
processing,
mac-vlans, etc). Each of these hooks are logically similar to the bridge
hook,
ie if it consumes the pkt, return, else, drop through to the next hook
untill
we get to the regular protocol processing logic.
I would like to be able to chain layer-2 handlers, such as bridge, mac-vlan,
pktgen such that if one consumed, you break out of the handling, else, you
try the next handler. The handlers can be dynamically registered and
inserted
in any order, controllable by user-space and/or module load/unload.
For many of the handlers, the logic will re-insert the packet by re-calling
the
netif-rx logic, so there would need to be some protection to keep loops from
occurring that would recurse too much and overflow the stack.
I'm also a big fan of a generalized system like this. It would need to
catch both the vlan accelerated path and the normal path.
--
---
Christophe Devriese EURiD
Network Adminstrator / Developer
[EMAIL PROTECTED]
http://www.eth1.org --
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Stackable devices.
Christophe Devriese wrote:
On Wed, Aug 02, 2006 at 10:50:08AM -0700, Ben Greear wrote:
Currently, the bridge hook logic is something like:
if (bridge-consumed-pkt) {
return
}
// drop through to other layers
There are several other hooks I'd like to see added (pktgen receive
processing,
mac-vlans, etc). Each of these hooks are logically similar to the bridge
hook,
ie if it consumes the pkt, return, else, drop through to the next hook
untill
we get to the regular protocol processing logic.
I would like to be able to chain layer-2 handlers, such as bridge, mac-vlan,
pktgen such that if one consumed, you break out of the handling, else, you
try the next handler. The handlers can be dynamically registered and
inserted
in any order, controllable by user-space and/or module load/unload.
For many of the handlers, the logic will re-insert the packet by re-calling
the
netif-rx logic, so there would need to be some protection to keep loops from
occurring that would recurse too much and overflow the stack.
I'm also a big fan of a generalized system like this. It would need to
catch both the vlan accelerated path and the normal path.
Well, it isn't actually needed for VLANs since VLAN's hook is a protocol
handler
Ben
--
Ben Greear [EMAIL PROTECTED]
Candela Technologies Inc http://www.candelatech.com
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Stackable devices.
Stephen Hemminger wrote:
On Wed, 2 Aug 2006 11:02:20 +0200
Christophe Devriese [EMAIL PROTECTED] wrote:
On Tuesday 01 August 2006 19:21, you wrote:
John W. Linville wrote:
I'm just not sure that cleverness is worth the headache, especially
since the most clever things usually only work by accident...
Or, work by solid, modular design and small tweaks!
Point taken. But stashing little hacks in the networking core for
specific virtual drivers isn't totally modular either. And even if
it were, modular design probably belongs on the list of things
that can be taken too far, like everything in userland, never
use ioctl, and microkernels are superior. :-)
To be honest, I'm not over-joyed to see bridging hooks included
in the VLAN code..but if that is what it takes to get bridging
and VLANs to play well and be flexible, I think it is a fair price.
It certainly wouldn't hurt to have someone take a holistic view of the
various L2 device interactions. Just documenting current functionality
on, say, the netdev wiki would be a good first step.
Ultimate flexibility could be provided by making the netif_rx routine (and the
others, including vlan etc), a virtual routine.
That way a list of filters could be defined that allow any processing to be
done on the packet before it is handed of to the linux kernel's higher
layers, including not delivering it on that interface, or delivering it on
another interface.
This would allow very complex implementations including stuff like a
high-level l2 bridge, with vlan support, and a number of protocols like rstp,
pvst+, ... with relatively simple code, that could be isolated from the main
kernel.
Would anyone be interested in signing off on such a patch ? (which basically
creates netif_rx and vlan_acc_netif_rx lists in the net_device structure, and
then modify bridging and bonding drivers to just use this)
I have thought about this, but you end up reinventing System V streams.
The problem is for simple up/down call, the stacking model works fine but
once you add flow-control and multiplexing issues the problem becomes complex.
It is hard to think of a good general solution where the performance wouldn't
end up sucking.
Currently, the bridge hook logic is something like:
if (bridge-consumed-pkt) {
return
}
// drop through to other layers
There are several other hooks I'd like to see added (pktgen receive processing,
mac-vlans, etc). Each of these hooks are logically similar to the bridge hook,
ie if it consumes the pkt, return, else, drop through to the next hook untill
we get to the regular protocol processing logic.
I would like to be able to chain layer-2 handlers, such as bridge, mac-vlan,
pktgen such that if one consumed, you break out of the handling, else, you
try the next handler. The handlers can be dynamically registered and inserted
in any order, controllable by user-space and/or module load/unload.
For many of the handlers, the logic will re-insert the packet by re-calling the
netif-rx logic, so there would need to be some protection to keep loops from
occurring that would recurse too much and overflow the stack.
Ben
--
Ben Greear [EMAIL PROTECTED]
Candela Technologies Inc http://www.candelatech.com
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Stackable devices.
On Wed, 2 Aug 2006 11:02:20 +0200 Christophe Devriese [EMAIL PROTECTED] wrote: On Tuesday 01 August 2006 19:21, you wrote: John W. Linville wrote: I'm just not sure that cleverness is worth the headache, especially since the most clever things usually only work by accident... Or, work by solid, modular design and small tweaks! Point taken. But stashing little hacks in the networking core for specific virtual drivers isn't totally modular either. And even if it were, modular design probably belongs on the list of things that can be taken too far, like everything in userland, never use ioctl, and microkernels are superior. :-) To be honest, I'm not over-joyed to see bridging hooks included in the VLAN code..but if that is what it takes to get bridging and VLANs to play well and be flexible, I think it is a fair price. It certainly wouldn't hurt to have someone take a holistic view of the various L2 device interactions. Just documenting current functionality on, say, the netdev wiki would be a good first step. Ultimate flexibility could be provided by making the netif_rx routine (and the others, including vlan etc), a virtual routine. That way a list of filters could be defined that allow any processing to be done on the packet before it is handed of to the linux kernel's higher layers, including not delivering it on that interface, or delivering it on another interface. This would allow very complex implementations including stuff like a high-level l2 bridge, with vlan support, and a number of protocols like rstp, pvst+, ... with relatively simple code, that could be isolated from the main kernel. Would anyone be interested in signing off on such a patch ? (which basically creates netif_rx and vlan_acc_netif_rx lists in the net_device structure, and then modify bridging and bonding drivers to just use this) I have thought about this, but you end up reinventing System V streams. The problem is for simple up/down call, the stacking model works fine but once you add flow-control and multiplexing issues the problem becomes complex. It is hard to think of a good general solution where the performance wouldn't end up sucking. -- Stephen Hemminger [EMAIL PROTECTED] And in the Packet there writ down that doome - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
