[Openib-windows] RE: IPoIB multicast support

[Fab Tillier]

> From: Yossi Leybovich [mailto:sleybo at mellanox.co.il]
> Sent: Tuesday, November 08, 2005 10:20 AM
> 
> My patch check if the MAC is multicast mac and then if the lookup failed
> its
> issue join request to the SA and return with STATUS_PENDING
> (I still need to check if the send side need to join the Mcgroup or just
> query for the LID and use it in the endpnt AV)
> 
> In the mcast_cb I call send_resume to complete the send request.

The patch doesn't handle the case where NDIS programs the multicast group after
it has sent a packet to it.  What happens is that during the send, IPoIB will
join the group and add it to its endpoint list.  When NDIS programs the
multicast group at a later time, the code expects that no matching endpoint
exists, and will create a new endpoint.

I'm trying to come up with a way to handle this, and it's not quite as simple as
I was hoping - it needs to handle the case where NDIS programs the multicast
group while a join is in progress but not complete (thus no matching endpoint).

There are two ways I can think of to solve this.  The first is to not track the
endpoint in the port's endpoint map.  We know when the multicast group creation
completes the associated packet is at the head of the pending send list.  We can
create the endpoint without adding it to the map, format the send (which
references the endpoint), and then initiate destruction of the endpoint before
we send.  When the send completes and dereferences the endpoint, destruction
will proceed.  This is very inefficient since every send to that multicast group
will result in a MC join/leave operation, not to mention potentially leaving the
group after a subsequent send requests to join it.

Another way is to pretend NDIS programmed that multicast group, so that
subsequent programming of the MC group by NDIS will effectively be a no-op.  The
down side to this is that if NDIS programs a new MC list that doesn't contain
this MAC then IPoIB will leave that MC group, potentially while a packet is in
flight.  This results in the MC forwarding tables potentially being updated
before the packet has finished going through the fabric.

Anyhow, I haven't settled on which way to go, and would like to find a better
solution than either of the above.  I think what we'll have to do is track
multicast endpoints created in the send path separately from those created
through NDIS programming the multicast list.  I'd appreciate any thoughts you
have on this.

Thanks,

- Fab