On 09/28/2015 11:51 AM, Christoph Lameter wrote:
> 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, I was referring to using this on top of your patch and my other two
patches, which change the ipoib driver to create sendonly groups and
then expire them when the neighbor expires.
> No host in the fabric could then be
> listening the only listeners possible are outside the fabric.
>
--
Doug Ledford <dledford@xxxxxxxxxx>
GPG KeyID: 0E572FDD
Attachment:
signature.asc
Description: OpenPGP digital signature
