netdev - Re: [GIT PULL v2] Open vSwitch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 23 Nov 2011 08:36:17 -0500
From:	jamal <hadi@...erus.ca>
To:	David Täht <dave.taht@...il.com>
Cc:	Eric Dumazet <eric.dumazet@...il.com>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	David Miller <davem@...emloft.net>, jesse@...ira.com,
	netdev@...r.kernel.org, dev@...nvswitch.org
Subject: Re: [GIT PULL v2] Open vSwitch

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

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html