On Wed, Sep 26, 2018 at 10:23 AM Roopa Prabhu <ro...@cumulusnetworks.com> wrote: > > On Tue, Sep 25, 2018 at 2:34 AM, Patrick Ruddy > <pru...@vyatta.att-mail.com> wrote: > > On Wed, 2018-09-19 at 21:47 -0700, David Ahern wrote: > >> On 9/18/18 6:12 AM, Patrick Ruddy wrote: > >> > > >> > I've hit a small snag with adding the new groups. The number of defined > >> > groups currently sits at 31 so I can only add one before hitting the > >> > >> I believe you have no more available. RTNLGRP_* has been defined from 0 > >> (RTNLGRP_NONE) to 31 (RTNLGRP_IPV6_MROUTE_R) which covers the u32 range. > >> > >> > limit defined by the 32 bit groups bitmask in socakddr_nl. I can use 1 > >> > group for both v4 and v6 notifications which seems like the sensible > >> > options since the AF is carried separately, but it breaks the precedent > >> > where there are separate IPV4 and IPV6 groups for IFADDR. > >> > > >> > I have the combined group patches ready and can share them if that's > >> > the preference. > >> > > >> > Has there been any previous discussion about extending the number of > >> > availabel groups? > >> > > >> > >> I have not tried it, but from a prior code review I believe you have you > >> use setsockopt to add groups > 31. > > > > I can certainly join the new groups using setsockopt and > > NETLINK_ADD_MEMBERSHIP. > > I can't see any examples of extending the defined group list within the > > kernel so I assume I just add to the RTNLGRP enum list with a suitable > > comment to indicate that later groups must be joined with the mechanism > > above or am I missing some other way of dynamically adding groups? > > > > With a quick look, there are other subsystem specific groups: > xfrm_nlgroups, nfnetlink_groups ...which i see apps registering using > NETLINK_ADD_MEMBERSHIP. >
scratch that. These groups are for different netlink protocols and the limit on netlink groups per protocol seems to be 32. We seem to have hit the max on groups for NETLINK_ROUTE protocol. we will have to rework the group handling to make room for more groups. We do need room for more groups in the future and not just for this patchset. > seems like an overkill to add something like this for your case. > > yet another option to consider: > use family: RTNL_FAMILY_IPMR/ RTNL_FAMILY_IP6MR with RTM_GETADDR/DELADDR > and use the existing groups: RTNLGRP_IPV4_IFADDR / RTNLGRP_IPV6_IFADDR > > (pls check if this will break any existing users) > > precedence is ipmr fib rules.
