On Mon, Nov 28, 2011 at 5:04 AM, Herbert Xu <herb...@gondor.apana.org.au> wrote: > On Wed, Nov 23, 2011 at 07:22:56AM -0500, jamal wrote: >> I cant find one - you may. After staring at the code, I am also now >> questioning if the existing bridge code couldnt have been re-used with >> some small tweaks. > > I wasn't able to find any functionality that could not be easily > done with the existing classifier/action code. > > Whether we want to go down this route though is open to debate > as someone would have to actually implement this :)
Thanks for taking the time to go through the code Herbert. I think this conversation overall has suffered some from being a little vague and high level so it helps a lot to have more people who have looked at the code. The main part that worries me about moving to a different approach is the impedance mismatch that occurs from the fact that Open vSwitch is modeling a switch and tc is not. As Jamal alluded to above, it's actually the bridge code which is more conceptually similar. In my experience, combining two disparate models makes things harder over the long run, not easier. It also tends to show up more in some of the edges like userspace/kernel compatibility. What I'd like to do is start a clean conversation (this one is far too long already) about what an Open vSwitch built using these components would look like and really go into the details and design implications. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
