netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christophe Devriese <Christophe.Devriese@eurid.eu>
To: netdev@vger.kernel.org
Subject: Re: Linville's L2 rant... -- Re: PATCH Fix bonding active-backup behavior for VLAN interfaces
Date: Wed, 2 Aug 2006 11:02:20 +0200	[thread overview]
Message-ID: <200608021102.20604.Christophe.Devriese@eurid.eu> (raw)
In-Reply-To: <44CF8D8A.5080101@candelatech.com>

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) 

Regards,

Christophe

  reply	other threads:[~2006-08-02  9:02 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-28  9:44 PATCH Fix bonding active-backup behavior for VLAN interfaces Christophe Devriese
2006-07-28 16:01 ` Ben Greear
2006-07-28 21:50   ` Christophe Devriese
2006-07-28 21:55     ` Ben Greear
2006-07-28 22:15       ` Christophe Devriese
     [not found]       ` <20060728221455.GA25610@walrus.eth1.org>
     [not found]         ` <44CA8AF1.3020408@candelatech.com>
2006-07-28 22:58           ` Christophe Devriese
2006-07-28 22:55             ` David Miller
2006-07-28 23:14               ` Ben Greear
2006-07-31  3:50       ` David Miller
2006-07-31  8:15         ` Christophe Devriese
2006-07-31 12:30           ` Linville's L2 rant... -- " John W. Linville
2006-07-31 16:48             ` Christophe Devriese
2006-08-01  1:39             ` Jamal Hadi Salim
2006-08-01 12:08               ` John W. Linville
2006-08-01 12:33                 ` Jamal Hadi Salim
2006-08-01 16:10                   ` Ben Greear
2006-08-01 16:52                     ` John W. Linville
2006-08-01 17:04                       ` Ben Greear
2006-08-01 19:47                         ` Krzysztof Halasa
2006-08-01 16:48                   ` John W. Linville
2006-08-01 16:17                 ` Ben Greear
2006-08-01 17:03                   ` John W. Linville
2006-08-01 17:21                     ` Ben Greear
2006-08-02  9:02                       ` Christophe Devriese [this message]
2006-08-02 17:37                         ` Stackable devices Stephen Hemminger
2006-08-02 17:50                           ` Ben Greear
2006-08-08 12:03                             ` Christophe Devriese
2006-08-08 16:36                               ` Ben Greear
2006-08-09 13:57                                 ` Christophe Devriese
2006-08-12 18:43                                   ` Ben Greear
2006-08-12 19:29                                   ` Ben Greear
2006-08-02 20:58           ` PATCH Fix bonding active-backup behavior for VLAN interfaces David Miller
2006-08-03  9:18             ` Krzysztof Oledzki
2006-08-10 18:18               ` Krzysztof Oledzki
2006-08-11  6:45                 ` David Miller
2006-08-11  8:50                   ` Christophe Devriese
2006-08-11  8:53                     ` David Miller
2006-08-14  8:16                   ` Christophe Devriese
2006-08-14  8:47                     ` David Miller
2006-08-14  8:47                     ` David Miller
2006-08-03 13:34             ` Christophe Devriese
2006-08-04  1:01             ` Jay Vosburgh
2006-08-15  0:09               ` David Miller
2006-08-15 22:18                 ` Jay Vosburgh
2006-08-15 22:27                   ` David Miller
2006-08-16 19:30                 ` Krzysztof Oledzki
2006-08-20 19:41                 ` Christophe Devriese

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200608021102.20604.Christophe.Devriese@eurid.eu \
    --to=christophe.devriese@eurid.eu \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).