On 12 July 2014 00:55, Thomas Graf wrote:
> On 07/11/14 at 11:29pm, Joe Stringer wrote:
> > I'm skeptical of taking the ovs_lock(). The current patch performs this
> > key/mask cache construction inside ovs_lock() as part of the critical
> > section for flow install. If we perform this during flo
On 12 July 2014 01:03, Thomas Graf wrote:
> On 07/11/14 at 09:28am, Flavio Leitner wrote:
> > On Fri, Jul 11, 2014 at 11:27:09AM +1200, Joe Stringer wrote:
> > > On 11 July 2014 04:53, Flavio Leitner wrote:
> > >
> > > > Can we push the cache construction to later that it doesn't impact
> > > >
On 12 July 2014 00:55, Thomas Graf wrote:
> > Another sidenote:
>
> > Looking at the code, OVS does not handle NLM_F_DUMP_INTR in user space
> yet
> > > and the kernel dump does not call genl_dump_check_consistent() yet to
> > > provide
> > > the flag. So what can currently happen even without y
On 07/11/14 at 09:28am, Flavio Leitner wrote:
> On Fri, Jul 11, 2014 at 11:27:09AM +1200, Joe Stringer wrote:
> > On 11 July 2014 04:53, Flavio Leitner wrote:
> >
> > > Can we push the cache construction to later that it doesn't impact
> > > either flow setup or flow dump? I.e. like a workqueue?
On 07/11/14 at 11:29pm, Joe Stringer wrote:
> I'm skeptical of taking the ovs_lock(). The current patch performs this
> key/mask cache construction inside ovs_lock() as part of the critical
> section for flow install. If we perform this during flow_dump, but extend
> the ovs_lock to the entire flow
On Fri, Jul 11, 2014 at 11:27:09AM +1200, Joe Stringer wrote:
> On 11 July 2014 04:53, Flavio Leitner wrote:
>
> > Can we push the cache construction to later that it doesn't impact
> > either flow setup or flow dump? I.e. like a workqueue? I don't know
> > if we have such facility.
>
>
> I'm o
On 11 July 2014 21:03, Thomas Graf wrote:
> > Correct. My main concern with doing it the first time it is required, is
> > how it's synchronised. Flow dump is RCU. I don't really know what the
> > threadsafety requirements are for this code, or what options are
> available
> > to address this. Is
On 07/11/14 at 11:22am, Joe Stringer wrote:
> Thanks for the review,
>
> On 10 July 2014 21:13, Thomas Graf wrote:
>
> > If I understand the code correctly the gain is only visible on
> > consecutive dumps of the same flow. How about constructing the cache
> > when you require it for the first t
On 11 July 2014 04:53, Flavio Leitner wrote:
> Can we push the cache construction to later that it doesn't impact
> either flow setup or flow dump? I.e. like a workqueue? I don't know
> if we have such facility.
I'm open to the idea, but completely unfamiliar with how these work. I can
take a l
Thanks for the review,
On 10 July 2014 21:13, Thomas Graf wrote:
> If I understand the code correctly the gain is only visible on
> consecutive dumps of the same flow. How about constructing the cache
> when you require it for the first time? That avoids the cost on flow
> setup.
Correct. My m
On Thu, Jul 10, 2014 at 11:13:33AM +0200, Thomas Graf wrote:
> On 07/10/14 at 05:29pm, Joe Stringer wrote:
> > Converting the flow key and mask back into netlink format during flow
> > dump is fairly expensive. By caching the netlink versions of these
> > during flow setup, and copying the memory d
On 07/10/14 at 05:29pm, Joe Stringer wrote:
> Converting the flow key and mask back into netlink format during flow
> dump is fairly expensive. By caching the netlink versions of these
> during flow setup, and copying the memory directly during flow dump, we
> are able to support up to 33% more flo
Converting the flow key and mask back into netlink format during flow
dump is fairly expensive. By caching the netlink versions of these
during flow setup, and copying the memory directly during flow dump, we
are able to support up to 33% more flows in the datapath. Flow setup
rate decreases by aro
13 matches
Mail list logo
