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:05:00 -0800
From:	John Fastabend <john.r.fastabend@...el.com>
To:	Jamal Hadi Salim <jhs@...atatu.com>
CC:	Eric Dumazet <eric.dumazet@...il.com>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	David Miller <davem@...emloft.net>,
	"jesse@...ira.com" <jesse@...ira.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"dev@...nvswitch.org" <dev@...nvswitch.org>
Subject: Re: [GIT PULL v2] Open vSwitch

On 11/23/2011 5:44 AM, Jamal Hadi Salim wrote:
> On Wed, 2011-11-23 at 13:55 +0100, Eric Dumazet wrote:
> 
>> Currently thinking about it. I was also waiting Tom Herbert BQL patches.
> 
> Excellent. I can test when you have something.
> 
>> Several people are interested, and John Fastabend told me he plans to :
>>
>>  (1) rcu'ify classifiers/actions as needed
> 
> Makes sense in most cases. If you have a lot of flow setup/teardown
> it may harm.

We could have a CONFIG option to always do locking in some
cases if thats not too ugly.

> Another one - but dont see how much you can do about this; useful
> when you want to share state (eg multiple flows being policed
> by a single rate meter);
> An action could be shared across multiple policies i.e you can
> have:
> match1, action foo instance 1, action bar instance 3
> match2, action bar instance3
> match3, ....
> This could would mean a lock contended across cpus when different
> flows hitting match1/2 show up on different cpus.
>  
>>  (2) add flag to drop qdisc lock on simple or hw qdiscs
> 
> Where does config for the hardware happen from?
> 

I assume you mean something like setup_tc() which we have
today to call into into the driver at qdisc create time. This
happens with the RTNL held. I don't see any reason not to also
call into the hardware on qdisc_change() I just haven't done
it yet.

Although I'm pretty sure we don't want to add a new ndo_ops
ever time we have some hardware feature we want to expose.
Assuming there are more than 1 or 2 hw features. So maybe
we could convert to something more generic. A setup_qos()
call that passes an skb with nl attributes.

Is that what you were asking?

>>  (3) mq and mqprio call root qdisc and run a pass over classifiers
>>      actions possibly resetting queue_mapping.
> 
> 
> It seems to make sense - but I will wait and see to have better
> understanding.

One of the problems this resolves is not being able to
call the classifier-actions until after the queue is
already selected. At this point you can't send it to
a higher/lower priority queue.

I'm traveling for a couple days, but I'll try to get
some actual patches out next week to illustrate this.

Thanks,
John

> 
> 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

--
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