[Openib-windows] RE: IPoIB multicast support

[Yossi Leybovich]

> -----Original Message-----
> From: Fab Tillier [mailto:ftillier at silverstorm.com] 
> Sent: Thursday, November 10, 2005 3:03 AM
> To: 'Yossi Leybovich'
> Cc: openib-windows at openib.org
> Subject: RE: IPoIB multicast support
> 
> 
> > 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.
> 
What about this way :
In Send create the entpnt and **update its Mac** but give it state of
not valid (same state like endpnt that waits for path_rec )
This field will become valid when the join request is finished.
When NDIS try to create the MC group before creating the entpndt check
if there is endpnt with this Mac in the list.
If yes use this endpnt for the MC group check the flag and issue join
with full membership
The MC group will be in the list only if NDIS ask for it.


> 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
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 3720 bytes
Desc: not available
URL: <http://lists.openfabrics.org/pipermail/ofw/attachments/20051110/ee140394/attachment.bin>