Re: [GIT PULL v2] Open vSwitch

From: jamal <hadi-fAAogVwAN2Kw5LPnMra/2Q@public.gmane.org>
To: "David Täht" <dave.taht-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org,
	Herbert Xu
	<herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>,
	Eric Dumazet
	<eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Subject: Re: [GIT PULL v2] Open vSwitch
Date: Wed, 23 Nov 2011 08:36:17 -0500	[thread overview]
Message-ID: <1322055377.2039.179.camel@mojatatu> (raw)
In-Reply-To: <4ECCF17D.5020509-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

On Wed, 2011-11-23 at 14:13 +0100, David Täht wrote:

> It's not so much 'modern tecniques', as modern environments.

modern as in "presence of a gazillion cpus" all trying to send
to that 40G port. You wont see much difference in a 2-4 cpu
sending to a GIG port.

> High on my list would be a way to more easily expose QoS and AQM
> features in the hardware all the way up the stack.
>
> I'd like the hardware to be able to express 'I have FQ', or 'I have red',
> much like we express many other features in ethtool, only abstractly 
> enough so that a qdisc setup can be made generic.
> 

Its been done - the challenge is agreeing on what the best path is.
My view is that we still need whatever thing the hardware can do
in software so we can configure the hardware with zero changes to
the user space architecture. The datapath can be bypassed.

> I find the mapping from hardware queues to any sort of complex software 
> queuing scheme hard to conceptualize. Also, as structured, tc cannot be 
> easily applied to wireless APs.

I didnt follow what that means - but you have all the tools you need.
You may need to provide the user a slightly different abstraction than
what tc provides. tc actually has a BNF grammar, so theres plenty of
opportunities to abstract.
i.e if tc was C then you may need to write a python interface
that uses C underneath.

> After burning the last several months getting good enough at the tc layer
> to do stuff in it, I would certainly like to have a place to put 
> documentation,
> and also easily update what already exists.
> 
> If it helps any I could offer a redmine instance on bufferbloat.net for 
> this.
> redmine has bug tracking and a wiki...
> 
> It would be nice also if the iproute2 code contained more working examples,
> and man pages.

man pages exist.
iproute2 has docs - that may be dated and need patching.

> It's a ton of doc work, but I'd be willing to do some of it.

If you wanna do this right - I suggest you get a different domain name.
tc.org or something along those lines.
Start aggregating documentation that is validated to be working. There's
a lot of "opinions" out there instead of facts.

cheers,
jamal

_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev