On Wed, May 13, 2015 at 6:05 AM, Guillermo Ontañón
wrote:
> On Wed, May 13, 2015 at 1:00 AM, Ben Pfaff wrote:
>> On Tue, May 12, 2015 at 10:21:19AM +0200, Duarte Nunes wrote:
>> Second, is it possible to use a better data structure? Perhaps one
>> could, for example, use a mutex per hash chain,
On Thu, May 14, 2015 at 2:17 AM, Jesse Gross wrote:
> This is basically an internal kernel optimization, so I agree with Ben
> that I would prefer not making userspace aware of this. I don't really
> think that changing the locking along the lines of what is described
> above is actually more comp
Hi Ben,
On Wed, May 13, 2015 at 1:00 AM, Ben Pfaff wrote:
> On Tue, May 12, 2015 at 10:21:19AM +0200, Duarte Nunes wrote:
>> We've observed that for high flow setup rates, the flow table becomes a
>> bottleneck since it only allows a single writer (all CRUD flow operations
>> take the ovs_mutex).
On Tue, May 12, 2015 at 10:21:19AM +0200, Duarte Nunes wrote:
> We've observed that for high flow setup rates, the flow table becomes a
> bottleneck since it only allows a single writer (all CRUD flow operations
> take the ovs_mutex).
>
> A solution for this is to shard the flow table. A hash func
Hi all,
We've observed that for high flow setup rates, the flow table becomes a
bottleneck since it only allows a single writer (all CRUD flow operations
take the ovs_mutex).
A solution for this is to shard the flow table. A hash function is used to
know which table to query on packet ingress and
