Re: [libvirt] [PATCH RFC] network: Delay creating private chains until starting network
On 4/30/19 10:34 PM, Jim Fehlig wrote:
Automated performance tests found that network-centric workloads
suffered
a 20 percent decrease when the host libvirt was updated from 5.0.0 to
5.1.0. On the test hosts libvirtd is enabled to start at boot and the
"default" network is defined, but it is not set to autostart.
libvirt 5.1.0 introduced private firewall chains with commit 5f1e6a7d.
The chains are created at libvirtd start, which triggers loading the
conntrack kernel module. Subsequent tracking and processing of
connections resulted in the performance hit. Prior to commit 5f1e6a7d
the conntrack module would not be loaded until starting a network,
when libvirt added rules to the builtin chains.
Restore the behavior of previous libvirt versions by delaying
the creation of private chains until the first network is started.
Signed-off-by: Jim Fehlig <jfehlig(a)suse.com>
---
I briefly discussed this issue with Daniel on IRC and just now finding
time to bring it to the list for broader discussion. The adjustment to
the test file feels hacky. The whole approach might by hacky, hence the
RFC.
src/network/bridge_driver_linux.c | 64 +++-------
.../nat-default-linux.args | 116 ++++++++++++++++++
2 files changed, 131 insertions(+), 49 deletions(-)
I like this. I was under impression that these rules are created if and
only if there's a NATed network found at startup when libvirt is reading
the config files. But that doesn't seem to be the case - we create the
rules even if all users have is one network with <forward mode='open'/>.
You have my +1. I'm not going give explicit ACK (at least for now) until
Dan speaks his mind. He had some opinions and good ideas when I tried to
fix a problem in the same area of the code.
Michal