On Mon, 28 Sep 2015, Doug Ledford wrote: > > We would like to keep > > irrelevant traffic off the fabric as much as possible. An a reception > > event that requires traffic to be thrown out will cause jitter in the > > processing of inbound traffic that we also would like to avoid. > > That may not be optimal for your app, but we also need to try and > maintain proper emulation of typical IP/Ethernet behavior since this is > IPoIB after all. That's why the app isn't required to join the group > before sending, and also why it should be able to expect that we will > fall back to sending via broadcast if needed. Ok this needs to work with the existing ethernet gateways and verified to work with them. > However, the following algorithm might be suitable here: > > On first packet: > create mcast group > queue packet to group > schedule join > > On subsequent packets: > find mcast group > check mcast state > if already joined, send immediately > if joining, queue packet to mcast queue > if join is deferred, send via bcast Hmmm... If the multicast group does not exist in the SM then we could only bcast to all routers instead? No host in the fabric could then be listening the only listeners possible are outside the fabric. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
