jamal wrote:
> IP rules. Who cares about
> IPX? Just encapsulate it (IPX) in the ether-packet and let it be
> switched/routed somewhere. some policy maps it to some VLAN. Is this not
> sufficient?
It's already been explained several times in this thread why this is
not so - namely, that one of the major uses of vlans is to isolate
large networks running broadcast-happy protocols in such a way that
they can still talk to their servers directly. Suppose you had a
big appletalk installation - you could split it in 10 pieces by VLAN
and then have your linux+netatalk servers bring in all the VLANs
on 802.1q.
Only your IP-centric solution doesn't handle this very well.
> We already have a very powerful modular routing architecture; use the
> route flags and dst_in/out properly and you have yourself specific routing
> code which does not touch the common path *at all*
Do you have a reference for this code - I wonder if we could make ATM-CLIP
work better.
Still, I don't see it as relevant to the VLAN discussion. The biggest problem
with your idea is that it changes the API that protocols use to pass
packets out a VLAN opposed to a LAN (i.e. net_device), you're changing
the abstration used for lots of configuring protocls (i.e. net_device),
and you're changing the abstration presented to the user space tools
(i.e. a named net_device)
jamal - answer this one question: what plans do you have for PPPoE?
After all, it's just another protocol for expressing VLANs on an
ethernet. It also has the exact same (supposedly fatal) flow
control issues that VLANs have. Therefore, I assume your arguments
are the same against them being a net_device, right? This one's
particularly hairy because you'll need to keep the ppp_generic
layer the same (to interface with pppd and speak the various PPP
protocols... this will become more even more important if we do
some of the things proposed for 2.5 like ppp-layer-bridging)
I'd like to see your proposal for handling this (and I mean a
real proposal, not just "use netfilter")
Technically, while you're fixing places that have broken flow control,
you can note that the same is true of any net_device that internally
uses dev_queue_xmit. Specifically, eql.c, shaper.c, bonding.c are
all busted in the same way you describe. These actually could
be done with netfilter, though, so I'm more interested in the PPPoE
implementation.
> I dislike extending the kernel to 'help' a few things at the expense of
> the common path.
I don't see where you can claim to hold the high ground on "common path".
-Mitch
|