Re: [RFC PATCH net-next] ipmr: ip6mr: APIs to support adding more than MAXVIFS/MAXMIFS

On Fri, Sep 17, 2021 at 06:41:23PM -0400, Stephen Suryaputra wrote:

MAXVIFS and MAXMIFS are too small (32) for certain applications. But
they are defined in user header files  So, use a different definition
CONFIG_IP_MROUTE_EXT_MAXVIFS that is configurable and different ioctl
requests (MRT_xyz_EXT and MRT6_xyz_EXT) as well as a different structure
for adding MFC (mfcctl_ext).

CONFIG_IP_MROUTE_EXT_MAXVIFS is bounded by the IF_SETSIZE (256) in
mroute6.h.

This patch is extending the following RFC:
http://patchwork.ozlabs.org/project/netdev/patch/m1eiis8uc6.fsf@fess.ebiederm.org/

Quoting the above URL:

My goal is an API that works with just a recompile of existing
applications, and an ABI that continues to work for old applications.

Does this really work? Does the distribution version of mrouted use
the kernel UAPI headers of the running kernel? Can i upgrade to a
newer kernel, with newer headers, and it automagically pulls in a new
mrouted built using the new kernel headers? I think not. ethtool has
its own copy of the kernel headers. mrouted uses
/usr/include/linux/mroute.h which is provided by
linux-libc-dev:amd64. That is not tied to the running kernel. What
about quagga?

So in effect, you have to ask the running kernel, what value is it
using for MAXVIFS? Which means it is much more than just a recompile.
So i doubt think you can achieve this goal.

Given that, i really think you should spend the time to do a proper
solution. Add a netlink based API, which does not have the 32 limit.
Make the kernel implementation be based on a linked list. Have the
ioctl interface simply return the first 32 entries and ignore anything
above that.

      Andrew