On 09/15/2015 03:11 PM, Jason Gunthorpe wrote:
> On Tue, Sep 15, 2015 at 02:24:21PM -0400, Doug Ledford wrote:
> 
>> suggesting.  What's more, there are a few difficulties here in that I'm
>> fairly certain the core networking layer doesn't have the concept of a
>> send-only join, yet we would need it to have such.
> 
> The mcast list in the core is soley for listing subscriptions for
> inbound - ie receive.

Agreed.

> Abusing it for send-side is probably the wrong
> direction overall.

I wouldn't "abuse" it for such, I would suggest adding a proper notion
of send-only registrations.

> send-side addressing is always done with the neighbour table. If core
> net infrastructure is to be done here it makes alot more sense to
> store multicast IP's in the neighbour table and drive the join
> lifetime from that side.

Wherever the right place in the core would turn out to be, my point was
that we should talk to netdev about extending the core multicast code to
have a notion of IPoIB's need for send-only groups to be tracked, then
set a flag on the device that notes it needs tracked, and have the core
code track these subscriptions.  I would then modify the ipoib multicast
code so that the join/leave handler could deal with both sendonly and
full joins/leaves, scrap the auto send-only join in mcast_send, and
modify mcast_restart_task to be able to promote/demote joins based upon
changes in the core maintained join list.  That would be my preferred
way to handle this.

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD