On Wed, Nov 30, 2011 at 11:52 PM, Herbert Xu
wrote:
> On Thu, Dec 01, 2011 at 04:24:18PM +0900, Simon Horman wrote:
>>
>> So while I agree that optimizing the hash is a good idea. I don't believe
>> it is a bottle-neck at this point. Though I could be convinced otherwise if
>> long collision chai
On Thu, Dec 01, 2011 at 03:52:37PM +0800, Herbert Xu wrote:
> On Thu, Dec 01, 2011 at 04:24:18PM +0900, Simon Horman wrote:
> >
> > So while I agree that optimizing the hash is a good idea. I don't believe
> > it is a bottle-neck at this point. Though I could be convinced otherwise if
> > long col
On Thu, Dec 01, 2011 at 04:24:18PM +0900, Simon Horman wrote:
>
> So while I agree that optimizing the hash is a good idea. I don't believe
> it is a bottle-neck at this point. Though I could be convinced otherwise if
> long collision chains could be constructed with relatively few flows.
> Someth
On Wed, Nov 30, 2011 at 03:02:19PM +0800, Herbert Xu wrote:
> On Tue, Nov 29, 2011 at 10:21:32PM -0800, Jesse Gross wrote:
> >
> > It's userspace which is managing the entries in the kernel hash table
> > and it has some intelligence about aging out entries (and specifically
> > about doing it more
On Tue, 2011-11-29 at 22:18 -0800, Jesse Gross wrote:
> As Jamal alluded to above, it's
> actually the bridge code which is more conceptually similar.
Either you misread what i said or i miscommunicated.
The exact similarity is in classifier action in the datapath.
The bridge, as i suggested, co
On Tue, Nov 29, 2011 at 10:18:02PM -0800, Jesse Gross wrote:
>
> 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 co
On Tue, Nov 29, 2011 at 10:21:32PM -0800, Jesse Gross wrote:
>
> It's userspace which is managing the entries in the kernel hash table
> and it has some intelligence about aging out entries (and specifically
> about doing it more aggressively as the number of entries increases),
> so it's not reall
On Mon, Nov 28, 2011 at 6:51 AM, Herbert Xu wrote:
> There are other issues with the hash implementation. For example,
> there seems to be no limit on the number of collisions in each
> bucket. As the hash table growth code simply continues when it
> fails to expand, this means that the number o
On Mon, Nov 28, 2011 at 5:04 AM, Herbert Xu 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 fi
On Mon, Nov 28, 2011 at 05:21:13PM -0500, Jamal Hadi Salim wrote:
> On Mon, 2011-11-28 at 08:01 -0800, Ben Pfaff wrote:
>
> > Regarding OpenFlow rate limiting, in addition to Martin's response, Open
> > vSwitch has implemented controller rate limiting since day one. It is
> > documented in ovs-vs
On Mon, 2011-11-28 at 08:01 -0800, Ben Pfaff wrote:
> Regarding OpenFlow rate limiting, in addition to Martin's response, Open
> vSwitch has implemented controller rate limiting since day one. It is
> documented in ovs-vswitchd.conf.db(5):
Ok, I think thats a good start. My experience says just
> Subject: Re: [ovs-dev] [GIT PULL v2] Open vSwitch
>
> On Mon, Nov 28, 2011 at 01:54:16PM +, Fischer, Anna wrote:
> > Yes, I mentioned this months ago, and I am surprised this critical
> > issue has never been picked up on and addressed. With a flaw like
> this
>
On Mon, Nov 28, 2011 at 01:54:16PM +, Fischer, Anna wrote:
> Yes, I mentioned this months ago, and I am surprised this critical
> issue has never been picked up on and addressed. With a flaw like this
> there is no chance this component can be used in any serious
> virtualization deployment whe
On Mon, Nov 28, 2011 at 09:02:34AM -0500, Jamal Hadi Salim wrote:
> On Mon, 2011-11-28 at 21:04 +0800, Herbert Xu wrote:
> > However, what's more worrying for me right now is the gaping
> > DoS opportunities that exist in the patch as is.
> >
> > In particular, the whole design principle of puntin
This is a common misunderstanding about OpenFlow. It does not require
the first packet of each flow to go to the controller.
I am reading this to mean that the switch CPU will resolve things?
Typically those tend to be tiny cpus.
No, no datapath traffic leaves the switching chip. Generally
co
On Mon, 2011-11-28 at 07:27 -0800, Martin Casado wrote:
> This is a common misunderstanding about OpenFlow. It does not require
> the first packet of each flow to go to the controller.
I am reading this to mean that the switch CPU will resolve things?
Typically those tend to be tiny cpus.
>
However, what's more worrying for me right now is the gaping
DoS opportunities that exist in the patch as is.
In particular, the whole design principle of punting all new
flows to user-space is an excellent way of attacking the system.
Indeed this is an issue with openflow in general.
The gene
On Mon, Nov 28, 2011 at 01:54:16PM +, Fischer, Anna wrote:
>
> Yes, I mentioned this months ago, and I am surprised this critical issue has
> never been picked up on and addressed. With a flaw like this there is no
> chance this component can be used in any serious virtualization deployment
On Mon, 2011-11-28 at 21:04 +0800, Herbert Xu wrote:
> You're right, a new classifier for the hash table would be the
> best option.
>
> > 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
> Subject: Re: [GIT PULL v2] Open vSwitch
>
> On Wed, Nov 23, 2011 at 07:22:56AM -0500, jamal wrote:
> >
> > For a classifier, u32 or em matches would do the job - but they may
> > need a wrapper around it in user space; so from a usability pov, it
> > would make sense to have a new classifier th
On Wed, Nov 23, 2011 at 07:22:56AM -0500, jamal wrote:
>
> For a classifier, u32 or em matches would do the job - but they may
> need a wrapper around it in user space; so from a usability pov, it
> would make sense to have a new classifier that is specific to them.
> All the VLAN actions could go
On Sun, 2011-11-27 at 20:34 +0100, Lennert Buytenhek wrote:
> On Thu, Nov 24, 2011 at 08:19:39AM -0500, Jamal Hadi Salim wrote:
> There's a bunch of features that the hardware supports that have no
> analog in the Linux networking stack (e.g. port mirroring a non-CPU
> port to another non-CPU por
On Thu, Nov 24, 2011 at 08:19:39AM -0500, Jamal Hadi Salim wrote:
> > 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_c
On Wed, 2011-11-23 at 08:05 -0800, John Fastabend wrote:
> > 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.
What i mean is RCU is useful when you have a substantial
On Wed, 2011-11-23 at 15:15 +0100, Eric Dumazet wrote:
>
> Or, we could stick documentation in kernel (Documentation/network/...),
> so that we give credit to contributors to this essential part of the
> network stack.
>
That would work - but i dont know how many "users" read
Documentation/netw
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
Le mercredi 23 novembre 2011 à 08:36 -0500, jamal a écrit :
> 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
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 need
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 t
On 11/23/2011 01:47 PM, jamal wrote:
On Wed, 2011-11-23 at 09:12 +0100, Eric Dumazet wrote:
I had no time to look at OVS, but current tc model is not scalable,
everything is performed under a queue lock.
Maybe its time to redesign a new model, based on modern techniques.
Making the enqueur/deq
Le mercredi 23 novembre 2011 à 07:47 -0500, jamal a écrit :
> On Wed, 2011-11-23 at 09:12 +0100, Eric Dumazet wrote:
>
> > I had no time to look at OVS, but current tc model is not scalable,
> > everything is performed under a queue lock.
> > Maybe its time to redesign a new model, based on modern
On Wed, 2011-11-23 at 09:12 +0100, Eric Dumazet wrote:
> I had no time to look at OVS, but current tc model is not scalable,
> everything is performed under a queue lock.
> Maybe its time to redesign a new model, based on modern techniques.
Making the enqueur/dequeuer lockless would be a big win.
On Wed, 2011-11-23 at 15:54 +0800, Herbert Xu wrote:
> I mostly agree with Jamal. As far as the concept of a policy
> lookup cache goes (which appears to be at the core of OVS), this
> almost fits exactly onto a u32 hash table. All that would be needed
> is to add the tail end of the policies, e
On Wed, Nov 23, 2011 at 09:12:22AM +0100, Eric Dumazet wrote:
>
> I had no time to look at OVS, but current tc model is not scalable,
> everything is performed under a queue lock.
>
> Maybe its time to redesign a new model, based on modern techniques.
Indeed, I pointed this out numerous times over
Le mercredi 23 novembre 2011 à 15:54 +0800, Herbert Xu a écrit :
> David Miller wrote:
> >
> > I would like to see some discussion wrt. Jamal's feedback, which is that
> > a lot of the side-band functionality added by this code is either 1) already
> > doable with packet scheduler actions or 2) s
David Miller wrote:
>
> I would like to see some discussion wrt. Jamal's feedback, which is that
> a lot of the side-band functionality added by this code is either 1) already
> doable with packet scheduler actions or 2) should be implemented there.
I mostly agree with Jamal. As far as the conc
* Stephen Hemminger (shemmin...@vyatta.com) wrote:
> Maybe someone with more insight than me can explain the relationship
> between Openflow and Open vSwitch. It maybe that the portability
> of Openflow makes the old qdisc, classifiers to use/implement.
I'm sure I can't answer the last bit as well
Maybe someone with more insight than me can explain the relationship
between Openflow and Open vSwitch. It maybe that the portability
of Openflow makes the old qdisc, classifiers to use/implement.
___
dev mailing list
dev@openvswitch.org
http://openvswitc
I would like to see some discussion wrt. Jamal's feedback, which is that
a lot of the side-band functionality added by this code is either 1) already
doable with packet scheduler actions or 2) should be implemented there.
___
dev mailing list
dev@openvsw
This series of patches proposes the Open vSwitch kernel components for
upstream. Open vSwitch has existed as a separate project for several
years and we now believe it to be mature enough for inclusion. The
actual functionality is described more fully in the commit that adds
the kernel code.
The
40 matches
Mail list logo
