InfiniBand/RDMA merge plans for 2.6.35

InfiniBand/RDMA merge plans for 2.6.35

[Roland Dreier]

Since 2.6.34 is here, it's probably a good time to talk about 2.6.35
merge plans.  All the pending things that I'm aware of are listed below.

Boilerplate:

If something isn't already in my tree and it isn't listed below, I
probably missed it or dropped it unintentionally.  Please remind me.

As usual, when submitting a patch:

 - Give a good changelog that explains what issue your patch
   addresses, how you address the issue, how serious the issue is, and
   any other information that would be useful to someone evaluating
   your patch now, or trying to understand it years from now.

 - Please make sure that you include a "Signed-off-by:" line, and put
   any extra junk that should not go into the final kernel log *after*
   the "---" line so that git tools strip it off automatically.  Make
   the subject line be appropriate for inclusion in the kernel log as
   well once the leading "[PATCH ...]" stuff is stripped off.  I waste a
   lot of time fixing patches by hand that could otherwise be spent
   doing something productive like watching youtube.

 - Run your patch through checkpatch.pl so I don't have to nag you to
   fix trivial issues (or spend time fixing them myself).

 - Check your patch over at least enough so I don't see a memory leak
   or deadlock as soon as I look at it.

 - Build your patch with sparse checking ("C=2 CF=-D__CHECK_ENDIAN__")
   and make sure it doesn't introduce new warnings.  (A big bonus in
   goodwill for sending patches that fix old warnings)

 - Test your patch on a kernel with things like slab debugging and
   lockdep turned on.

And while you're waiting for me to get to your patch, I sure wouldn't
mind if you read and commented on someone else's patch.  We currently
have a big imbalance between people who are writing patches (many) and
people who are reviewing patches (mostly me).  None of this means you
shouldn't remind me about pending patches, since I often lose track of
things and drop them accidentally.

Core:

 - Added support for masked atomic operations.

ULPs:

 - Merged a series of iSER failover improvements.

HW specific:

 - Added the iw_cxgb4 driver for new Chelsio T4 adapters.

 - Added masked atomic support to mlx4.

 - Removed use of the older PCI state API in favor of the new DMA
   state API.

 - A few other fixes here and there.

Here are a few topics that are not ready in time for the 2.6.35 window
and will need to wait for 2.6.36 at least:

 - XRC.  While I think we made significant progress here, the fact is
   that this is not ready to merge at the beginning of the merge
   window, and so we'll need to keep working on it and wait for the
   next merge window.

 - IBoE.  Same as XRC; we made significant progress (and I opened an
   iboe branch to track this), but we still do not have even the
   user-kernel interface really nailed down yet.

 - New QLogic qib driver.  If a new set of patches shows up soon, we
   can probably sneak this in, since it is essentially a new hardware
   driver that affects little else.  However the sheer size of the
   driver means we need to get this in early in the release cycle.

Here all the patches I already have in my for-next branch:

Chien Tung (1):
      RDMA/nes: Make nesadapter->phy_lock usage consistent

Dan Carpenter (1):
      IB/iser: Fix error flow in iser_create_ib_conn_res()

FUJITA Tomonori (3):
      RDMA/cxgb3: Use the dma state API instead of pci equivalents
      RDMA/amso1100: Use the dma state API instead of pci equivalents
      IB/mthca: Use the dma state API instead of pci equivalents

Julia Lawall (1):
      IB/core: Use kmemdup() instead of kmalloc()+memcpy()

Or Gerlitz (4):
      IPoIB: Allow disabling/enabling TSO on the fly through ethtool
      IB/iser: Add asynchronous event handler
      IB/iser: Remove buggy back-pointer setting
      IB/iser: Enhance disconnection logic for multi-pathing

Roland Dreier (4):
      IB: Explicitly rule out llseek to avoid BKL in default_llseek()
      RDMA/nes: Make unnecessarily global functions static
      RDMA/cxgb3: Shrink .text with compile-time init of handlers arrays
      MAINTAINERS: Add cxgb4 and iw_cxgb4 entries

Steve Wise (2):
      RDMA/cxgb3: Don't free skbs on NET_XMIT_* indications from LLD
      RDMA/cxgb4: Add driver for Chelsio T4 RNIC

Tetsuo Handa (1):
      RDMA/cma: Randomize local port allocation

Vladimir Sokolovsky (2):
      IB/core: Add support for masked atomic operations
      IB/mlx4: Add support for masked atomic operations
-- 
Roland Dreier <rolandd-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: InfiniBand/RDMA merge plans for 2.6.35

[Sean Hefty]

>Here are a few topics that are not ready in time for the 2.6.35 window
>and will need to wait for 2.6.36 at least:

I just wanted to make sure that this didn't get dropped off the radar for 2.6.36
review.  I have a set of patches to add support for AF_IB to the rdma_cm.  At
this point, all received feedback has been incorporated.  I won't repost the
entire patch set unless requested, but it's also available from:

	git://git.openfabrics.org/~shefty/rdma-dev.git af_ib

which has been updated to 2.6.34-rc7.  I tried to keep the patches small, to
make review a little easier.

Jason, you've been most involved in reviewing the patches so far.  Any chance I
can ask you to assist Roland with a more formal review?

 drivers/infiniband/core/addr.c           |   20 ++-
 drivers/infiniband/core/cma.c            |  469 ++++++++++++++++++++++--------
 drivers/infiniband/core/sa_query.c       |    6 +
 drivers/infiniband/core/ucma.c           |  356 ++++++++++++++++++++---
 drivers/infiniband/ulp/iser/iser_verbs.c |    2 +-
 include/linux/socket.h                   |    2 +
 include/rdma/ib.h                        |   89 ++++++
 include/rdma/ib_addr.h                   |    6 +-
 include/rdma/ib_sa.h                     |    6 +
 include/rdma/rdma_cm.h                   |   19 ++-
 include/rdma/rdma_user_cm.h              |   76 ++++-
 net/9p/trans_rdma.c                      |    3 +-
 net/rds/ib.c                             |    2 +-
 net/rds/ib_cm.c                          |    2 +-
 net/rds/iw.c                             |    2 +-
 net/rds/iw_cm.c                          |    2 +-
 net/rds/rdma_transport.c                 |    3 +-
 net/sunrpc/xprtrdma/svc_rdma_transport.c |    3 +-
 net/sunrpc/xprtrdma/verbs.c              |    2 +-
 19 files changed, 877 insertions(+), 193 deletions(-)

- Sean

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: InfiniBand/RDMA merge plans for 2.6.35

[Roland Dreier]

 > I just wanted to make sure that this didn't get dropped off the radar for 2.6.36
 > review.  I have a set of patches to add support for AF_IB to the rdma_cm.  At
 > this point, all received feedback has been incorporated.  I won't repost the
 > entire patch set unless requested, but it's also available from:
 > 
 > 	git://git.openfabrics.org/~shefty/rdma-dev.git af_ib

Sorry, yes, I forgot to add two more topics that, to be honest, I did
not even have a chance to start thinking about.  Namely this AF_IB stuff
and also the raw QP stuff for iWARP/datagram acceleration.  Again,
hopefully for 2.6.36.

 - R.
-- 
Roland Dreier <rolandd-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: InfiniBand/RDMA merge plans for 2.6.35

[Jason Gunthorpe]

On Mon, May 17, 2010 at 12:58:59PM -0700, Sean Hefty wrote:
> which has been updated to 2.6.34-rc7.  I tried to keep the patches small, to
> make review a little easier.
> 
> Jason, you've been most involved in reviewing the patches so far.
> Any chance I can ask you to assist Roland with a more formal review?

Sure, as time permits.. :)

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: InfiniBand/RDMA merge plans for 2.6.35

[Andy Grover]

On 05/17/2010 09:36 AM, Roland Dreier wrote:
> Since 2.6.34 is here, it's probably a good time to talk about 2.6.35
> merge plans.  All the pending things that I'm aware of are listed below.
>
> Boilerplate:
>
> If something isn't already in my tree and it isn't listed below, I
> probably missed it or dropped it unintentionally.  Please remind me.

Hi Roland,

Please also pick up the 3-patch set "Least attached vector support" from 
Yevgeny on 2010-5-13? RDS changes depend on these.

Thanks -- Regards -- Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: InfiniBand/RDMA merge plans for 2.6.35

[Roland Dreier]

 > Please also pick up the 3-patch set "Least attached vector support"
 > from Yevgeny on 2010-5-13? RDS changes depend on these.

It's now post -rc2, so these obviously wait for 2.6.36 at best.

However, I haven't replied to these patches in detail but in general I
don't like this approach of "pick a random vector" since it is
non-deterministic and not likely to end up with an optimal result.

 - R.
-- 
Roland Dreier <rolandd-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: InfiniBand/RDMA merge plans for 2.6.35

[Andy Grover]

On 06/09/2010 11:08 AM, Roland Dreier wrote:
>   >  Please also pick up the 3-patch set "Least attached vector support"
>   >  from Yevgeny on 2010-5-13? RDS changes depend on these.
>
> It's now post -rc2, so these obviously wait for 2.6.36 at best.
>
> However, I haven't replied to these patches in detail but in general I
> don't like this approach of "pick a random vector" since it is
> non-deterministic and not likely to end up with an optimal result.

What is the optimal way to do this, if it isn't to spread CQs evenly 
across all available vectors? (least attached vector != random.)

I guess we'll just round-robin modulo caps.num_comp_vectors for now, but 
I do think this should be up to the hca, not the ulp, since the ULP has 
no visibility into other ulp's usage of vectors.

Regards -- Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: InfiniBand/RDMA merge plans for 2.6.35

[Roland Dreier]

 > > However, I haven't replied to these patches in detail but in general I
 > > don't like this approach of "pick a random vector" since it is
 > > non-deterministic and not likely to end up with an optimal result.

 > What is the optimal way to do this, if it isn't to spread CQs evenly
 > across all available vectors? (least attached vector != random.)

Since there is no way to know whether a given vector has a bunch of CQs
that generate very few events or maybe a single CQ that generates a
heavy load of events, the number of attached CQs is really pretty
useless as a basis to decide.  I think it's much better to try and
attach your CQ to a vector that is directed at the CPU where you want to
process the work.

 - R.
-- 
Roland Dreier <rolandd-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html