On 09/28/2015 01:10 PM, Jason Gunthorpe wrote:
> On Mon, Sep 28, 2015 at 11:36:11AM -0400, Doug Ledford wrote:
>
>>> Also broadcast could cause a unecessary reception event on the NICs of
>>> machines that have no interest in this traffic.
>>
>> This is true. However, I'm trying to balance between several competing
>> issues. You also stated the revamped multicast code was adding latency
>> and dropped packets into the problem space. Sending over the broadcast
>> would help with latency. However, I have an alternative idea for that...
>
> I think your original idea of broadcast immediately and deferred
> optimal mlid lookup is the best *functionally* for every case - only
> when you enter the very edge world of caring about timing does it make
> any difference.
>
> Christoph's needs would probably be better served by giving some API
> to control the mlid cache (ie the neightbour table is already 99% of
> the way there). This would let some userspace component pre-load and
> fix all relevant data and undesired cache activity simply can't add
> jitter.
So, I've taken Christoph's patch, added two of my own (just changed the
comment and the #if statement so that we create groups on send-only
joins, and upped the max send-only backlog queue). We'll leave it at
that for 4.3 and try to address it more fully in 4.4.
--
Doug Ledford <dledford@xxxxxxxxxx>
GPG KeyID: 0E572FDD
Attachment:
signature.asc
Description: OpenPGP digital signature
