ligato / vpp-agent

⚡️ Control plane management agent for FD.io's VPP
https://docs.ligato.io/
Apache License 2.0
247 stars 127 forks source link

Optimize dumping VPP state #1458

Open ondrej-fabry opened 5 years ago

ondrej-fabry commented 5 years ago

Current implementation of VPP interface dumping in ifplugin/vppcalls is composed of several binapi requests for various parts required to return all relevant information. This is very inefficient where there is a lot of interfaces.

This issue opens a discussion for ways to optimize this.

Ideas:

VladoLavor commented 5 years ago

Skip dump for interface types that are not used

Not sure what it means, how do you know what interface types are not used?

One possible optimization could be a kind of a just-in-time dump for interfaces. It means that instead of dumping everything at once, the DumpInterfaces would return just details from the binary API, and the dumped interface object would not contain information about IP address, type details, etc.

Then the vppcalls API defines methods to dump all the stuff which is currently a part of the top-level method. These require InterfaceIndex as a parameter so it will not return any redundant data, only for the interface we need. We can even define some custom object returned from the DumpInterfaces (in form of a list as it is now) and define these partial dump methods on it for convenience. Have a look at the pseudo-code:

vppIfs, err := d.ifHandler.DumpInterfaces() // only index, link-state, MTU, ...
for _, intf := range vppIfs {
    if (condition) {
        // Here I need to know IP address
        addrs := intf.dumpIPAddresses() 
        ...
    else if (condition) {
        // Here I need to know RX mode
        rxMode := intf.dumpRxMode()
        ...
    }
    ...
}

This approach can possibly decrease binary API calls. Dumped data can be stored in the intf instance, so there would be no need to do it again later (the partial dumpSomething() method can check whether the required data is available, and call dump it if not).

Also, the interface type can be guessed since internal names are pretty much fixed (I think we already do it somewhere) so there is no need to iterate over and call every dump type method.