From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamal Hadi Salim Subject: Re: Integration of Open vSwitch Date: Mon, 05 Dec 2011 08:49:03 -0500 Message-ID: <1323092943.1831.19.camel@mojatatu> References: <1322658716.2243.12.camel@mojatatu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org, Chris Wright , Herbert Xu , Eric Dumazet , netdev , John Fastabend , Stephen Hemminger , David Miller To: Jesse Gross Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dev-bounces-yBygre7rU0TnMu66kgdUjQ@public.gmane.org Errors-To: dev-bounces-yBygre7rU0TnMu66kgdUjQ@public.gmane.org List-Id: netdev.vger.kernel.org Jesse, I empathize with effort youve put in, i really do; youve already created the messaging from user space to kernel and dammit it works; however, i dont agree with your reasoning. The classifier action code is _exactly_ the same infrastructure. The user space API/messaging already exists. If there are actions or a classifier missing - add it. I wish i had the time to re-write the pieces i think need changing. If the plan is to migrate to the current tc action code, I will be fine with it - but you are not even suggesting that. I think i will punt this to DaveM to make the call. cheers, jamal On Fri, 2011-12-02 at 15:30 -0800, Jesse Gross wrote: > > I completely agree with the desire to share code where there's overlap > and it makes sense (I was actually just working on some refactoring to > increase code reuse before this). > > I think one of the key things to focus on is the userspace/kernel > interface since we'll have much less opportunity to significantly > change that over time. Getting both compatibility and performance is > something that we've worked on a fair amount and have arrived at a > solution that meets the needs of OVS (and probably only OVS) pretty > well. I think it's a nice model but keeping that while refactoring on > top of the tc layer seems challenging to do cleanly because the flow > information is needed by both the flow lookup and userspace > communication. Stringing that through generic code seems fairly > unappealing. > > So I agree with you in principle and if you are right that things tend > to converge there should be more room for code reuse over time. Right > now though I would just focus on the high level bits.