[ewg] Re: [ofa-general] ANNOUNCE ofed backports for 2.6.22 kernel bits
- A single git reset ORIG_HEAD recovers from a conflicting merge handling conflicts is a big part of a maintainer's job! Because you are a driver maintainer. That's what's different here from regular merge. Please understand: we have upstream code and we have changes against it. Upstream code is golden. If some patch conflicts with it, it is always this patch that needs to be fixed. And I want to ability to bounce that job to patch author - I simply do not know enough about e.g. ehca. also, if the upstream changes touch code that conflicts with a backport patch, you get to fix the problem as it happens That's exactly the thing that I do not want to do. -- MST ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [PATCH ofed-1.2-rc3 2/4] ehca: backport for rhel-4.5 - mmap functonality
Quoting Stefan Roscher [EMAIL PROTECTED]: Subject: [PATCH ofed-1.2-rc3 2/4] ehca: backport for rhel-4.5 - mmap functonality Signed-off-by: Stefan Roscher [EMAIL PROTECTED] --- backport_ehca_2_rhel45_umap.patch | 850 ++ 1 files changed, 850 insertions(+) Guys, I have updated the ofed_kernel (destined for OFED 1.3) kernel tree to 2.6.23-rc1, and this patch no longer applies. The conflicts aren't trivial (e.g. there's been ABI change). I moved it to kernel_patches/attic for now. Could you please take a look and update the patch for that tree? The updated code is here: git://git.openfabrics.org/~mst/ofed_kernel.git ofed_kernel I expect Vlad'll pull it soon, too. -- MST ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] add_open_iscsi_h.patch
Erez, add_open_iscsi_h currently does: -#include scsi/iscsi_if.h +#include iscsi_if.h why is ths bit needed? -- MST ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: add_open_iscsi_h.patch
Michael S. Tsirkin wrote: Erez, add_open_iscsi_h currently does: -#include scsi/iscsi_if.h +#include iscsi_if.h why is ths bit needed? Strange. I remember that I couldn't build OFED 1.2 without it in the past. I tried to rebuild it without this now, and it compiles successfully, so let's remove that code. Erez ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: add_open_iscsi_h.patch
Quoting Erez Zilber [EMAIL PROTECTED]: Subject: Re: add_open_iscsi_h.patch Michael S. Tsirkin wrote: Quoting Erez Zilber [EMAIL PROTECTED]: Subject: Re: add_open_iscsi_h.patch Michael S. Tsirkin wrote: Quoting Erez Zilber [EMAIL PROTECTED]: Subject: Re: add_open_iscsi_h.patch Michael S. Tsirkin wrote: Erez, add_open_iscsi_h currently does: -#include scsi/iscsi_if.h +#include iscsi_if.h why is ths bit needed? Strange. I remember that I couldn't build OFED 1.2 without it in the past. I tried to rebuild it without this now, and it compiles successfully, so let's remove that code. OK, I killed these patches completely and things still build fine. Vlad, please pull my tree into ofed_kernel. Yes, it also works for me. I guess that these are all leftovers. Deleted. Hmm. Do we want to kill them in 1.2.c too? Yes (why not?) Donnu. It's in bugfix-only mode after all. You decide. -- MST ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: add_open_iscsi_h.patch
Michael S. Tsirkin wrote: Quoting Erez Zilber [EMAIL PROTECTED]: Subject: Re: add_open_iscsi_h.patch Michael S. Tsirkin wrote: Quoting Erez Zilber [EMAIL PROTECTED]: Subject: Re: add_open_iscsi_h.patch Michael S. Tsirkin wrote: Quoting Erez Zilber [EMAIL PROTECTED]: Subject: Re: add_open_iscsi_h.patch Michael S. Tsirkin wrote: Erez, add_open_iscsi_h currently does: -#include scsi/iscsi_if.h +#include iscsi_if.h why is ths bit needed? Strange. I remember that I couldn't build OFED 1.2 without it in the past. I tried to rebuild it without this now, and it compiles successfully, so let's remove that code. OK, I killed these patches completely and things still build fine. Vlad, please pull my tree into ofed_kernel. Yes, it also works for me. I guess that these are all leftovers. Deleted. Hmm. Do we want to kill them in 1.2.c too? Yes (why not?) Donnu. It's in bugfix-only mode after all. You decide. OK. Let's do it for OFED 1.3 only. This is not really a bug fix. Erez ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [ofa-general] ANNOUNCE ofed backports for 2.6.22 kernel bits
hi michael, ... On Wed, Jul 25, 2007 at 10:27:23AM +0300, Michael S. Tsirkin wrote: - A single git reset ORIG_HEAD recovers from a conflicting merge handling conflicts is a big part of a maintainer's job! Because you are a driver maintainer. That's what's different here from regular merge. Please understand: we have upstream code and we have changes against it. i am a driver maintainer, but i'm also maintaining the ipath release which is OFED + qlogic specific stuff. i know the process that you go through to make a release. i've lived it now for 2 releases of ipath software. Upstream code is golden. If some patch conflicts with it, it is always this patch that needs to be fixed. And I want to ability to bounce that job to patch author - I simply do not know enough about e.g. ehca. i agree, non-trivial merges should be bounced to the patch author -- nothing about using backport branches prevents or even makes this more difficult, in fact, i have found it to be easier in git than in dealing w/ patches because the environment where the changes need to be made is much more comfortable (git rather than quilt or some random patch stack)... also, if the upstream changes touch code that conflicts with a backport patch, you get to fix the problem as it happens That's exactly the thing that I do not want to do. you don't want to know about a problem a patch until days or weeks later when the auto build keeps failing and you don't know why? it is easy to catch many problems _before_ the build check fails... arthur ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [ofa-general] ANNOUNCE ofed backports for 2.6.22 kernel bits
also, if the upstream changes touch code that conflicts with a backport patch, you get to fix the problem as it happens That's exactly the thing that I do not want to do. you don't want to know about a problem a patch until days or weeks later when the auto build keeps failing and you don't know why? it is easy to catch many problems _before_ the build check fails... I don't work this way. I just just apply all patches before pushing out. And I see *immediately* the patch that conflicts - unlike merge conflict where I will know which file conflicts but not which change created the conflict. And if a patch conflicts with upstream code, an option to move the patch aside and defer the merge decision to patch author is very important to me: this just happened with ehca backport and update to 2.6.23-rc1. I do not want to delay update to 2.6.23-rc1 until IBM can be bothered to update their backport. Yes, this means that the specific module won't build on a specific kernel until the conflict is resolved. But there are multiple conflicts and each needs to be resolved by another person. -- MST ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [PATCH ofed-1.2-rc3 2/4] ehca: backport for rhel-4.5 - mmap functonality
Hi Michael,
Below is the version without conflicts. And it should compile.
As soon as the build scripts are ready, I'll test the whole backport.
Thanks
Nam
From 6fa28219914394064a49c34030a09e23d160231c Mon Sep 17 00:00:00 2001
From: [EMAIL PROTECTED]
Date: Wed, 25 Jul 2007 17:16:53 +0200
Subject: [PATCH ofed-1.3-alpha] ehca: backport_ehca_2_rhel45_umap.patch
---
drivers/infiniband/hw/ehca/ehca_classes.h | 29 ++-
drivers/infiniband/hw/ehca/ehca_cq.c | 66 -
drivers/infiniband/hw/ehca/ehca_iverbs.h |8 +
drivers/infiniband/hw/ehca/ehca_qp.c | 92 +--
drivers/infiniband/hw/ehca/ehca_uverbs.c | 423 +
5 files changed, 395 insertions(+), 223 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_classes.h
b/drivers/infiniband/hw/ehca/ehca_classes.h
index 3725aa8..49d6155 100644
--- a/drivers/infiniband/hw/ehca/ehca_classes.h
+++ b/drivers/infiniband/hw/ehca/ehca_classes.h
@@ -160,14 +160,13 @@ struct ehca_qp {
struct ipz_qp_handle ipz_qp_handle;
struct ehca_pfqp pf;
struct ib_qp_init_attr init_attr;
+ u64 uspace_squeue;
+ u64 uspace_rqueue;
+ u64 uspace_fwh;
struct ehca_cq *send_cq;
struct ehca_cq *recv_cq;
unsigned int sqerr_purgeflag;
struct hlist_node list_entries;
- /* mmap counter for resources mapped into user space */
- u32 mm_count_squeue;
- u32 mm_count_rqueue;
- u32 mm_count_galpa;
};
#define IS_SRQ(qp) (qp-ext_type == EQPT_SRQ)
@@ -188,6 +187,8 @@ struct ehca_cq {
struct ipz_cq_handle ipz_cq_handle;
struct ehca_pfcq pf;
spinlock_t cb_lock;
+ u64 uspace_queue;
+ u64 uspace_fwh;
struct hlist_head qp_hashtab[QP_HASHTAB_LEN];
struct list_head entry;
u32 nr_callbacks; /* #events assigned to cpu by scaling code */
@@ -195,9 +196,6 @@ struct ehca_cq {
wait_queue_head_t wait_completion;
spinlock_t task_lock;
u32 ownpid;
- /* mmap counter for resources mapped into user space */
- u32 mm_count_queue;
- u32 mm_count_galpa;
};
enum ehca_mr_flag {
@@ -300,6 +298,20 @@ struct ehca_ucontext {
struct ib_ucontext ib_ucontext;
};
+struct ehca_module *ehca_module_new(void);
+
+int ehca_module_delete(struct ehca_module *me);
+
+int ehca_eq_ctor(struct ehca_eq *eq);
+
+int ehca_eq_dtor(struct ehca_eq *eq);
+
+struct ehca_shca *ehca_shca_new(void);
+
+int ehca_shca_delete(struct ehca_shca *me);
+
+struct ehca_sport *ehca_sport_new(struct ehca_shca *anchor);
+
int ehca_init_pd_cache(void);
void ehca_cleanup_pd_cache(void);
int ehca_init_cq_cache(void);
@@ -324,6 +336,7 @@ extern int ehca_use_hp_mr;
extern int ehca_scaling_code;
struct ipzu_queue_resp {
+ u64 queue;/* points to first queue entry */
u32 qe_size; /* queue entry size */
u32 act_nr_of_sg;
u32 queue_length; /* queue length allocated in bytes */
@@ -336,6 +349,7 @@ struct ehca_create_cq_resp {
u32 cq_number;
u32 token;
struct ipzu_queue_resp ipz_queue;
+ struct h_galpas galpas;
};
struct ehca_create_qp_resp {
@@ -349,6 +363,7 @@ struct ehca_create_qp_resp {
u32 dummy; /* padding for 8 byte alignment */
struct ipzu_queue_resp ipz_squeue;
struct ipzu_queue_resp ipz_rqueue;
+ struct h_galpas galpas;
};
struct ehca_alloc_cq_parms {
diff --git a/drivers/infiniband/hw/ehca/ehca_cq.c
b/drivers/infiniband/hw/ehca/ehca_cq.c
index 9c7172b..ac0bb10 100644
--- a/drivers/infiniband/hw/ehca/ehca_cq.c
+++ b/drivers/infiniband/hw/ehca/ehca_cq.c
@@ -268,6 +268,7 @@ struct ib_cq *ehca_create_cq(struct ib_device *device, int
cqe, int comp_vector,
if (context) {
struct ipz_queue *ipz_queue = my_cq-ipz_queue;
struct ehca_create_cq_resp resp;
+ struct vm_area_struct *vma;
memset(resp, 0, sizeof(resp));
resp.cq_number = my_cq-cq_number;
resp.token = my_cq-token;
@@ -276,14 +277,40 @@ struct ib_cq *ehca_create_cq(struct ib_device *device,
int cqe, int comp_vector,
resp.ipz_queue.queue_length = ipz_queue-queue_length;
resp.ipz_queue.pagesize = ipz_queue-pagesize;
resp.ipz_queue.toggle_state = ipz_queue-toggle_state;
+ ret = ehca_mmap_nopage(((u64)(my_cq-token) 32) | 0x1200,
+ ipz_queue-queue_length,
+ (void**)resp.ipz_queue.queue,
+ vma);
+ if (ret) {
+ ehca_err(device, Could not mmap queue pages);
+ cq = ERR_PTR(ret);
+ goto create_cq_exit4;
+ }
+ my_cq-uspace_queue = resp.ipz_queue.queue;
+ resp.galpas = my_cq-galpas;
+ ret = ehca_mmap_register(my_cq-galpas.user.fw_handle,
Re: [ewg] Re: [ofa-general] RE: OFA website edits
Heh -- I didn't notice these links until Sean moved them up to the top of the text. Yes, we should definitely link to the MPI project home sites; we have lots of our own information there, separate downloads, etc. On Jul 25, 2007, at 3:23 PM, Sean Hefty wrote: http://www.openfabrics.org/downloads/mpi/mvapich (pasha) http://www.openfabrics.org/downloads/mpi/mvapich2 (rowland) http://www.openfabrics.org/downloads/mpi/openmpi (jsquyres) Are all of these MPI versions distributed by OFA? If they have other official sites, should we instead direct users to that site? Or will this be automated enough that people can provide their own links? - Sean ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg -- Jeff Squyres Cisco Systems ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [PATCH ofed-1.2-rc3 2/4] ehca: backport for rhel-4.5 - mmap functonality
Quoting Hoang-Nam Nguyen [EMAIL PROTECTED]: Subject: Re: [PATCH ofed-1.2-rc3 2/4] ehca: backport for rhel-4.5 - mmap functonality Hi Michael, Below is the version without conflicts. And it should compile. Seems to apply fine. I pushed it out. Vlad, can you take it pls? As soon as the build scripts are ready, I'll test the whole backport. What kind of scripts are you waiting for? -- MST ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: ANNOUNCE: ofed kernel build updates
Michael, I only got a chance to try the ofed_makedist.sh and compile (not actually run). However the build worked very well! So initial feedback is this works much better. Thanks, Ira On Wed, 25 Jul 2007 17:11:41 +0300 Michael S. Tsirkin [EMAIL PROTECTED] wrote: Hi! I'd like to announce a couple of updates that were recently made to the build scripts on the ofed_kernel branch. This is an attempt to answer repeated requests, aired at Sonoma, to simplify access to kernel sources. The idea is that a user of a supported kernel will just be able to download an appropriate tarball and run with it without need for patching. These changes are available from ofed_kernel git tree maintained by Vlad: git://git.openfabrics.org/~vlad/ofed_kernel.git ofed_kernel The code is mine, but the ideas mostly come from criticism and code sent by Ira Weiny. Thanks, Ira! Note that the changes were made in a backwards-compatible way, so that existing scripts using configure/make will continue working. What's new: 1. New script ofed_scripts/ofed_patch.sh This will apply fixes and backport patches for a specific kernel to the current tree. Usage: ./ofed_scripts/ofed_patch.sh --with-backport=VERSION This makes it possible for distro vendors to generate a tarball pre-patched for a specific kernel. 2. New script ofed_scripts/ofed_makedist.sh This script repeatedly clones the current repository, runs ofed_scripts/ofed_patch.sh, and then builds tarballs of ofed kernel source pre-patched for supported kernel versions. I plan to work with Vlad to run this script as part of nightly builds, so that prepatched tarballs will become available for download. 3. configure script made re-entrant configure script does not apply patches anymore: all it does is create configure.mk.kernel and autoconf.h files. This finally makes it possible to change configuration parameters just by re-running configure. For backwards-compatibility, if configure detects that ofed_scripts/ofed_patch.sh was not run yet, it prints a warning and runs it automatically. Feedback wellcome. -- MST ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Re: [ofa-general] RE: OFA website edits
Jeff Squyres wrote: Heh -- I didn't notice these links until Sean moved them up to the top of the text. Yes, we should definitely link to the MPI project home sites; we have lots of our own information there, separate downloads, etc. ] Are these the links we want? MVAPICH - http://mvapich.cse.ohio-state.edu/ OpenMPI - http://www.open-mpi.org/ ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [ofa-general] RE: OFA website edits
http://www.openfabrics.org/downloads/mpi/mvapich (pasha) http://www.openfabrics.org/downloads/mpi/mvapich2 (rowland) http://www.openfabrics.org/downloads/mpi/openmpi (jsquyres) Are all of these MPI versions distributed by OFA? If they have other official sites, should we instead direct users to that site? Or will this be automated enough that people can provide their own links? - Sean ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [ofa-general] RE: OFA website edits
I would like to propose adding project directories under http://www.openfabrics.org/downloads/ where appropriate and give maintainers access. For example: Jeff, please add the following directories with maintainer access as follow (or grant access at a maintainer group level): http://www.openfabrics.org/downloads/verbs (rdreier) http://www.openfabrics.org/downloads/rdmacm (shefty) http://www.openfabrics.org/downloads/dapl (ardavis) http://www.openfabrics.org/downloads/sdp (eitan) http://www.openfabrics.org/downloads/utils (eitan) http://www.openfabrics.org/downloads/management (sashak) http://www.openfabrics.org/downloads/OFED (vlad) http://www.openfabrics.org/downloads/archives (vlad) http://www.openfabrics.org/downloads/WinOF (ssmith) (Stan Smith will need an account) http://www.openfabrics.org/downloads/hw/mthca (rdreir) http://www.openfabrics.org/downloads/hw/mlx4 (rdreir) http://www.openfabrics.org/downloads/hw/ehca (raisch) http://www.openfabrics.org/downloads/hw/ipath (ralphc) http://www.openfabrics.org/downloads/hw/cxgb3 (ralphc) http://www.openfabrics.org/downloads/mpi/mvapich (pasha) http://www.openfabrics.org/downloads/mpi/mvapich2 (rowland) http://www.openfabrics.org/downloads/mpi/openmpi (jsquyres) Let us know when these directories are created and the maintainers, who want to expose their packages via the webpage, will create a README that details the contents of the directory along with WEB_README that provides a short description for the webpage. Will this format allow you to auto configure the download webpage sufficiently? The idea is to only add links/descriptions to those project sub-directories with WEB_README files present. Please advise if something on the list is wrong or we missed a project. Thanks, -arlin ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
