On Mon, 2018-09-03 at 16:12 -0700, Roopa Prabhu wrote: > On Sun, Sep 2, 2018 at 4:18 AM, Patrick Ruddy > <pru...@vyatta.att-mail.com> wrote: > > Hi Roopa > > > > inline > > > > thx > > > > -pr > > > > On Fri, 2018-08-31 at 09:29 -0700, Roopa Prabhu wrote: > > > On Fri, Aug 31, 2018 at 4:20 AM, Patrick Ruddy > > > <pru...@vyatta.att-mail.com> wrote: > > > > Some userspace applications need to know about IGMP joins from the > > > > kernel > > > > for 2 reasons > > > > 1. To allow the programming of multicast MAC filters in hardware > > > > 2. To form a multicast FORUS list for non link-local multicast > > > > groups to be sent to the kernel and from there to the interested > > > > party. > > > > (1) can be fulfilled but simply sending the hardware multicast MAC > > > > address to be programmed but (2) requires the L3 address to be sent > > > > since this cannot be constructed from the MAC address whereas the > > > > reverse translation is a standard library function. > > > > > > > > This commit provides addition and deletion of multicast addresses > > > > using the RTM_NEWADDR and RTM_DELADDR messages. It also provides > > > > the RTM_GETADDR extension to allow multicast join state to be read > > > > from the kernel. > > > > > > > > Signed-off-by: Patrick Ruddy <pru...@vyatta.att-mail.com> > > > > --- > > > > v2: fix kbuild warnings. > > > > > > I am still going through the series, but AFAICT, user-space caches > > > listening to > > > RTNLGRP_IPV4_IFADDR will now also get multicast addresses by default ? > > > > > > > Yes that's the crux of this change. It's unfortunate that I could not > > use IFA_MULTICAST to distinguish the SAFI. I suppose the other option > > would be to create a set of new NEW/DEL/GETMULTICAST messages but the > > partial code for RTM_GETMULTICAST in ipv6/mcast.c complicates that > > slightly. Happy to look at it if you think that would be be better. > > > > yeah, true. Thinking about this some more, you are adding an interface > for multicast entries learnt via igmp. > There is already a netlink channel for layer2 mc addresses via igmp. I > can't see why that cannot be used. > It is RTM_*MDB msgs. It is currently only available for the bridge. > But, I have a requirement for it to be > available via a vxlan dev...so, I am looking at making it available on > other devices. > > Can you check if RTM_*MDB msgs can be made to work for your case ?. > > The reason I think it should be possible is because this is similar to > bridge fdb entries. > The bridge fdb api (RTM_NEWNEIGH with AF_BRIDGE) is overloaded to > notify and dump netdev unicast addresses. > similarly I think the mdb api can be overloaded to notify and dump > netdev multicast addresses (statically added or learnt via igmp)
If I'm reading this correctly I think overloading this channel is possible. What you're suggesting is overloading the RTM_***MDB messages with AF_INET and AF_INET6 to carry the per-interfaces joined l3 multicast addresses. I've thrown together a quick test of this and it looks good. I can polish this up and resubmit if you're happy with the approach. FWIW isolating the multicast addresses this was seems safer and it's a smaller patchset. thx -pr
