[ewg] RFCv2: SRC API

This is version 2 of the proposal, addressing comments from version 1. Changelog: - Use oflags to make API smaller - Clarify sharing semantics - Add documentation This is the API proposal for support of the SRC (scalable reliable connected) protocol extension in libibverbs. This adds APIs to: -

[ewg] Re: ofa_1_2_c_kernel 20070802-0201 daily build status

Quoting Hoang-Nam Nguyen [EMAIL PROTECTED]: Subject: Re: ofa_1_2_c_kernel 20070802-0201 daily build status Hello Michael and Vladimir! ehca backports for kernel.org kernels seem to be broken. 1. Does anyone care enough to fix them? If not we'll disable ehca in build for these

[ewg] [PATCH ofed-1.2.c] ehca: backport kmem_cache_zalloc() for 2.6.10/sles10/sles10_sp1

Hello Michael and Vladimir! This patch below adds a backport patch for ehca to the dirs 2.6.16, 2.6.16_sles10 and 2.6.16_sles10_sp1 underneath kernel_patches/backport of ofed-1.2.c source tree. Thanks! Nam backport kmem_cache_zalloc() to 2.6.10, 2.6.10_sles10 and 2.6.10_sles10_sp1

[ewg] Re: [PATCH ofed-1.2.c] ehca: backport kmem_cache_zalloc() for 2.6.10/sles10/sles10_sp1

Let's not do it this way. I think the right thing is to implement kmem_cache_zalloc by means of kmem_cache_allocand memset in kernel_addons. Quoting Hoang-Nam Nguyen [EMAIL PROTECTED]: Subject: [PATCH ofed-1.2.c] ehca: backport kmem_cache_zalloc() for 2.6.10/sles10/sles10_sp1 Hello Michael

[ewg] Re: RFCv2: SRC API

Only of the job among j2, j3, j4 on remote node n need to create a receiving qp2 for j1, right ? Correct. A single QP can be used to send data to any SRQ that shares the same domain. -- MST ___ ewg mailing list ewg@lists.openfabrics.org

[ewg] RE: RFCv2: SRC API

OK, I was wrong before, here is my question. if remote node n has j2, j3, and j4, and j2 is the job to create qp2 and make connection with qp1 in j1. if j2 is done before j3 and j4, then we can not let j2 to destroy qp2, because j3 and j4 are still communicating with j1.

[ewg] Re: RFCv2: SRC API

Quoting Tang, Changqing [EMAIL PROTECTED]: Subject: RE: RFCv2: SRC API OK, I was wrong before, here is my question. if remote node n has j2, j3, and j4, and j2 is the job to create qp2 and make connection with qp1 in j1. if j2 is done before j3 and j4, then we can not

[ewg] RE: RFCv2: SRC API

Cleanup: When job j1 does not need to communicate to any jobs on node n, it disconnects qp1 from qp2, and asks j2 to destroy qp2. + +Note: both qp1 and qp2 must exist for the communication to take place. +Thus, j2 should not destroy qp2 (and in particular, should not exit) +until j1

[ewg] Re: RFCv2: SRC API

Quoting Tang, Changqing [EMAIL PROTECTED]: Subject: RE: RFCv2: SRC API Cleanup: When job j1 does not need to communicate to any jobs on node n, it disconnects qp1 from qp2, and asks j2 to destroy qp2. + +Note: both qp1 and qp2 must exist for the communication to take place.

[ewg] [PATCH 1/5 VNIC] DMA interface changes to support iPath

Use the ib_dma interface for compatibility with ipath driver. From: Poornima Kamath [EMAIL PROTECTED] Signed-off-by: Ramachandra K [EMAIL PROTECTED] --- drivers/infiniband/ulp/vnic/vnic_control.c | 352 ++-- drivers/infiniband/ulp/vnic/vnic_data.c| 192

[ewg] [PATCH 2/5 VNIC] Changes to VNIC control state machine (Depends on Patch 1)

Reimplement control statemachine for fixing IB send not completed errors. Also simplify the control command processing logic and remove all control QP retries. From: Poornima Kamath [EMAIL PROTECTED] Signed-off-by: Ramachandra K [EMAIL PROTECTED] --- drivers/infiniband/ulp/vnic/vnic_config.c

[ewg] [PATCH 4/5 VNIC] Delay reconnects to prevent flooding of EVIC (Depends on Patch 3)

Delay the reconnects to prevent the flooding of EVIC in case of a failure. From: Poornima Kamath [EMAIL PROTECTED] Signed-off-by: Ramachandra K [EMAIL PROTECTED] --- drivers/infiniband/ulp/vnic/vnic_main.c|7 +-- drivers/infiniband/ulp/vnic/vnic_netpath.h |1 + 2 files changed,

[ewg] Re: [PATCH 0/5 VNIC] VNIC patch series for OFED-1.2 and OFED-1.2.c

Quoting Ramachandra K [EMAIL PROTECTED]: Subject: [PATCH 0/5 VNIC] VNIC patch series for OFED-1.2 and OFED-1.2.c Vlad, Please apply this VNIC patch series to both the OFED-1.2 and OFED-1.2.c branches. This series contains changes to the VNIC driver for supporting iPath and the new

[ewg] [GIT PULL] Please pull qlvnictools.git

Vlad, For inclusion in OFED-1.2 and OFED-1.2.c, please also pull qlvnictools.git: git://git.openfabrics.org/~ramachandrak/qlvnictools.git Changes include: - Removing check for MTHCA in vnic_parser.pl as now iPath and ConnectX are supported by the VNIC driver - Fix in ibvexdm to

[ewg] RE: [PATCH 0/5 VNIC] VNIC patch series for OFED-1.2 and OFED-1.2.c

-Original Message- From: Michael S. Tsirkin [mailto:[EMAIL PROTECTED] Sent: Mon 8/6/2007 11:48 PM To: Kuchimanchi, Ramachandra Cc: [EMAIL PROTECTED]; ewg@lists.openfabrics.org Subject: Re: [PATCH 0/5 VNIC] VNIC patch series for OFED-1.2 and OFED-1.2.c Quoting Ramachandra K [EMAIL

[ewg] Re: [PATCH 0/5 VNIC] VNIC patch series for OFED-1.2 and OFED-1.2.c

Quoting Kuchimanchi, Ramachandra [EMAIL PROTECTED]: Subject: RE: [PATCH 0/5 VNIC] VNIC patch series for OFED-1.2 and OFED-1.2.c -Original Message- From: Michael S. Tsirkin [mailto:[EMAIL PROTECTED] Sent: Mon 8/6/2007 11:48 PM To: Kuchimanchi, Ramachandra Cc: [EMAIL PROTECTED];

[ewg] RE: [PATCH 0/5 VNIC] VNIC patch series for OFED-1.2 and OFED-1.2.c

From: Michael S. Tsirkin [mailto:[EMAIL PROTECTED] Sent: Tue 8/7/2007 12:16 AM To: Kuchimanchi, Ramachandra Cc: Michael S. Tsirkin; [EMAIL PROTECTED]; ewg@lists.openfabrics.org Subject: Re: [PATCH 0/5 VNIC] VNIC patch series for OFED-1.2 and OFED-1.2.c Quoting Kuchimanchi, Ramachandra [EMAIL

[ewg] Re: [PATCH ofed-1.2.c] ehca: backport kmem_cache_zalloc() for 2.6.10/sles10/sles10_sp1

Hmm, I thought about it some more. kmem_cache struct is not exported on recent kernels, so this might br hard to do. So I think the patch is probably the right approach, after all. Quoting Michael S. Tsirkin [EMAIL PROTECTED]: Subject: Re: [PATCH ofed-1.2.c] ehca: backport kmem_cache_zalloc()