On Mon, 26 Oct 2020, Cezar Sá Espinola wrote:
> Hi all. This is my first message here and also my first attempt at kernel
> development so I'm a bit nervous and afraid I'm doing something wrong.
> The last few days I've been toying with a patch to IPVS to allow me to use
> netlink to dump all services and all its destinations in a single call.
> The motivation for this came after profiling a kubernetes node machine with a
> few thousand IPVS services each with an average of two destinations. The
> component responsible for ensuring that the IPVS rules are correct always
> a fresh dump of all services with all destinations and currently this is
> accomplished by issuing a IPVS_CMD_GET_SERVICE generic netlink dump command
> followed by multiple IPVS_CMD_GET_DEST dump commands.
This is how ipvsadm -S runs now, list_all() gets all
services and for each gets its destinations.
> The patch in question adds a new netlink command IPVS_CMD_GET_SERVICE_DEST
> which dumps all services where each service is followed by a dump of its
> destinations. It's working now on my machine and some preliminary experiments
> show me that there's a significant performance improvement in switching to a
> single call to dump everything. However, I have some questions that I'd like
> talk about before trying to submit it.
> 1. First of all is such a patch adding a new command something desirable and
> could it possibly be merged or should I just drop it?
It depends on its complexity, are you changing
the ipvsadm -S code or just the kernel part?
> 2. I can see that besides the generic netlink interface there's also another
> interface based on getsockopt options, should the patch also add a new socket
> option or is it okay for this new functionality to be exclusive to generic
No, sockopt is old interface and it is not changed,
it lacks IPv6 support, etc.
> 3. Should this go forward, any advice on my next steps? Should I simply send
> patch here?
You can post it with [PATCH RFC] tag, so that we
can see how do you mix services and destinations in same
packet. You can also add speed comparison after the --- line
for more information.
Julian Anastasov <ja@xxxxxx>