On 12 July 2014 01:03, Thomas Graf <tg...@noironetworks.com> 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 <f...@redhat.com> 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 look into this as well. > > > > Workqueue is a kernel's facility to defer the work. You can indicate how > > much time from now it should execute it and the work to be done, similar > > to timers. >
I took a bit of a look at them. This approach seems a bit more involved, so I'd like to learn more about how expensive this piece is before launching into something like this. A couple of thoughts: * Requires adding another lock/unlock per flow from a different thread, like the lock-on-dump idea. * If cache construction is queued, then another thread gets/dumps/deletes the flow before cache is constructed, then it needs to assemble the reply anyway. * Furthermore, in the unlikely case that the flow is deleted before cache construction, the workqueue would need to handle the fact the flow has been deleted. (Sounds unlikely with a low enough timer, but needs a bit more thought) On 12 July 2014 01:03, Thomas Graf <tg...@noironetworks.com> wrote: > The difference is that the dump may take the lock even if no cache > construction is needed but that could be optimized by having the dump > function only take the lock if construction is needed and then keeping > it until the message is fully constructed. > We could probably check my suspicions around locking without too much trouble. > I agree though that the alternative idea of fixing up the key is more > attractive if that is doable. > I plan to look at the copy+fixup approach first. If this code is still the most expensive item after that, then it could be worth looking at another approach that allows us to reduce the need to copy so many netlink messages. Cheers, Joe _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
