[libvirt] [PATCH RFC] network: Delay creating private chains until starting network

[Michal Privoznik]

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 at 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