[openib-general] Re: ipoib: outstanding patches

[Michael S. Tsirkin]

Quoting r. Roland Dreier <rdreier at cisco.com>:
> Subject: [openib-general] Re: ipoib: outstanding patches
> 
> OK, I've started reviewing and applying these.
> 
> > ipoib_mc_list.patch
> 
> Applied, except spin_lock_bh() followed by spin_lock_irqsave() looked
> silly to me, so I changed it to spin_lock_irqsave() followed by spin_lock().

Thats fine too.

> > ipoib_flush_wq_1.patch
> > ipoib_flush_wq_2.patch
> 
> Still trying to decide if I like this approach.  Right now the ipoib
> workqueue is only doing multicast stuff, so it's easier for me to see
> what's going on.  These patches lose that so I'm trying to see if
> there's a better approach.
> 
> > ipoib_mcast_send.patch
> 
> Could we reuse the IPOIB_MCAST_RUN bit rather than adding a new bit?
> It seems that we could kill mcast_mutex and replace uses with
> priv->lock instead -- I don't see anything that sleeps inside mcast_mutex.

I'll need to think about this.

> > ipoib_all_neigh_issues_2.patch
> 
> Could we do this without a linear search through a list of neighbours?
> It seems this might become a scalability issue.

We could have a list of distinct ops pointers. Would that be better?

> > ipoib_multicast_leak.patch
> 
> Why does this change only handle send-only multicast groups?  Where
> are other multicast groups getting freed now that misses send-only groups?

Linux will clean other groups from mc_list so restart will kill them.

-- 
MST