headers
Joachim Fenkes | 1 Sep 2009 13:55
Picon
Favicon

[PATCH] IB/ehca: Fix CQE flags reporting

Was reporting CQE flags in the wrong bit positions, causing consumers to
miss incoming immediate data.

Signed-off-by: Joachim Fenkes <fenkes@...>
---

Please review and queue for 2.6.32 if you think it's okay. Thanks!
  Joachim

 drivers/infiniband/hw/ehca/ehca_reqs.c |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/drivers/infiniband/hw/ehca/ehca_reqs.c b/drivers/infiniband/hw/ehca/ehca_reqs.c
index 5a3d96f..8fd88cd 100644
--- a/drivers/infiniband/hw/ehca/ehca_reqs.c
+++ b/drivers/infiniband/hw/ehca/ehca_reqs.c
 <at>  <at>  -786,7 +786,11  <at>  <at>  repoll:
 	wc->slid = cqe->rlid;
 	wc->dlid_path_bits = cqe->dlid;
 	wc->src_qp = cqe->remote_qp_number;
-	wc->wc_flags = cqe->w_completion_flags;
+	/*
+	 * HW has "Immed data present" and "GRH present" in bits 6 and 5.
+	 * SW defines those in bits 1 and 0, so we can just shift and mask.
+	 */
+	wc->wc_flags = (cqe->w_completion_flags >> 5) & 3;
 	wc->ex.imm_data = cpu_to_be32(cqe->immediate_data);
 	wc->sl = cqe->service_level;

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Roland Dreier | 1 Sep 2009 21:55
Picon
Favicon

Re: [PATCH] IB/ehca: Fix CQE flags reporting

applied, thanks
Permalink | Reply | 0 comments |
headers
Tung, Chien Tin | 2 Sep 2009 00:56
Picon
Favicon

[GIT PULL OFED 1.5] RDMA/nes: updates for beta

Vlad,

Please pull from:

ssh://vlad@.../home/ctung/scm/ofed-1.5.git ofed_kernel_1_5

to pickup commit dac8ba1d1528df477ebe0808f7900ee5b062169d

I've added 11 patches that's been accepted by Roland.

        RDMA/nes: Update refcnt during disconnect
        RDMA/nes: Allocate work item for disconnect event handling
        RDMA/nes: Change memory allocation for cqp request to GFP_ATOMIC
        RDMA/nes: Clean out CQ completions when QP is destroyed
        RDMA/nes: Add CQ error handling
        RDMA/nes: Implement Terminate Packet
        RDMA/nes: Use flush mechanism to set status for wqe in error
        RDMA/nes: Make poll_cq return correct number of wqes during flush
        RDMA/nes: Use the flush code to fill in cqe error
        RDMA/nes: Rework the disconn routine for terminate and flushing
        RDMA/nes: Map MTU to IB_MTU_* and correctly report link state

Thanks,

Chien

--
Chien Tung | chien.tin.tung@...
Permalink | Reply | 1 comment |
headers
Vladimir Sokolovsky | 2 Sep 2009 10:09
Picon

Re: [GIT PULL OFED 1.5] RDMA/nes: updates for beta

Tung, Chien Tin wrote:
> Vlad,
>
> Please pull from:
>
> ssh://vlad@.../home/ctung/scm/ofed-1.5.git ofed_kernel_1_5
>
> to pickup commit dac8ba1d1528df477ebe0808f7900ee5b062169d
>
> I've added 11 patches that's been accepted by Roland.
>
>         RDMA/nes: Update refcnt during disconnect
>         RDMA/nes: Allocate work item for disconnect event handling
>         RDMA/nes: Change memory allocation for cqp request to GFP_ATOMIC
>         RDMA/nes: Clean out CQ completions when QP is destroyed
>         RDMA/nes: Add CQ error handling
>         RDMA/nes: Implement Terminate Packet
>         RDMA/nes: Use flush mechanism to set status for wqe in error
>         RDMA/nes: Make poll_cq return correct number of wqes during flush
>         RDMA/nes: Use the flush code to fill in cqe error
>         RDMA/nes: Rework the disconn routine for terminate and flushing
>         RDMA/nes: Map MTU to IB_MTU_* and correctly report link state
>
> Thanks,
>
> Chien
>
> --
> Chien Tung | chien.tin.tung@...
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Amir Vadai | 2 Sep 2009 15:39
Picon

Re: [PATCH] sdp: check if sdp device is actually present in sdp_remove_one

done

Amir Vadai
Software Eng.
Mellanox Technologies
mailto: amirv@...
Tel +972-3-6259539

On 08/30/2009 05:24 PM, Jack Morgenstein wrote:
> If sdp fails to initialize at driver startup for any reason,
> the device is still registered with the ib_core, but there will be
> no client data (i.e., ib_set_client_data() will not be called, and all
> kernel resources are de-allocated).
> 
> On removal, ib_get_client_data() will return NULL in this case -- and this
> must be tested for -- or we will get a kernel Oops for a NULL pointer
> dereference.
> 
> Signed-off-by: Jack Morgenstein <jackm@...>
> 
> ---
> Amir,
> Please take care of this.
> 
> Index: ofed_kernel-fixes/drivers/infiniband/ulp/sdp/sdp_main.c
> ===================================================================
> --- ofed_kernel-fixes.orig/drivers/infiniband/ulp/sdp/sdp_main.c	2009-08-30
16:56:54.000000000 +0300
> +++ ofed_kernel-fixes/drivers/infiniband/ulp/sdp/sdp_main.c	2009-08-30 16:58:08.000000000 +0300
>  <at>  <at>  -2595,6 +2595,8  <at>  <at>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Amir Vadai | 2 Sep 2009 15:39
Picon

Re: [PATCH] sdp: incorrect SDP_FMR_SIZE on 32-bit machines

done

Amir Vadai
Software Eng.
Mellanox Technologies
mailto: amirv@...
Tel +972-3-6259539

On 08/30/2009 05:16 PM, Jack Morgenstein wrote:
> On 32-bit machines, sizeof (u64 *) is 4 bytes (size of a ***pointer***).
> However, the max SDP FMR pool size should be PAGE_SIZE / sizeof(an mtt entry) --
> and mtt entries are u64's (or __be64's).
> 
> This resulted in SDP requesting twice as many entries per pool on 32-bit machines
> as could fit on a single page -- with the result that the fmr pool allocation failed
> at driver startup.
> 
> Signed-off-by: Jack Morgenstein <jackm@...>
> 
> ---
> Amir,
> Please take care of this.
> 
> Index: ofed_kernel-fixes/drivers/infiniband/ulp/sdp/sdp.h
> ===================================================================
> --- ofed_kernel-fixes.orig/drivers/infiniband/ulp/sdp/sdp.h	2009-08-30 16:57:02.000000000 +0300
> +++ ofed_kernel-fixes/drivers/infiniband/ulp/sdp/sdp.h	2009-08-30 16:57:20.000000000 +0300
>  <at>  <at>  -29,7 +29,7  <at>  <at> 
>  #define SDP_TX_SIZE 0x40
>  #define SDP_RX_SIZE 0x40
(Continue reading)

Permalink | Reply | 0 comments |
headers
Venkataraman, Meenakshi | 2 Sep 2009 22:23
Picon
Favicon

OFED iwarp verbs implementation question

Hi,

 

I’m benchmarking servers connected by 10Gbps iWARP adaptors and I had a question regarding ordering and fencing operations in the iWARP OFED stack.

 

What spec do the ordering and fencing rules comply with?

 

I have the iWARP verbs 1.0 spec (from 2003, look here). Do the fencing operations conform the spec (look in section 8). As an aside, is there a newer version of the spec (this is what I found on the rdma consortium website)?

 

Thanks,

Meenakshi

 

Meenakshi Venkataraman

Intel Labs | CSR | SSAL | SSAL-IOA

(503) 712 8166

~ 42 ~

 

_______________________________________________
ewg mailing list
ewg@...
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Permalink | Reply | 2 comments |
headers
Steve Wise | 2 Sep 2009 23:30

Re: OFED iwarp verbs implementation question

Venkataraman, Meenakshi wrote:
>
> Hi,
>
> I’m benchmarking servers connected by 10Gbps iWARP adaptors and I had 
> a question regarding ordering and fencing operations in the iWARP OFED 
> stack.
>
> What spec do the ordering and fencing rules comply with?
>
> I have the iWARP verbs 1.0 spec (from 2003, look here 
> <http://www.rdmaconsortium.org/home/draft-hilland-iwarp-verbs-v1.0-RDMAC.pdf>). 
> Do the fencing operations conform the spec (look in section 8). As an 
> aside, is there a newer version of the spec (this is what I found on 
> the rdma consortium website)?
>
> Thanks,
>
> Meenakshi
>

The iWARP providers should be adhering to that specification. Chelsio's 
rnic does. Dunno about Intel/NES.

There is no newer version of that specification.

Steve.
//
Permalink | Reply | 1 comment |
headers
Steve Wise | 3 Sep 2009 04:03

[GIT PULL ofed-1.5] cxgb3 upstream bug fixes


Vlad,

Please pull from:

ssh://vlad@.../~swise/scm/ofed_kernel ofed_1_5

This pulls in all the latest upstream bug fixes for cxgb3 and adjusts 
the backport patches accordingly.

Thanks,

Steve.

-----
commit eea5c50fa98fb938b260f4646583b5ae619502cf
Author: Steve Wise <swise@...>
Date:   Wed Sep 2 16:10:36 2009 -0500

    RDMA/cxgb3: Pull in upstream bug fixes.

    Pull in all the latest cxgb3 bug files and adjust the backport patches
    accordingly.

    Signed-off-by: Steve Wise <swise@...>

 .../2.6.16_sles10_sp2/cxgb3_0010_napi.patch        |   51 ++--
 .../2.6.16_sles10_sp2/cxgb3_0100_remove_lro.patch  |   32 ++--
 .../backport/2.6.18-EL5.2/cxgb3_0010_napi.patch    |   51 ++--
 .../2.6.18-EL5.2/cxgb3_0100_remove_lro.patch       |   32 ++--
 .../backport/2.6.18-EL5.3/cxgb3_0010_napi.patch    |   51 ++--
 .../2.6.18-EL5.3/cxgb3_0100_remove_lro.patch       |   32 ++--
 .../backport/2.6.18/cxgb3_0010_napi.patch          |   51 ++--
 .../backport/2.6.18/cxgb3_0100_remove_lro.patch    |   32 ++--
 .../backport/2.6.19/cxgb3_0010_napi.patch          |   51 ++--
 .../backport/2.6.19/cxgb3_0100_remove_lro.patch    |   32 ++--
 .../backport/2.6.20/cxgb3_0010_napi.patch          |   51 ++--
 .../backport/2.6.20/cxgb3_0100_remove_lro.patch    |   32 ++--
 .../backport/2.6.21/cxgb3_0010_napi.patch          |   51 ++--
 .../backport/2.6.21/cxgb3_0100_remove_lro.patch    |   32 ++--
 .../backport/2.6.22/cxgb3_0010_napi.patch          |   51 ++--
 .../backport/2.6.22/cxgb3_0100_remove_lro.patch    |   32 ++--
 .../backport/2.6.23/cxgb3_0010_napi.patch          |   51 ++--
 .../backport/2.6.23/cxgb3_0100_remove_lro.patch    |   32 ++--
 .../backport/2.6.24/cxgb3_0100_remove_lro.patch    |   32 ++--
 .../backport/2.6.25/cxgb3_0100_remove_lro.patch    |   32 ++--
 .../backport/2.6.26/cxgb3_0100_remove_lro.patch    |   32 ++--
 .../backport/2.6.27/cxgb3_0100_remove_lro.patch    |   32 ++--
 .../2.6.27_sles11/cxgb3_0100_remove_lro.patch      |   32 ++--
 .../backport/2.6.28/cxgb3_0100_remove_lro.patch    |   32 ++--
 .../backport/2.6.9_U6/cxgb3_0010_napi.patch        |   51 ++--
 .../backport/2.6.9_U6/cxgb3_0100_remove_lro.patch  |   32 ++--
 .../backport/2.6.9_U7/cxgb3_0010_napi.patch        |   51 ++--
 .../backport/2.6.9_U7/cxgb3_0100_remove_lro.patch  |   32 ++--
 .../fixes/cxgb3_00520_removegfpnofailusage.patch   |  267 
++++++++++++++++++++
 .../fixes/cxgb3_00530_aq100xupdate.patch           |   33 +++
 .../fixes/cxgb3_00540_fixphypowerdown.patch        |   40 +++
 .../cxgb3_00542_fixt3cmaxpacketsizeaccess.patch    |   34 +++
 .../fixes/cxgb3_00545_ael2020update.patch          |  176 +++++++++++++
 kernel_patches/fixes/cxgb3_00560_fixmsstable.patch |   24 ++
 .../fixes/cxgb3_00565_fixmacindexmapping.patch     |   25 ++
 .../fixes/cxgb3_00570_drainmaxtxfifo.patch         |   83 ++++++
 .../cxgb3_00575_fixcrash_wrongnetdevqueue.patch    |   35 +++
 .../fixes/cxgb3_00585_fixgen2pcidefault.patch      |   43 ++++
 .../fixes/cxgb3_00590_fix2ports1Gregression.patch  |   37 +++
 39 files changed, 1344 insertions(+), 558 deletions(-)
Permalink | Reply | 1 comment |
headers
Vladimir Sokolovsky | 3 Sep 2009 08:44
Picon

Re: [GIT PULL ofed-1.5] cxgb3 upstream bug fixes

Steve Wise wrote:
>
> Vlad,
>
> Please pull from:
>
> ssh://vlad@.../~swise/scm/ofed_kernel ofed_1_5
>
> This pulls in all the latest upstream bug fixes for cxgb3 and adjusts 
> the backport patches accordingly.
>
> Thanks,
>
> Steve.
>

Done,

Regards,
Vladimir
Permalink | Reply | 0 comments |

Gmane