On Tue, 15 Sep 2015, Doug Ledford wrote: > > I actually think this is a step in the right direction, but I think we > are talking about a layering violation doing it the way you are > suggesting. What's more, there are a few difficulties here in that I'm
The function is used in various lower layer processing functions throughout the network stack. As long as we still have a task context and a socket accessible this should be fine. > fairly certain the core networking layer doesn't have the concept of a > send-only join, yet we would need it to have such. If we had three apps The networking layer supports a setsockopt that can set IP_MULTICAST_LOOP behavior. The the API is there to properly control this from user space and thus its possible to join sendonly from user space. Actually we would need that for the proper implementaiton of sendonly joins at the fabric level I would think. I can work on making this work properly with the IP stack. > do send only sends, we would need to track all three of those sockets as > being send only socket joins, and then if someone did a full join, we > would need to automatically upgrade the join, and then if that app with > the full join left, we would need to gracefully downgrade to send only > again. So, I think it would take work at the core level to get this > right, but I think that's probably the right place to do the work. Well the IP stack already has to deal with this. See mc_loop option in the socket field as well as the sk_mc_loop() function in the network stack. > -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
