Re: [PATCH v2 00/10] NFS/RDMA server for 3.20

2015-01-15 Thread J. Bruce Fields 
On Tue, Jan 13, 2015 at 11:31:16AM -0600, Steve Wise wrote:
 
 Reviewed-by: Steve Wise sw...@opengridcomputing.com

Thanks, applying for 3.20.

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

Re: [PATCH V3 FIX For-3.19 0/3] IB/ipoib: Fix multicast join flow

2015-01-15 Thread Doug Ledford 
On Thu, 2015-01-15 at 09:19 +, Erez Shitrit wrote:
 Hi Doug,
 
 Thank you for the quick response.
 
 Now I can see 2 issues, that I want to draw your attention to:
 
 1. if there is a mcg that the driver failed to join, the mc_task enters to 
 endless loop of re-queue, and the log will be full with the next messages:
 [682560.569826] ib0: no multicast record for 
 ff12:601b::::::0016, starting sendonly join
 [682560.580136] ib0: no multicast record for 
 ff12:601b::::::0016, starting sendonly join
 [682560.590364] ib0: no multicast record for 
 ff12:601b::::::0016, starting sendonly join
 [682560.600504] ib0: no multicast record for 
 ff12:601b::::::0016, starting sendonly join
 [682560.610627] ib0: no multicast record for 
 ff12:601b::::::0016, starting sendonly join
 [682560.620769] ib0: no multicast record for 
 ff12:601b::::::0016, starting sendonly join
 [682560.631082] ib0: no multicast record for 
 ff12:601b::::::0016, starting sendonly join
 [682560.640835] ib0: sendonly multicast join failed for 
 ff12:601b::::::0016, status -22
 [682560.651033] ib0: no multicast record for 
 ff12:601b::::::0016, starting sendonly join
 [682560.660758] ib0: sendonly multicast join failed for 
 ff12:601b::::::0016, status -22
 [682560.670923] ib0: no multicast record for 
 ff12:601b::::::0016, starting sendonly join
 [682560.680676] ib0: sendonly multicast join failed for 
 ff12:601b::::::0016, status -22
 [682560.690898] ib0: no multicast record for 
 ff12:601b::::::0016, starting sendonly join
 [682560.700630] ib0: sendonly multicast join failed for 
 ff12:601b::::::0016, status -22
 
 around 100 times a sec.

OK, this looks like the send only joins that fail are not setting a
fallback properly or something like that.  There is a separate bug that
I've isolated that I'm going to fix, then I we can see if that fix
effects things here, as it very well might.

 2. IPv6 still doesn't work for me, at the same case where it is not the first 
 mcg in the list.

Can you give me some sort of instructions on how to replicate your
testing?  Things are working for me here, but I don't have a complex
IPv6 setup and mine may be too simple to reproduce what you are seeing.

 Thanks, Erez
 
 -Original Message-
 From: Doug Ledford [mailto:dledf...@redhat.com] 
 Sent: Wednesday, January 14, 2015 9:53 PM
 To: linux-rdma@vger.kernel.org; rol...@kernel.org
 Cc: Amir Vadai; Eyal Perry; Erez Shitrit; Or Gerlitz; Doug Ledford
 Subject: [PATCH V3 FIX For-3.19 0/3] IB/ipoib: Fix multicast join flow
 
 This patch series fixes the multicast join behavior problems introduced by my 
 previous patchset.  In particular, the original code did not use the send 
 only join code from the multicast thread context, and so it did not need to 
 restart the multicast thread.  After my previous patchset, it does get called 
 from the thread context, and so the send only join completion areas need to 
 restart the join thread but they don't.  This patchset makes them do so.  It 
 then adds in some cleanups for restarting the thread, and fixes the fact that 
 one delayed join holds up the entire list of joins.
 
 v3: Resend because the last send didn't register in patchworks properly
 (because the subject-prefix was not on all of the emails, only the
 first) and because the Cc: list didn't not pass from cover letter
 to patches
 
 v2: Added two new patches, the first creates a helper to restart the
 multicast join thread and also adds using it in the two places where
 it should have been used but wasn't, the second allows the joins to
 proceed around a delayed join instead of stalling everything.
 
 v1: Addressed the usage of the IPOIB_MCAST_RUN flag
 
 Doug Ledford (3):
   IB/ipoib: Fix failed multicast joins/sends
   IB/ipoib: Add a helper to restart the multicast task
   IB/ipoib: make delayed tasks not hold up everything
 
  drivers/infiniband/ulp/ipoib/ipoib.h   |  1 +
  drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 94 
 ++
  2 files changed, 66 insertions(+), 29 deletions(-)
 
 --
 2.1.0
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-rdma in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
Doug Ledford dledf...@redhat.com
  GPG KeyID: 0E572FDD




signature.asc
Description: This is a digitally signed message part

Re: [PATCH V3 FIX For-3.19 0/3] IB/ipoib: Fix multicast join flow

2015-01-15 Thread Doug Ledford 
On Thu, 2015-01-15 at 22:08 +0200, Erez Shitrit wrote:
 On 1/15/2015 5:24 PM, Doug Ledford wrote:
  On Thu, 2015-01-15 at 09:19 +, Erez Shitrit wrote:
  Hi Doug,
 
  Thank you for the quick response.
 
  Now I can see 2 issues, that I want to draw your attention to:
 
  1. if there is a mcg that the driver failed to join, the mc_task enters to 
  endless loop of re-queue, and the log will be full with the next messages:
  [682560.569826] ib0: no multicast record for 
  ff12:601b::::::0016, starting sendonly join
  [682560.580136] ib0: no multicast record for 
  ff12:601b::::::0016, starting sendonly join
  [682560.590364] ib0: no multicast record for 
  ff12:601b::::::0016, starting sendonly join
  [682560.600504] ib0: no multicast record for 
  ff12:601b::::::0016, starting sendonly join
  [682560.610627] ib0: no multicast record for 
  ff12:601b::::::0016, starting sendonly join
  [682560.620769] ib0: no multicast record for 
  ff12:601b::::::0016, starting sendonly join
  [682560.631082] ib0: no multicast record for 
  ff12:601b::::::0016, starting sendonly join
  [682560.640835] ib0: sendonly multicast join failed for 
  ff12:601b::::::0016, status -22
  [682560.651033] ib0: no multicast record for 
  ff12:601b::::::0016, starting sendonly join
  [682560.660758] ib0: sendonly multicast join failed for 
  ff12:601b::::::0016, status -22
  [682560.670923] ib0: no multicast record for 
  ff12:601b::::::0016, starting sendonly join
  [682560.680676] ib0: sendonly multicast join failed for 
  ff12:601b::::::0016, status -22
  [682560.690898] ib0: no multicast record for 
  ff12:601b::::::0016, starting sendonly join
  [682560.700630] ib0: sendonly multicast join failed for 
  ff12:601b::::::0016, status -22
 
  around 100 times a sec.
  OK, this looks like the send only joins that fail are not setting a
  fallback properly or something like that.  There is a separate bug that
  I've isolated that I'm going to fix, then I we can see if that fix
  effects things here, as it very well might.
 
  2. IPv6 still doesn't work for me, at the same case where it is not the 
  first mcg in the list.
  Can you give me some sort of instructions on how to replicate your
  testing?  Things are working for me here, but I don't have a complex
  IPv6 setup and mine may be too simple to reproduce what you are seeing.
 I don't have a complex setup, i have 2 devices, and i do a regular ping6 
 from device with the full series in it, to some other device. nothing 
 special, the only thing i can say that in the list there is one sendonly 
 mcg (
 
 ff12:601b::::::0016) that is at the first place in the 
 list.
 anyway, i think it connected to the first issue,because it at some endless 
 loop with the first mcg, it doesn't have the chance to handle the other mcg's.

OK, well, I have this all working here.  However, there is still one
lingering issue (not reported on this thread yet) that needs addressed,
so I don't yet consider the patchset complete.  But, I'll post it as it
stands so far for you to try your tests again.

The outstanding issue is that it is possible for ipoib_mcast_flush_dev
to race with ipoib_mcast_join and cause ipoib_mcast_join to oops.  It's
rare, I've only seen it once, but I was afraid that it was possible by
looking at the code, and now I have confirmation that it is indeed
possible.  So, it needs to be fixed.

 
  Thanks, Erez
 
  -Original Message-
  From: Doug Ledford [mailto:dledf...@redhat.com]
  Sent: Wednesday, January 14, 2015 9:53 PM
  To: linux-rdma@vger.kernel.org; rol...@kernel.org
  Cc: Amir Vadai; Eyal Perry; Erez Shitrit; Or Gerlitz; Doug Ledford
  Subject: [PATCH V3 FIX For-3.19 0/3] IB/ipoib: Fix multicast join flow
 
  This patch series fixes the multicast join behavior problems introduced by 
  my previous patchset.  In particular, the original code did not use the 
  send only join code from the multicast thread context, and so it did not 
  need to restart the multicast thread.  After my previous patchset, it does 
  get called from the thread context, and so the send only join completion 
  areas need to restart the join thread but they don't.  This patchset makes 
  them do so.  It then adds in some cleanups for restarting the thread, and 
  fixes the fact that one delayed join holds up the entire list of joins.
 
  v3: Resend because the last send didn't register in patchworks properly
   (because the subject-prefix was not on all of the emails, only the
   first) and because the Cc: list didn't not pass from cover letter
   to patches
 
  v2: Added two new patches, the first creates a helper to restart the
   multicast join thread and also adds using it in the

[PATCH FIX For-3.19 v3 5/6] IB/ipoib: don't restart our thread on ENETRESET

2015-01-15 Thread Doug Ledford 
Make the send only join completion handler behave like the normal join
completion handler in that we should restart the multicast join thread
whenever our join completes with either an error or success, but don't
restart the thread if we got a net reset event, let ipoib_event queue
up a device flush, which will then call ipoib_mcast_dev_flush to remove
all of the current mcast entries, and ipoib_mcase_restart_task to check
out current mcast entry list against the netdev list of mcast entries
we are supposed to have and requeue the ones we need to get back.

Signed-off-by: Doug Ledford dledf...@redhat.com
---
 drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c 
b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
index e81ed117c30..34727254339 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
@@ -336,17 +336,18 @@ ipoib_mcast_sendonly_join_complete(int status,
dev_kfree_skb_any(skb_dequeue(mcast-pkt_queue));
}
netif_tx_unlock_bh(dev);
+   __ipoib_mcast_continue_join_thread(priv, mcast, 1);
} else {
/* Join completed, so reset any backoff parameters */
mcast-backoff = 1;
mcast-delay_until = jiffies;
+   __ipoib_mcast_continue_join_thread(priv, NULL, 0);
}
 out:
clear_bit(IPOIB_MCAST_FLAG_BUSY, mcast-flags);
if (status)
mcast-mc = NULL;
complete(mcast-done);
-   __ipoib_mcast_continue_join_thread(priv, NULL, 0);
mutex_unlock(mcast_mutex);
return status;
 }
-- 
2.1.0

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

Re: [PATCH V3 FIX For-3.19 0/3] IB/ipoib: Fix multicast join flow

2015-01-15 Thread Erez Shitrit 

On 1/15/2015 5:24 PM, Doug Ledford wrote:

On Thu, 2015-01-15 at 09:19 +, Erez Shitrit wrote:

Hi Doug,

Thank you for the quick response.

Now I can see 2 issues, that I want to draw your attention to:

1. if there is a mcg that the driver failed to join, the mc_task enters to 
endless loop of re-queue, and the log will be full with the next messages:
[682560.569826] ib0: no multicast record for 
ff12:601b::::::0016, starting sendonly join
[682560.580136] ib0: no multicast record for 
ff12:601b::::::0016, starting sendonly join
[682560.590364] ib0: no multicast record for 
ff12:601b::::::0016, starting sendonly join
[682560.600504] ib0: no multicast record for 
ff12:601b::::::0016, starting sendonly join
[682560.610627] ib0: no multicast record for 
ff12:601b::::::0016, starting sendonly join
[682560.620769] ib0: no multicast record for 
ff12:601b::::::0016, starting sendonly join
[682560.631082] ib0: no multicast record for 
ff12:601b::::::0016, starting sendonly join
[682560.640835] ib0: sendonly multicast join failed for 
ff12:601b::::::0016, status -22
[682560.651033] ib0: no multicast record for 
ff12:601b::::::0016, starting sendonly join
[682560.660758] ib0: sendonly multicast join failed for 
ff12:601b::::::0016, status -22
[682560.670923] ib0: no multicast record for 
ff12:601b::::::0016, starting sendonly join
[682560.680676] ib0: sendonly multicast join failed for 
ff12:601b::::::0016, status -22
[682560.690898] ib0: no multicast record for 
ff12:601b::::::0016, starting sendonly join
[682560.700630] ib0: sendonly multicast join failed for 
ff12:601b::::::0016, status -22

around 100 times a sec.

OK, this looks like the send only joins that fail are not setting a
fallback properly or something like that.  There is a separate bug that
I've isolated that I'm going to fix, then I we can see if that fix
effects things here, as it very well might.


2. IPv6 still doesn't work for me, at the same case where it is not the first 
mcg in the list.

Can you give me some sort of instructions on how to replicate your
testing?  Things are working for me here, but I don't have a complex
IPv6 setup and mine may be too simple to reproduce what you are seeing.
I don't have a complex setup, i have 2 devices, and i do a regular ping6 
from device with the full series in it, to some other device. nothing 
special, the only thing i can say that in the list there is one sendonly 
mcg (


ff12:601b::::::0016) that is at the first place in the list.
anyway, i think it connected to the first issue,because it at some endless loop 
with the first mcg, it doesn't have the chance to handle the other mcg's.




Thanks, Erez

-Original Message-
From: Doug Ledford [mailto:dledf...@redhat.com]
Sent: Wednesday, January 14, 2015 9:53 PM
To: linux-rdma@vger.kernel.org; rol...@kernel.org
Cc: Amir Vadai; Eyal Perry; Erez Shitrit; Or Gerlitz; Doug Ledford
Subject: [PATCH V3 FIX For-3.19 0/3] IB/ipoib: Fix multicast join flow

This patch series fixes the multicast join behavior problems introduced by my 
previous patchset.  In particular, the original code did not use the send only 
join code from the multicast thread context, and so it did not need to restart 
the multicast thread.  After my previous patchset, it does get called from the 
thread context, and so the send only join completion areas need to restart the 
join thread but they don't.  This patchset makes them do so.  It then adds in 
some cleanups for restarting the thread, and fixes the fact that one delayed 
join holds up the entire list of joins.

v3: Resend because the last send didn't register in patchworks properly
 (because the subject-prefix was not on all of the emails, only the
 first) and because the Cc: list didn't not pass from cover letter
 to patches

v2: Added two new patches, the first creates a helper to restart the
 multicast join thread and also adds using it in the two places where
 it should have been used but wasn't, the second allows the joins to
 proceed around a delayed join instead of stalling everything.

v1: Addressed the usage of the IPOIB_MCAST_RUN flag

Doug Ledford (3):
   IB/ipoib: Fix failed multicast joins/sends
   IB/ipoib: Add a helper to restart the multicast task
   IB/ipoib: make delayed tasks not hold up everything

  drivers/infiniband/ulp/ipoib/ipoib.h   |  1 +
  drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 94 ++
  2 files changed, 66 insertions(+), 29 deletions(-)

--
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at

[PATCH FIX For-3.19 v3 4/6] IB/ipoib: Handle -ENETRESET properly in our callback

2015-01-15 Thread Doug Ledford 
When the core layer calls our callback with ENETRESET as the error, we
clear the status to 0 before returning indicating that we are going to
handle the error ourselves.  This causes the core layer to not free the
mcast-mc structure, but we are releasing our reference to it by
clearing mcast-mc.  So, preserve our reference to the multicast
structure so when we next run ipoib_mcast_dev_flush, it will be able
to properly release the mcast-mc entry at the right time in the right
way.

Signed-off-by: Doug Ledford dledf...@redhat.com
---
 drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c 
b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
index 9291b2d569e..e81ed117c30 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
@@ -315,8 +315,10 @@ ipoib_mcast_sendonly_join_complete(int status,
mutex_lock(mcast_mutex);
 
/* We trap for port events ourselves. */
-   if (status == -ENETRESET)
+   if (status == -ENETRESET) {
+   status = 0;
goto out;
+   }
 
if (!status)
status = ipoib_mcast_join_finish(mcast, multicast-rec);
@@ -344,8 +346,6 @@ out:
if (status)
mcast-mc = NULL;
complete(mcast-done);
-   if (status == -ENETRESET)
-   status = 0;
__ipoib_mcast_continue_join_thread(priv, NULL, 0);
mutex_unlock(mcast_mutex);
return status;
@@ -462,8 +462,10 @@ static int ipoib_mcast_join_complete(int status,
mutex_lock(mcast_mutex);
 
/* We trap for port events ourselves. */
-   if (status == -ENETRESET)
+   if (status == -ENETRESET) {
+   status = 0;
goto out;
+   }
 
if (!status)
status = ipoib_mcast_join_finish(mcast, multicast-rec);
@@ -499,8 +501,6 @@ out:
if (status)
mcast-mc = NULL;
complete(mcast-done);
-   if (status == -ENETRESET)
-   status = 0;
spin_unlock_irq(priv-lock);
mutex_unlock(mcast_mutex);
 
-- 
2.1.0

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

[PATCH FIX For-3.19 v3 6/6] IB/ipoib: remove unneeded locks

2015-01-15 Thread Doug Ledford 
During the various work I've done on this, some extra locking has crept
in when things weren't working right.  This is one of those spots.
Remove the unneeded spinlocks.  The mutex is enough to protect against
what we need to protect against.

Signed-off-by: Doug Ledford dledf...@redhat.com
---
 drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c 
b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
index 34727254339..9df74f831e2 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
@@ -497,12 +497,10 @@ static int ipoib_mcast_join_complete(int status,
__ipoib_mcast_continue_join_thread(priv, mcast, 1);
}
 out:
-   spin_lock_irq(priv-lock);
clear_bit(IPOIB_MCAST_FLAG_BUSY, mcast-flags);
if (status)
mcast-mc = NULL;
complete(mcast-done);
-   spin_unlock_irq(priv-lock);
mutex_unlock(mcast_mutex);
 
return status;
-- 
2.1.0

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

RE: [PATCH 16/20] IB/mad: Add Intel Omni-Path Architecture defines

2015-01-15 Thread Weiny, Ira 
 
 On 1/12/2015 12:11 PM, ira.we...@intel.com wrote:
  From: Ira Weiny ira.we...@intel.com
 
  OPA_MIN_CLASS_VERSION -- OPA Class versions are  0x80
  OPA_SMP_CLASS_VERSION -- Defined at 0x80 OPA_MGMT_BASE_VERSION --
  Defined at 0x80
 
  Increase max management version to accommodate OPA
 
 Allocation of MAD base and class version numbers is owned by the IBTA.
 It doesn't seem appropriate to arbitrarily claim code points without proper
 approval.

OPA is its own architecture space.  While this space uses some of the same 
values as IB we are not claiming any IBTA values.  This is similar to how IB 
GIDs and IPv6 addresses look the same but are in separate addressing domains.

Ira

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

[PATCH for-next 2/2] iw_cxgb4: Cleanup register defines/MACROS defined in t4fw_ri_api.h

2015-01-15 Thread Hariprasad Shenai 
Cleanup all the MACROS that are defined in t4fw_ri_api.h and affected files

Signed-off-by: Hariprasad Shenai haripra...@chelsio.com
---
 drivers/infiniband/hw/cxgb4/cm.c  |   30 +-
 drivers/infiniband/hw/cxgb4/cq.c  |   22 +-
 drivers/infiniband/hw/cxgb4/device.c  |   12 +-
 drivers/infiniband/hw/cxgb4/ev.c  |   12 +-
 drivers/infiniband/hw/cxgb4/mem.c |   18 +-
 drivers/infiniband/hw/cxgb4/qp.c  |   60 ++--
 drivers/infiniband/hw/cxgb4/t4fw_ri_api.h |  812 ++--
 7 files changed, 483 insertions(+), 483 deletions(-)

diff --git a/drivers/infiniband/hw/cxgb4/cm.c b/drivers/infiniband/hw/cxgb4/cm.c
index 694e030..57176dd 100644
--- a/drivers/infiniband/hw/cxgb4/cm.c
+++ b/drivers/infiniband/hw/cxgb4/cm.c
@@ -674,7 +674,7 @@ static int send_connect(struct c4iw_ep *ep)
opt2 |= WND_SCALE_EN_F;
if (is_t5(ep-com.dev-rdev.lldi.adapter_type)) {
opt2 |= T5_OPT_2_VALID_F;
-   opt2 |= V_CONG_CNTRL(CONG_ALG_TAHOE);
+   opt2 |= CONG_CNTRL_V(CONG_ALG_TAHOE);
opt2 |= CONG_CNTRL_VALID; /* OPT_2_ISS for T5 */
}
t4_set_arp_err_handler(skb, ep, act_open_req_arp_failure);
@@ -1258,8 +1258,8 @@ static int update_rx_credits(struct c4iw_ep *ep, u32 
credits)
OPCODE_TID(req) = cpu_to_be32(MK_OPCODE_TID(CPL_RX_DATA_ACK,
ep-hwtid));
req-credit_dack = cpu_to_be32(credits | RX_FORCE_ACK_F |
-  F_RX_DACK_CHANGE |
-  V_RX_DACK_MODE(dack_mode));
+  RX_DACK_CHANGE_F |
+  RX_DACK_MODE_V(dack_mode));
set_wr_txq(skb, CPL_PRIORITY_ACK, ep-ctrlq_idx);
c4iw_ofld_send(ep-com.dev-rdev, skb);
return credits;
@@ -2205,15 +2205,15 @@ static void accept_cr(struct c4iw_ep *ep, struct 
sk_buff *skb,
const struct tcphdr *tcph;
u32 hlen = ntohl(req-hdr_len);
 
-   tcph = (const void *)(req + 1) + G_ETH_HDR_LEN(hlen) +
-   G_IP_HDR_LEN(hlen);
+   tcph = (const void *)(req + 1) + ETH_HDR_LEN_G(hlen) +
+   IP_HDR_LEN_G(hlen);
if (tcph-ece  tcph-cwr)
opt2 |= CCTRL_ECN_V(1);
}
if (is_t5(ep-com.dev-rdev.lldi.adapter_type)) {
u32 isn = (prandom_u32()  ~7UL) - 1;
opt2 |= T5_OPT_2_VALID_F;
-   opt2 |= V_CONG_CNTRL(CONG_ALG_TAHOE);
+   opt2 |= CONG_CNTRL_V(CONG_ALG_TAHOE);
opt2 |= CONG_CNTRL_VALID; /* OPT_2_ISS for T5 */
rpl5 = (void *)rpl;
memset(rpl5-iss, 0, roundup(sizeof(*rpl5)-sizeof(*rpl), 16));
@@ -2245,8 +2245,8 @@ static void get_4tuple(struct cpl_pass_accept_req *req, 
int *iptype,
   __u8 *local_ip, __u8 *peer_ip,
   __be16 *local_port, __be16 *peer_port)
 {
-   int eth_len = G_ETH_HDR_LEN(be32_to_cpu(req-hdr_len));
-   int ip_len = G_IP_HDR_LEN(be32_to_cpu(req-hdr_len));
+   int eth_len = ETH_HDR_LEN_G(be32_to_cpu(req-hdr_len));
+   int ip_len = IP_HDR_LEN_G(be32_to_cpu(req-hdr_len));
struct iphdr *ip = (struct iphdr *)((u8 *)(req + 1) + eth_len);
struct ipv6hdr *ip6 = (struct ipv6hdr *)((u8 *)(req + 1) + eth_len);
struct tcphdr *tcp = (struct tcphdr *)
@@ -3500,20 +3500,20 @@ static void build_cpl_pass_accept_req(struct sk_buff 
*skb, int stid , u8 tos)
 
req = (struct cpl_pass_accept_req *)__skb_push(skb, sizeof(*req));
memset(req, 0, sizeof(*req));
-   req-l2info = cpu_to_be16(V_SYN_INTF(intf) |
-V_SYN_MAC_IDX(RX_MACIDX_G(
+   req-l2info = cpu_to_be16(SYN_INTF_V(intf) |
+SYN_MAC_IDX_V(RX_MACIDX_G(
 (__force int) htonl(l2info))) |
-F_SYN_XACT_MATCH);
+SYN_XACT_MATCH_F);
eth_hdr_len = is_t4(dev-rdev.lldi.adapter_type) ?
RX_ETHHDR_LEN_G((__force int)htonl(l2info)) :
RX_T5_ETHHDR_LEN_G((__force int)htonl(l2info));
-   req-hdr_len = cpu_to_be32(V_SYN_RX_CHAN(RX_CHAN_G(
+   req-hdr_len = cpu_to_be32(SYN_RX_CHAN_V(RX_CHAN_G(
(__force int) htonl(l2info))) |
-  V_TCP_HDR_LEN(RX_TCPHDR_LEN_G(
+  TCP_HDR_LEN_V(RX_TCPHDR_LEN_G(
(__force int) htons(hdr_len))) |
-  V_IP_HDR_LEN(RX_IPHDR_LEN_G(
+  IP_HDR_LEN_V(RX_IPHDR_LEN_G(
(__force int) htons(hdr_len))) |
-  V_ETH_HDR_LEN(RX_ETHHDR_LEN_G(eth_hdr_len)));
+

[PATCH for-next 0/2] Refactor macros to conform to uniform standards

2015-01-15 Thread Hariprasad Shenai 
Hi,

This patch series cleansup macros/register defines, defined in t4.h and
t4fw_ri_api.h and all the affected files.

This patch series is created against net-next tree and includes patches on
iw_cxgb4 tree. Since the patches are dependent on previous cleanup patched we
would line to get this series merged through net-next tree.

We have included all the maintainers of respective drivers. Kindly review the
change and let us know in case of any review comments.

Thanks

Hariprasad Shenai (2):
  iw_cxgb4: Cleanup register defines/MACROS defined in t4.h
  iw_cxgb4: Cleanup register defines/MACROS defined in t4fw_ri_api.h

 drivers/infiniband/hw/cxgb4/cm.c  |   30 +-
 drivers/infiniband/hw/cxgb4/cq.c  |   60 ++--
 drivers/infiniband/hw/cxgb4/device.c  |   12 +-
 drivers/infiniband/hw/cxgb4/ev.c  |   12 +-
 drivers/infiniband/hw/cxgb4/mem.c |   18 +-
 drivers/infiniband/hw/cxgb4/qp.c  |   62 ++--
 drivers/infiniband/hw/cxgb4/t4.h  |   90 ++--
 drivers/infiniband/hw/cxgb4/t4fw_ri_api.h |  812 ++--
 8 files changed, 548 insertions(+), 548 deletions(-)

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

[PATCH for-next 1/2] iw_cxgb4: Cleanup register defines/MACROS defined in t4.h

2015-01-15 Thread Hariprasad Shenai 
Cleanup all the MACROS defined in t4.h and the affected files

Signed-off-by: Hariprasad Shenai haripra...@chelsio.com
---
 drivers/infiniband/hw/cxgb4/cq.c |   38 
 drivers/infiniband/hw/cxgb4/qp.c |2 +-
 drivers/infiniband/hw/cxgb4/t4.h |   90 +++---
 3 files changed, 65 insertions(+), 65 deletions(-)

diff --git a/drivers/infiniband/hw/cxgb4/cq.c b/drivers/infiniband/hw/cxgb4/cq.c
index e9fd3a0..39b0da3 100644
--- a/drivers/infiniband/hw/cxgb4/cq.c
+++ b/drivers/infiniband/hw/cxgb4/cq.c
@@ -182,12 +182,12 @@ static void insert_recv_cqe(struct t4_wq *wq, struct 
t4_cq *cq)
PDBG(%s wq %p cq %p sw_cidx %u sw_pidx %u\n, __func__,
 wq, cq, cq-sw_cidx, cq-sw_pidx);
memset(cqe, 0, sizeof(cqe));
-   cqe.header = cpu_to_be32(V_CQE_STATUS(T4_ERR_SWFLUSH) |
-V_CQE_OPCODE(FW_RI_SEND) |
-V_CQE_TYPE(0) |
-V_CQE_SWCQE(1) |
-V_CQE_QPID(wq-sq.qid));
-   cqe.bits_type_ts = cpu_to_be64(V_CQE_GENBIT((u64)cq-gen));
+   cqe.header = cpu_to_be32(CQE_STATUS_V(T4_ERR_SWFLUSH) |
+CQE_OPCODE_V(FW_RI_SEND) |
+CQE_TYPE_V(0) |
+CQE_SWCQE_V(1) |
+CQE_QPID_V(wq-sq.qid));
+   cqe.bits_type_ts = cpu_to_be64(CQE_GENBIT_V((u64)cq-gen));
cq-sw_queue[cq-sw_pidx] = cqe;
t4_swcq_produce(cq);
 }
@@ -215,13 +215,13 @@ static void insert_sq_cqe(struct t4_wq *wq, struct t4_cq 
*cq,
PDBG(%s wq %p cq %p sw_cidx %u sw_pidx %u\n, __func__,
 wq, cq, cq-sw_cidx, cq-sw_pidx);
memset(cqe, 0, sizeof(cqe));
-   cqe.header = cpu_to_be32(V_CQE_STATUS(T4_ERR_SWFLUSH) |
-V_CQE_OPCODE(swcqe-opcode) |
-V_CQE_TYPE(1) |
-V_CQE_SWCQE(1) |
-V_CQE_QPID(wq-sq.qid));
+   cqe.header = cpu_to_be32(CQE_STATUS_V(T4_ERR_SWFLUSH) |
+CQE_OPCODE_V(swcqe-opcode) |
+CQE_TYPE_V(1) |
+CQE_SWCQE_V(1) |
+CQE_QPID_V(wq-sq.qid));
CQE_WRID_SQ_IDX(cqe) = swcqe-idx;
-   cqe.bits_type_ts = cpu_to_be64(V_CQE_GENBIT((u64)cq-gen));
+   cqe.bits_type_ts = cpu_to_be64(CQE_GENBIT_V((u64)cq-gen));
cq-sw_queue[cq-sw_pidx] = cqe;
t4_swcq_produce(cq);
 }
@@ -284,7 +284,7 @@ static void flush_completed_wrs(struct t4_wq *wq, struct 
t4_cq *cq)
 */
PDBG(%s moving cqe into swcq sq idx %u cq idx %u\n,
__func__, cidx, cq-sw_pidx);
-   swsqe-cqe.header |= htonl(V_CQE_SWCQE(1));
+   swsqe-cqe.header |= htonl(CQE_SWCQE_V(1));
cq-sw_queue[cq-sw_pidx] = swsqe-cqe;
t4_swcq_produce(cq);
swsqe-flushed = 1;
@@ -301,10 +301,10 @@ static void create_read_req_cqe(struct t4_wq *wq, struct 
t4_cqe *hw_cqe,
 {
read_cqe-u.scqe.cidx = wq-sq.oldest_read-idx;
read_cqe-len = htonl(wq-sq.oldest_read-read_len);
-   read_cqe-header = htonl(V_CQE_QPID(CQE_QPID(hw_cqe)) |
-   V_CQE_SWCQE(SW_CQE(hw_cqe)) |
-   V_CQE_OPCODE(FW_RI_READ_REQ) |
-   V_CQE_TYPE(1));
+   read_cqe-header = htonl(CQE_QPID_V(CQE_QPID(hw_cqe)) |
+   CQE_SWCQE_V(SW_CQE(hw_cqe)) |
+   CQE_OPCODE_V(FW_RI_READ_REQ) |
+   CQE_TYPE_V(1));
read_cqe-bits_type_ts = hw_cqe-bits_type_ts;
 }
 
@@ -400,7 +400,7 @@ void c4iw_flush_hw_cq(struct c4iw_cq *chp)
} else {
swcqe = chp-cq.sw_queue[chp-cq.sw_pidx];
*swcqe = *hw_cqe;
-   swcqe-header |= cpu_to_be32(V_CQE_SWCQE(1));
+   swcqe-header |= cpu_to_be32(CQE_SWCQE_V(1));
t4_swcq_produce(chp-cq);
}
 next_cqe:
@@ -576,7 +576,7 @@ static int poll_cq(struct t4_wq *wq, struct t4_cq *cq, 
struct t4_cqe *cqe,
}
if (unlikely((CQE_WRID_MSN(hw_cqe) != (wq-rq.msn {
t4_set_wq_in_error(wq);
-   hw_cqe-header |= htonl(V_CQE_STATUS(T4_ERR_MSN));
+   hw_cqe-header |= htonl(CQE_STATUS_V(T4_ERR_MSN));
goto proc_cqe;
}
goto proc_cqe;
diff --git a/drivers/infiniband/hw/cxgb4/qp.c b/drivers/infiniband/hw/cxgb4/qp.c
index bb85d47..42238ed 100644
--- a/drivers/infiniband/hw/cxgb4/qp.c
+++ b/drivers/infiniband/hw/cxgb4/qp.c
@@ -1776,7 +1776,7 @@ struct ib_qp *c4iw_create_qp(struct ib_pd *pd, struct 
ib_qp_init_attr *attrs,

Re: [PATCH for-next 0/2] Refactor macros to conform to uniform standards

2015-01-15 Thread David Miller 
From: Hariprasad Shenai haripra...@chelsio.com
Date: Fri, 16 Jan 2015 09:24:46 +0530

 This patch series cleansup macros/register defines, defined in t4.h and
 t4fw_ri_api.h and all the affected files.
 
 This patch series is created against net-next tree and includes patches on
 iw_cxgb4 tree. Since the patches are dependent on previous cleanup patched we
 would line to get this series merged through net-next tree.
 
 We have included all the maintainers of respective drivers. Kindly review the
 change and let us know in case of any review comments.

Series applied, thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH V3 FIX For-3.19 0/3] IB/ipoib: Fix multicast join flow

2015-01-15 Thread Erez Shitrit 
Hi Doug,

Thank you for the quick response.

Now I can see 2 issues, that I want to draw your attention to:

1. if there is a mcg that the driver failed to join, the mc_task enters to 
endless loop of re-queue, and the log will be full with the next messages:
[682560.569826] ib0: no multicast record for 
ff12:601b::::::0016, starting sendonly join
[682560.580136] ib0: no multicast record for 
ff12:601b::::::0016, starting sendonly join
[682560.590364] ib0: no multicast record for 
ff12:601b::::::0016, starting sendonly join
[682560.600504] ib0: no multicast record for 
ff12:601b::::::0016, starting sendonly join
[682560.610627] ib0: no multicast record for 
ff12:601b::::::0016, starting sendonly join
[682560.620769] ib0: no multicast record for 
ff12:601b::::::0016, starting sendonly join
[682560.631082] ib0: no multicast record for 
ff12:601b::::::0016, starting sendonly join
[682560.640835] ib0: sendonly multicast join failed for 
ff12:601b::::::0016, status -22
[682560.651033] ib0: no multicast record for 
ff12:601b::::::0016, starting sendonly join
[682560.660758] ib0: sendonly multicast join failed for 
ff12:601b::::::0016, status -22
[682560.670923] ib0: no multicast record for 
ff12:601b::::::0016, starting sendonly join
[682560.680676] ib0: sendonly multicast join failed for 
ff12:601b::::::0016, status -22
[682560.690898] ib0: no multicast record for 
ff12:601b::::::0016, starting sendonly join
[682560.700630] ib0: sendonly multicast join failed for 
ff12:601b::::::0016, status -22

around 100 times a sec.

2. IPv6 still doesn't work for me, at the same case where it is not the first 
mcg in the list.

Thanks, Erez

-Original Message-
From: Doug Ledford [mailto:dledf...@redhat.com] 
Sent: Wednesday, January 14, 2015 9:53 PM
To: linux-rdma@vger.kernel.org; rol...@kernel.org
Cc: Amir Vadai; Eyal Perry; Erez Shitrit; Or Gerlitz; Doug Ledford
Subject: [PATCH V3 FIX For-3.19 0/3] IB/ipoib: Fix multicast join flow

This patch series fixes the multicast join behavior problems introduced by my 
previous patchset.  In particular, the original code did not use the send only 
join code from the multicast thread context, and so it did not need to restart 
the multicast thread.  After my previous patchset, it does get called from the 
thread context, and so the send only join completion areas need to restart the 
join thread but they don't.  This patchset makes them do so.  It then adds in 
some cleanups for restarting the thread, and fixes the fact that one delayed 
join holds up the entire list of joins.

v3: Resend because the last send didn't register in patchworks properly
(because the subject-prefix was not on all of the emails, only the
first) and because the Cc: list didn't not pass from cover letter
to patches

v2: Added two new patches, the first creates a helper to restart the
multicast join thread and also adds using it in the two places where
it should have been used but wasn't, the second allows the joins to
proceed around a delayed join instead of stalling everything.

v1: Addressed the usage of the IPOIB_MCAST_RUN flag

Doug Ledford (3):
  IB/ipoib: Fix failed multicast joins/sends
  IB/ipoib: Add a helper to restart the multicast task
  IB/ipoib: make delayed tasks not hold up everything

 drivers/infiniband/ulp/ipoib/ipoib.h   |  1 +
 drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 94 ++
 2 files changed, 66 insertions(+), 29 deletions(-)

--
2.1.0

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

Re: [PATCH 16/20] IB/mad: Add Intel Omni-Path Architecture defines

2015-01-15 Thread Hal Rosenstock 
On 1/12/2015 12:11 PM, ira.we...@intel.com wrote:
 From: Ira Weiny ira.we...@intel.com
 
 OPA_MIN_CLASS_VERSION -- OPA Class versions are  0x80
 OPA_SMP_CLASS_VERSION -- Defined at 0x80
 OPA_MGMT_BASE_VERSION -- Defined at 0x80
 
 Increase max management version to accommodate OPA

Allocation of MAD base and class version numbers is owned by the IBTA.
It doesn’t seem appropriate to arbitrarily claim code points without
proper approval.

-- Hal

 
 Signed-off-by: Ira Weiny ira.we...@intel.com
 ---
  drivers/infiniband/core/mad_priv.h |4 +++-
  include/rdma/ib_mad.h  |5 -
  2 files changed, 7 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/infiniband/core/mad_priv.h 
 b/drivers/infiniband/core/mad_priv.h
 index d71ddcc..a7041b0 100644
 --- a/drivers/infiniband/core/mad_priv.h
 +++ b/drivers/infiniband/core/mad_priv.h
 @@ -56,11 +56,13 @@
  
  /* Registration table sizes */
  #define MAX_MGMT_CLASS   80
 -#define MAX_MGMT_VERSION 8
 +#define MAX_MGMT_VERSION 0x83
  #define MAX_MGMT_OUI 8
  #define MAX_MGMT_VENDOR_RANGE2   (IB_MGMT_CLASS_VENDOR_RANGE2_END - \
   IB_MGMT_CLASS_VENDOR_RANGE2_START + 1)
  
 +#define OPA_MIN_CLASS_VERSION0x80
 +
  struct ib_mad_list_head {
   struct list_head list;
   struct ib_mad_queue *mad_queue;
 diff --git a/include/rdma/ib_mad.h b/include/rdma/ib_mad.h
 index 80e7cf4..8938f1e 100644
 --- a/include/rdma/ib_mad.h
 +++ b/include/rdma/ib_mad.h
 @@ -42,8 +42,11 @@
  #include rdma/ib_verbs.h
  #include uapi/rdma/ib_user_mad.h
  
 -/* Management base version */
 +/* Management base versions */
  #define IB_MGMT_BASE_VERSION 1
 +#define OPA_MGMT_BASE_VERSION0x80
 +
 +#define OPA_SMP_CLASS_VERSION0x80
  
  /* Management classes */
  #define IB_MGMT_CLASS_SUBN_LID_ROUTED0x01

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