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

[Stephen Suryaputra <ssuryaextr@gmail.com>]

On Sun, Sep 19, 2021 at 03:07:34AM +0200, Andrew Lunn wrote:
> 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?

That particular goal by Eric isn't exactly my goal. I extended his
approach to be more inline with the latest feedback he got. My
application is written for an embedded router and for it
/usr/include/linux/mroute.h is coming from the
include/uapi/linux/mroute.h. So, the new structure mfcctl_ext can be
used by the application.
> 
> 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.

This proposal doesn't change any existing ones such as MRT_ADD_MFC,
MRT_ADD_VIF, MRT6_ADD_MFC and MRT6_ADD_MIF as they are still using the
unchanged MAXVIFS. So, if the applications such as quagga still use the
existing mroute.h it should still be working with the 32 vifs
limitation.

To use more than 32 vifs, then MRT_ADD_MFC_EXT, etc can be used. But for
that the applications need to be modified and be using the updated
mroute.h and mroute6.h.

Regards,
Stephen.