lvs-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Possibility of adding a new netlink command to dump everything
@ 2020-10-26 15:27 Cezar Sá Espinola
  2020-10-26 19:35 ` Julian Anastasov
  0 siblings, 1 reply; 3+ messages in thread
From: Cezar Sá Espinola @ 2020-10-26 15:27 UTC (permalink / raw)
  To: lvs-devel

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 needs
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.

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 to
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?

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
netlink?

3. Should this go forward, any advice on my next steps? Should I simply send the
patch here?

Thank you for your time!

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Possibility of adding a new netlink command to dump everything
  2020-10-26 15:27 Possibility of adding a new netlink command to dump everything Cezar Sá Espinola
@ 2020-10-26 19:35 ` Julian Anastasov
  2020-10-26 19:47   ` Cezar Sá Espinola
  0 siblings, 1 reply; 3+ messages in thread
From: Julian Anastasov @ 2020-10-26 19:35 UTC (permalink / raw)
  To: Cezar Sá Espinola; +Cc: lvs-devel

[-- Attachment #1: Type: text/plain, Size: 2237 bytes --]


	Hello,

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 needs
> 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 to
> 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
> netlink?

	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 the
> 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.

Regards

--
Julian Anastasov <ja@ssi.bg>

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Possibility of adding a new netlink command to dump everything
  2020-10-26 19:35 ` Julian Anastasov
@ 2020-10-26 19:47   ` Cezar Sá Espinola
  0 siblings, 0 replies; 3+ messages in thread
From: Cezar Sá Espinola @ 2020-10-26 19:47 UTC (permalink / raw)
  To: Julian Anastasov; +Cc: lvs-devel

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

Thank you for the fast reply! Just the kernel part for now and some
crude standalone benchmarking code, although I intend to also change
the ipvsadm -S code to use this new cmd if available.

> > 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
> > netlink?
>
>         No, sockopt is old interface and it is not changed,
> it lacks IPv6 support, etc.

Great.

> > 3. Should this go forward, any advice on my next steps? Should I simply send the
> > 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.

I'll do that and we can discuss further then. Thanks a lot for your time!

Regards
--
Cezar Sá Espinola

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2020-10-26 19:47 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-10-26 15:27 Possibility of adding a new netlink command to dump everything Cezar Sá Espinola
2020-10-26 19:35 ` Julian Anastasov
2020-10-26 19:47   ` Cezar Sá Espinola

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).