Just for completeness, I did some tests with and without the JSON parser C extension [0]. There's no significant gain (at this point), maybe when we add the port groups it's more noticeable though. Average time without it's been 2.09s while with the C extension it's been 2.03s.
@Han, I can try rebase the patch if you want but that was basically renaming the Address_Set table and from Ben's comment, it may be better to keep the name. Not sure, however, how we can proceed to address Lucas' points in this thread. Thanks, Daniel [0] https://imgur.com/a/etb5M On Fri, Feb 16, 2018 at 6:33 PM, Han Zhou <zhou...@gmail.com> wrote: > Hi Daniel, > > Thanks for the detailed profiling! > > On Fri, Feb 16, 2018 at 6:50 AM, Daniel Alvarez Sanchez < > dalva...@redhat.com> wrote: > > > > About the duplicated processing of the update2 messages, I've verified > that those are not always present. I've isolated the scenario further and > did tcpdump and debugging on the exact process which is sending > the'transact' command and I see no update2 processing duplicates. Among the > rest of the workers, one of them is always getting them duplicated while > the rest don't I don't know why. > > However, the 'modify' in the LS table for updating the acls set is the > one always taking 2-3 seconds on this load. > > > I think this explains why the time spent grows linearly with number of > lports. Each lport has its own ACLs added to same LS, so the acl column in > the row gets bigger and bigger. It is likely that the port group > optimization would solve this problem. > > Thanks > Han >
_______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
