[openib-general] [RFC] [PATCH 2/7] ib_multicast 2.6.20: add ib_multicast module to track join requests from the same port

[Michael S. Tsirkin]

OK, I'll talk about the ipoib change part here.

Quoting r. Sean Hefty <sean.hefty at intel.com>:
> >You might be right. But I wander whether we'll regret it later that
> >we switched to the slower generic thing when we already had a stable,
> >streamlined version.
> 
> To be direct, I'm not sure that I'd call the ipoib multicast either
> streamlined or stable.

Have to disagree on the stability count here - and this goes for all of IPoIB.
If you look at the git log you'll see that all fixes were one-liners or updates
due to API changes since probably 2.6.17. code in 2.6.17 has also been
backported and in field use since IBG2 too (around Jan 2006) and from what I
hear from field IPoIB is exceptionally stable there.

git log -p v2.6.17.. -- drivers/infiniband/ulp/ipoib/ipoib_multicast.c |
diffstat
 b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c |   20 +++++++---
 drivers/infiniband/ulp/ipoib/ipoib_multicast.c   |   46 +++++++++++------------
 2 files changed, 38 insertions(+), 28 deletions(-)


> A fix against it just recently went by,

Do you refer to the strict compliance in
d0df6d6d4539241179a1ef5394787825bf05bbce?
Come on.

> and given the
> complexity of its use of bit flags, thread, mutex, locks, and pointers to
> track state, the code is fairly difficult to follow, so I'm not surprised that
> it's taken a while to stabilize.

I think cleaning up code is always a good thing.
So, please do not get discouraged by my comments.
However, it would be nice to have the cleanup be
1. done in small steps so we can review each one
2. separate from the switch to the multicast module

Thanks,

-- 
MST