Re: [ewg] RFC: Do we wish to take MPI out of OFED?
On Tue, 02 Jun 2009 at 10:30:07PM +0300, Tziporet Koren wrote: Main reasons to keep MPI in OFED: - All participants test with the same MPI versions, and when installing OFED it is ensured that MPI will work fine with this version. - Customers convenience in install (no need to go to more sites to get MPI) - MPI is an important RDMA ULP and although it is not developed in OFA it is widely used by OFED customers As a customer I strongly support above mentioned pros. It's a guarantee for us that MPI is well tested with OFED release. I believe that this effort saves a lot of troubles that would be raised from separate releases of MPI and OFED distros. thanks, Pawel -- Pawel Dziekonski pawel.dziekon...@wcss.pl Wroclaw Centre for Networking Supercomputing, HPC Department Politechnika Wr., pl. Grunwaldzki 9, bud. D2/101, 50-377 Wroclaw, POLAND phone: +48 71 3202043, fax: +48 71 3225797, http://www.wcss.wroc.pl ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [ofa-general] RFC: Do we wish to take MPI out of OFED?
I'll state right up front that I'm in favor of removing MPI from OFED. :-) On Jun 2, 2009, at 3:30 PM, Tziporet Koren wrote: Here are some of the reasons for keeping MPI in or out of OFED. Main reasons to take MPI out of OFED: - MPI is not developed under OFA - Need to synchronize between different projects -- This point alone is hugely difficult. OFED has been held up multiple times because of MPI release delays. I would like to stress that the open source MPI implementations are entirely different software projects with minimal overlap of personnel between MPI and OFED. Also, OFED is but one of the stacks that the MPI's support. For example, many Open MPI members don't care about OpenFabrics at all. It has sometimes been difficult to rationalize MPI schedule adjustments because of OFED. - Some customers prefer to install a different MPI version then the one in OFED - Also note that OFED only includes the open source MPI's; it's not a level playing field. - Several of Open MPI's features are disabled in OFED builds (e.g., scheduler / resource manager support), causing customers to re- download / re-build Open MPI anyway. *** This is a fairly important point to us. Main reasons to keep MPI in OFED: - All participants test with the same MPI versions, and when installing OFED it is ensured that MPI will work fine with this version. -- I think we're all convinced that testing OFED with the various MPI implementations is a Good Thing -- nobody is suggesting that we remove that. As discussed on the call, we can certainly all test the same version of the open source MPI's during OFED releases and include this information in the release notes (OFED x.y.z was tested with Open MPI a.b.c.). The Open MPI project would be happy to contribute the MPI Testing Tool (MTT; which itself is also open source) to OFED. The MTT was designed for almost exactly this purpose: a large, distributed set of organizations that all need to test the same versions of MPI and report the results to a central location. The MTT is not specific to Open MPI; it can be used with any MPI implementation. The MTT is essentially an engine to download/install MPI implementations, run a set of MPI tests (e.g., IMB, OSU and others), and then report the results to a central database. FWIW: several OFA members are using MTT internally for their own MPI testing. - Customers convenience in install (no need to go to more sites to get MPI) -- My $0.02 is that this is a dubious point. In installing a production HPC cluster, you're getting 20 pieces of software and installing them together. So if you have to get OFED *and* MPI (i.e., 21 pieces of software), I think it makes little difference. Indeed, as noted above, MPI implementations move at a different speed than OFED, so many customers go install their own MPI's anyway (or, per an above point, need to re-install MPI's to enable features that the OFED packaging disables). I think the biggest issue related to this point is going to be customers asking you *used* to bundle MPI, why don't do anymore? - MPI is an important RDMA ULP and although it is not developed in OFA it is widely used by OFED customers -- This point is actually used as a crutch by the OFA: why develop your own comprehensive performance testing / monitoring tools when you have MPI with all of its tools? Removing MPI may help motivate the OFA to have better networking tools than those provided by a ULP. (before you flame, I admit that this is a minor point, but it is still worth noting -- I've always thought it strange that people use MPI to monitor and test their OF-based networks...) -- Jeff Squyres Cisco Systems ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH OFED-1.5] NFSRDMA: NFS backport for SLES11
Jon Mason wrote: This patch provides the NFS backport for SLES11. Since the RDMA infrastructure has not been backports for this distro release, only TCP support has been tested. It passes Connectathon as a client and server. Signed-Off-By: Jon Mason j...@opengridcomputing.com --- Hi Jon, This patch is broken and cannot be applied. Please fix. In addition, this patch includes changes to files not related to NFS: kernel_patches/backport/2.6.27_sles11/mlx4_en_0010_do_not_use_netdev_ops.patch | 65 kernel_patches/backport/2.6.27_sles11/mlx4_en_0030_lro_backport.patch | 606 -- All other patches were applied. Regards, Vladimir ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] RFC: Do we wish to take MPI out of OFED?
On Jun 3, 2009, at 3:39 AM, Pawel Dziekonski wrote: On Tue, 02 Jun 2009 at 10:30:07PM +0300, Tziporet Koren wrote: Main reasons to keep MPI in OFED: - All participants test with the same MPI versions, and when installing OFED it is ensured that MPI will work fine with this version. - Customers convenience in install (no need to go to more sites to get MPI) - MPI is an important RDMA ULP and although it is not developed in OFA it is widely used by OFED customers As a customer I strongly support above mentioned pros. It's a guarantee for us that MPI is well tested with OFED release. MPI makes an effective test bed for the RDMA stack whether it is shipped with it or not. Removing the MPIs from the distribution would not, in all likelihood, change the fact that MPIs would be used to test the RDMA stack prior to release. I believe that this effort saves a lot of troubles that would be raised from separate releases of MPI and OFED distros. If you truly believe this, and you accept that shipping the MPI with the RDMA stack is an acceptable solution to the problem, then you are encouraging totally craptacular engineering as a customer. Since you have a non-US email address, and since craptacular is a word I use frequently, but which I also sort of just made up, let me define that. Sometimes, things are good. When they are really good, they are spectacular. Sometimes, things are crap. When they are *really* crap, they are craptacular. The RDMA stack provides an API. The MPI stacks are nothing more than a consumer of that API. This is no different than TCP sockets and MPI stacks: API provider/consumer relationship. If there is a problem between the MPIs and the RDMA stacks from version to version, it means that one of them isn't adhering to the API. The proper solution to that problem is *NOT* to put them together and throw the API out the window, it's to get the API provider and consumer to adhere to the API and to make sure that the API works. Otherwise, the only solution is to bundle *every* consumer of that API with the API provider because the API stability is, you guessed it, craptacular. If you aren't part of the solution, you're part of the problem. Don't encourage craptacular engineering that throws the API out the window. thanks, Pawel -- Pawel Dziekonski pawel.dziekon...@wcss.pl Wroclaw Centre for Networking Supercomputing, HPC Department Politechnika Wr., pl. Grunwaldzki 9, bud. D2/101, 50-377 Wroclaw, POLAND phone: +48 71 3202043, fax: +48 71 3225797, http://www.wcss.wroc.pl ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg -- Doug Ledford dledf...@redhat.com GPG KeyID: CFBFF194 http://people.redhat.com/dledford InfiniBand Specific RPMS http://people.redhat.com/dledford/Infiniband PGP.sig Description: This is a digitally signed message part ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [PATCH] IB/ehca: Remove superfluous bitmasks from QP control block
All the fields in the control block are nicely right-aligned, so no masking
is necessary.
Signed-off-by: Joachim Fenkes fen...@de.ibm.com
---
drivers/infiniband/hw/ehca/ehca_classes_pSeries.h | 28 -
drivers/infiniband/hw/ehca/ehca_qp.c | 18 +++-
2 files changed, 5 insertions(+), 41 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_classes_pSeries.h
b/drivers/infiniband/hw/ehca/ehca_classes_pSeries.h
index 1798e64..689c357 100644
--- a/drivers/infiniband/hw/ehca/ehca_classes_pSeries.h
+++ b/drivers/infiniband/hw/ehca/ehca_classes_pSeries.h
@@ -165,7 +165,6 @@ struct hcp_modify_qp_control_block {
#define MQPCB_MASK_ALT_P_KEY_IDXEHCA_BMASK_IBM( 7, 7)
#define MQPCB_MASK_RDMA_ATOMIC_CTRL EHCA_BMASK_IBM( 8, 8)
#define MQPCB_MASK_QP_STATE EHCA_BMASK_IBM( 9, 9)
-#define MQPCB_QP_STATE EHCA_BMASK_IBM(24, 31)
#define MQPCB_MASK_RDMA_NR_ATOMIC_RESP_RES EHCA_BMASK_IBM(11, 11)
#define MQPCB_MASK_PATH_MIGRATION_STATE EHCA_BMASK_IBM(12, 12)
#define MQPCB_MASK_RDMA_ATOMIC_OUTST_DEST_QPEHCA_BMASK_IBM(13, 13)
@@ -176,60 +175,33 @@ struct hcp_modify_qp_control_block {
#define MQPCB_MASK_RETRY_COUNT EHCA_BMASK_IBM(18, 18)
#define MQPCB_MASK_TIMEOUT EHCA_BMASK_IBM(19, 19)
#define MQPCB_MASK_PATH_MTU EHCA_BMASK_IBM(20, 20)
-#define MQPCB_PATH_MTU EHCA_BMASK_IBM(24, 31)
#define MQPCB_MASK_MAX_STATIC_RATE EHCA_BMASK_IBM(21, 21)
-#define MQPCB_MAX_STATIC_RATE EHCA_BMASK_IBM(24, 31)
#define MQPCB_MASK_DLID EHCA_BMASK_IBM(22, 22)
-#define MQPCB_DLID EHCA_BMASK_IBM(16, 31)
#define MQPCB_MASK_RNR_RETRY_COUNT EHCA_BMASK_IBM(23, 23)
-#define MQPCB_RNR_RETRY_COUNT EHCA_BMASK_IBM(29, 31)
#define MQPCB_MASK_SOURCE_PATH_BITS EHCA_BMASK_IBM(24, 24)
-#define MQPCB_SOURCE_PATH_BITS EHCA_BMASK_IBM(25, 31)
#define MQPCB_MASK_TRAFFIC_CLASSEHCA_BMASK_IBM(25, 25)
-#define MQPCB_TRAFFIC_CLASS EHCA_BMASK_IBM(24, 31)
#define MQPCB_MASK_HOP_LIMITEHCA_BMASK_IBM(26, 26)
-#define MQPCB_HOP_LIMIT EHCA_BMASK_IBM(24, 31)
#define MQPCB_MASK_SOURCE_GID_IDX EHCA_BMASK_IBM(27, 27)
-#define MQPCB_SOURCE_GID_IDXEHCA_BMASK_IBM(24, 31)
#define MQPCB_MASK_FLOW_LABEL EHCA_BMASK_IBM(28, 28)
-#define MQPCB_FLOW_LABELEHCA_BMASK_IBM(12, 31)
#define MQPCB_MASK_DEST_GID EHCA_BMASK_IBM(30, 30)
#define MQPCB_MASK_SERVICE_LEVEL_AL EHCA_BMASK_IBM(31, 31)
-#define MQPCB_SERVICE_LEVEL_AL EHCA_BMASK_IBM(28, 31)
#define MQPCB_MASK_SEND_GRH_FLAG_AL EHCA_BMASK_IBM(32, 32)
-#define MQPCB_SEND_GRH_FLAG_AL EHCA_BMASK_IBM(31, 31)
#define MQPCB_MASK_RETRY_COUNT_AL EHCA_BMASK_IBM(33, 33)
-#define MQPCB_RETRY_COUNT_ALEHCA_BMASK_IBM(29, 31)
#define MQPCB_MASK_TIMEOUT_AL EHCA_BMASK_IBM(34, 34)
-#define MQPCB_TIMEOUT_ALEHCA_BMASK_IBM(27, 31)
#define MQPCB_MASK_MAX_STATIC_RATE_AL EHCA_BMASK_IBM(35, 35)
-#define MQPCB_MAX_STATIC_RATE_ALEHCA_BMASK_IBM(24, 31)
#define MQPCB_MASK_DLID_AL EHCA_BMASK_IBM(36, 36)
-#define MQPCB_DLID_AL EHCA_BMASK_IBM(16, 31)
#define MQPCB_MASK_RNR_RETRY_COUNT_AL EHCA_BMASK_IBM(37, 37)
-#define MQPCB_RNR_RETRY_COUNT_ALEHCA_BMASK_IBM(29, 31)
#define MQPCB_MASK_SOURCE_PATH_BITS_AL EHCA_BMASK_IBM(38, 38)
-#define MQPCB_SOURCE_PATH_BITS_AL EHCA_BMASK_IBM(25, 31)
#define MQPCB_MASK_TRAFFIC_CLASS_AL EHCA_BMASK_IBM(39, 39)
-#define MQPCB_TRAFFIC_CLASS_AL EHCA_BMASK_IBM(24, 31)
#define MQPCB_MASK_HOP_LIMIT_AL EHCA_BMASK_IBM(40, 40)
-#define MQPCB_HOP_LIMIT_AL EHCA_BMASK_IBM(24, 31)
#define MQPCB_MASK_SOURCE_GID_IDX_ALEHCA_BMASK_IBM(41, 41)
-#define MQPCB_SOURCE_GID_IDX_AL EHCA_BMASK_IBM(24, 31)
#define MQPCB_MASK_FLOW_LABEL_ALEHCA_BMASK_IBM(42, 42)
-#define MQPCB_FLOW_LABEL_AL EHCA_BMASK_IBM(12, 31)
#define MQPCB_MASK_DEST_GID_AL EHCA_BMASK_IBM(44, 44)
#define MQPCB_MASK_MAX_NR_OUTST_SEND_WR EHCA_BMASK_IBM(45, 45)
-#define MQPCB_MAX_NR_OUTST_SEND_WR EHCA_BMASK_IBM(16, 31)
#define MQPCB_MASK_MAX_NR_OUTST_RECV_WR EHCA_BMASK_IBM(46, 46)
-#define MQPCB_MAX_NR_OUTST_RECV_WR EHCA_BMASK_IBM(16, 31)
#define MQPCB_MASK_DISABLE_ETE_CREDIT_CHECK EHCA_BMASK_IBM(47, 47)
-#define MQPCB_DISABLE_ETE_CREDIT_CHECK EHCA_BMASK_IBM(31, 31)
-#define MQPCB_QP_NUMBER
Re: [ewg] [PATCH OFED-1.5] NFSRDMA: NFS backport for SLES11
On Wed, Jun 03, 2009 at 04:10:00PM +0300, Vladimir Sokolovsky wrote: Jon Mason wrote: This patch provides the NFS backport for SLES11. Since the RDMA infrastructure has not been backports for this distro release, only TCP support has been tested. It passes Connectathon as a client and server. Signed-Off-By: Jon Mason j...@opengridcomputing.com --- Hi Jon, This patch is broken and cannot be applied. Please fix. In addition, this patch includes changes to files not related to NFS: kernel_patches/backport/2.6.27_sles11/mlx4_en_0010_do_not_use_netdev_ops.patch | 65 kernel_patches/backport/2.6.27_sles11/mlx4_en_0030_lro_backport.patch | 606 -- All other patches were applied. Sorry, I will split that up into 2 patches and recreate the SLES11 NFS patch. Should be sentout shortly. Thanks, Jon Regards, Vladimir ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [PATCH OFED-1.5] NFSRDMA: NFS backport for SLES11 (version 2)
This patch provides the NFS backport for SLES11. Since the RDMA
infrastructure has not been backports for this distro release, only TCP
support has been tested. It passes Connectathon as a client and server.
Signed-Off-By: Jon Mason j...@opengridcomputing.com
---
diff --git a/kernel_addons/backport/2.6.27_sles11/include/linux/cpumask.h
b/kernel_addons/backport/2.6.27_sles11/include/linux/cpumask.h
new file mode 100644
index 000..391cc04
--- /dev/null
+++ b/kernel_addons/backport/2.6.27_sles11/include/linux/cpumask.h
@@ -0,0 +1,10 @@
+#ifndef BACKPORT_LINUX_CPUMASK_H
+#define BACKPORT_LINUX_CPUMASK_H
+
+#include_next linux/cpumask.h
+#include asm/topology.h
+
+#define cpumask_of(cpu)(get_cpu_mask(cpu))
+#define cpumask_of_node(node) (_node_to_cpumask_ptr(node))
+
+#endif /* BACKPORT_LINUX_CPUMASK_H */
diff --git a/kernel_addons/backport/2.6.27_sles11/include/linux/dcache.h
b/kernel_addons/backport/2.6.27_sles11/include/linux/dcache.h
new file mode 100644
index 000..4a571af
--- /dev/null
+++ b/kernel_addons/backport/2.6.27_sles11/include/linux/dcache.h
@@ -0,0 +1,22 @@
+#ifndef BACKPORT_LINUX_DCACHE_H
+#define BACKPORT_LINUX_DCACHE_H
+
+#include_next linux/dcache.h
+#include linux/err.h
+
+extern void iput(struct inode *);
+
+static inline struct dentry *d_obtain_alias(struct inode *inode)
+{
+ struct dentry *rc;
+
+ rc = d_alloc_anon(inode);
+ if (!rc) {
+ iput(inode);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ return rc;
+}
+
+#endif
diff --git a/kernel_addons/backport/2.6.27_sles11/include/linux/fs.h
b/kernel_addons/backport/2.6.27_sles11/include/linux/fs.h
new file mode 100644
index 000..094dda6
--- /dev/null
+++ b/kernel_addons/backport/2.6.27_sles11/include/linux/fs.h
@@ -0,0 +1,63 @@
+#ifndef BACKPORT_LINUX_FS_H
+#define BACKPORT_LINUX_FS_H
+
+#include_next linux/fs.h
+#include linux/sched.h
+#include linux/fs_struct.h
+
+struct lock_manager {
+ struct list_head list;
+};
+
+void locks_start_grace(struct lock_manager *);
+void locks_end_grace(struct lock_manager *);
+int locks_in_grace(void);
+
+static inline bool execute_ok(struct inode *inode)
+{
+ return (inode-i_mode S_IXUGO) || S_ISDIR(inode-i_mode);
+}
+
+static inline int current_umask(void)
+{
+ return current-fs-umask;
+}
+
+static inline void free_fs_struct(struct fs_struct *fs)
+{
+ struct task_struct *tsk;
+
+ tsk = kzalloc(sizeof(struct task_struct), GFP_KERNEL);
+ if (!tsk)
+ return;
+
+ spin_lock_init(tsk-alloc_lock);
+ tsk-fs = fs;
+
+ exit_fs(tsk);
+ kfree(tsk);
+}
+
+static inline int unshare_fs_struct(void)
+{
+ struct fs_struct *fs = current-fs;
+ struct fs_struct *new_fs = copy_fs_struct(fs);
+ int kill;
+
+ if (!new_fs)
+ return -ENOMEM;
+
+ task_lock(current);
+ write_lock(fs-lock);
+ kill = atomic_read(fs-count) == 1;
+ current-fs = new_fs;
+ write_unlock(fs-lock);
+ task_unlock(current);
+
+ if (kill)
+ free_fs_struct(fs);
+
+ return 0;
+}
+
+#endif
diff --git a/kernel_addons/backport/2.6.27_sles11/include/linux/fscache.h
b/kernel_addons/backport/2.6.27_sles11/include/linux/fscache.h
new file mode 100644
index 000..f758384
--- /dev/null
+++ b/kernel_addons/backport/2.6.27_sles11/include/linux/fscache.h
@@ -0,0 +1,4 @@
+#ifndef BACKPORT_LINUX_FSCACHE_H
+#define BACKPORT_LINUX_FSCACHE_H
+
+#endif
diff --git a/kernel_addons/backport/2.6.27_sles11/include/linux/jiffies.h
b/kernel_addons/backport/2.6.27_sles11/include/linux/jiffies.h
new file mode 100644
index 000..9871948
--- /dev/null
+++ b/kernel_addons/backport/2.6.27_sles11/include/linux/jiffies.h
@@ -0,0 +1,10 @@
+#ifndef _JIFFIES_BACKPORT_H
+#define _JIFFIES_BACKPORT_H
+
+#include_next linux/jiffies.h
+
+#define time_in_range_open(a,b,c) \
+ (time_after_eq(a,b) \
+time_before(a,c))
+
+#endif /* _JIFFIES_BACKPORT_H */
diff --git a/kernel_addons/backport/2.6.27_sles11/include/linux/namei.h
b/kernel_addons/backport/2.6.27_sles11/include/linux/namei.h
new file mode 100644
index 000..ef46b08
--- /dev/null
+++ b/kernel_addons/backport/2.6.27_sles11/include/linux/namei.h
@@ -0,0 +1,17 @@
+#ifndef BACKPORT_LINUX_NAMEI_H
+#define BACKPORT_LINUX_NAMEI_H
+
+#include_next linux/namei.h
+
+#define LOOKUP_EXCL 0x0400
+
+static inline int kern_path(const char *name, unsigned int flags, struct path
*path)
+{
+ struct nameidata nd;
+ int rc = path_lookup(name, flags, nd);
+ if (!rc)
+ *path = nd.path;
+ return rc;
+}
+
+#endif /* BACKPORT_LINUX_NAMEI_H */
diff --git a/kernel_addons/backport/2.6.27_sles11/include/linux/pagevec.h
b/kernel_addons/backport/2.6.27_sles11/include/linux/pagevec.h
new file mode 100644
index 000..1fb684d
--- /dev/null
+++ b/kernel_addons/backport/2.6.27_sles11/include/linux/pagevec.h
@@ -0,0 +1,17 @@
+#ifndef
Re: [ewg] [PATCH OFED-1.5] Move SLES11 backports to attic
Jon Mason wrote: The SLES11 backports are legacy patches from the OFED 1.4 build, and do not apply cleanly to the 2.6.30 kernel. Move them to the attic so they can be referenced for their historical value but no longer interfere with the OFED 1.5 build. Signed-Off-By: Jon Mason j...@opengridcomputing.com --- Applied, Regards, Vladimir ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH OFED-1.5] NFSRDMA: NFS backport for SLES11 (version 2)
Jon Mason wrote: This patch provides the NFS backport for SLES11. Since the RDMA infrastructure has not been backports for this distro release, only TCP support has been tested. It passes Connectathon as a client and server. Signed-Off-By: Jon Mason j...@opengridcomputing.com --- Applied, Regards, Vladimir ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [PATCH OFED-1.5] MTHCA: Fix ilog2 error
ilog2 and roundup_pow_of_two are needed to build mthca, but the current
version of log2.h lacks these in 2.6.22 (and most likely other versions
as well). When log2.h is updated to match the version currently in
RHEL5, mthca compiles cleanly.
Signed-Off-By: Jon Mason j...@opengridcomputing.com
---
diff --git a/kernel_addons/backport/2.6.22/include/linux/log2.h
b/kernel_addons/backport/2.6.22/include/linux/log2.h
index 546a967..aebafd9 100644
--- a/kernel_addons/backport/2.6.22/include/linux/log2.h
+++ b/kernel_addons/backport/2.6.22/include/linux/log2.h
@@ -17,6 +17,54 @@
#include linux/bitops.h
/*
+ * deal with unrepresentable constant logarithms
+ */
+extern __attribute__((const, noreturn))
+int ilog2_NaN(void);
+
+/*
+ * non-constant log of base 2 calculators
+ * - the arch may override these in asm/bitops.h if they can be implemented
+ * more efficiently than using fls() and fls64()
+ * - the arch is not required to handle n==0 if implementing the fallback
+ */
+#ifndef CONFIG_ARCH_HAS_ILOG2_U32
+static inline __attribute__((const))
+int __ilog2_u32(u32 n)
+{
+ return fls(n) - 1;
+}
+#endif
+
+#ifndef CONFIG_ARCH_HAS_ILOG2_U64
+static inline __attribute__((const))
+int __ilog2_u64(u64 n)
+{
+ return fls64(n) - 1;
+}
+#endif
+
+/*
+ * Determine whether some value is a power of two, where zero is
+ * *not* considered a power of two.
+ */
+
+static inline __attribute__((const))
+bool is_power_of_2(unsigned long n)
+{
+ return (n != 0 ((n (n - 1)) == 0));
+}
+
+/*
+ * round up to nearest power of two
+ */
+static inline __attribute__((const))
+unsigned long __roundup_pow_of_two(unsigned long n)
+{
+ return 1UL fls_long(n - 1);
+}
+
+/*
* round down to nearest power of two
*/
static inline __attribute__((const))
@@ -25,6 +73,107 @@ unsigned long __rounddown_pow_of_two(unsigned long n)
return 1UL (fls_long(n) - 1);
}
+/**
+ * ilog2 - log of base 2 of 32-bit or a 64-bit unsigned value
+ * @n - parameter
+ *
+ * constant-capable log of base 2 calculation
+ * - this can be used to initialise global variables from constant data, hence
+ * the massive ternary operator construction
+ *
+ * selects the appropriately-sized optimised version depending on sizeof(n)
+ */
+#define ilog2(n) \
+( \
+ __builtin_constant_p(n) ? ( \
+ (n) 1 ? ilog2_NaN() : \
+ (n) (1ULL 63) ? 63 : \
+ (n) (1ULL 62) ? 62 : \
+ (n) (1ULL 61) ? 61 : \
+ (n) (1ULL 60) ? 60 : \
+ (n) (1ULL 59) ? 59 : \
+ (n) (1ULL 58) ? 58 : \
+ (n) (1ULL 57) ? 57 : \
+ (n) (1ULL 56) ? 56 : \
+ (n) (1ULL 55) ? 55 : \
+ (n) (1ULL 54) ? 54 : \
+ (n) (1ULL 53) ? 53 : \
+ (n) (1ULL 52) ? 52 : \
+ (n) (1ULL 51) ? 51 : \
+ (n) (1ULL 50) ? 50 : \
+ (n) (1ULL 49) ? 49 : \
+ (n) (1ULL 48) ? 48 : \
+ (n) (1ULL 47) ? 47 : \
+ (n) (1ULL 46) ? 46 : \
+ (n) (1ULL 45) ? 45 : \
+ (n) (1ULL 44) ? 44 : \
+ (n) (1ULL 43) ? 43 : \
+ (n) (1ULL 42) ? 42 : \
+ (n) (1ULL 41) ? 41 : \
+ (n) (1ULL 40) ? 40 : \
+ (n) (1ULL 39) ? 39 : \
+ (n) (1ULL 38) ? 38 : \
+ (n) (1ULL 37) ? 37 : \
+ (n) (1ULL 36) ? 36 : \
+ (n) (1ULL 35) ? 35 : \
+ (n) (1ULL 34) ? 34 : \
+ (n) (1ULL 33) ? 33 : \
+ (n) (1ULL 32) ? 32 : \
+ (n) (1ULL 31) ? 31 : \
+ (n) (1ULL 30) ? 30 : \
+ (n) (1ULL 29) ? 29 : \
+ (n) (1ULL 28) ? 28 : \
+ (n) (1ULL 27) ? 27 : \
+ (n) (1ULL 26) ? 26 : \
+ (n) (1ULL 25) ? 25 : \
+ (n) (1ULL 24) ? 24 : \
+ (n) (1ULL 23) ? 23 : \
+ (n) (1ULL 22) ? 22 : \
+ (n) (1ULL 21) ? 21 : \
+ (n) (1ULL 20) ? 20 : \
+ (n) (1ULL 19) ? 19 : \
+ (n) (1ULL 18) ? 18 : \
+ (n) (1ULL 17) ? 17 : \
+ (n) (1ULL 16) ? 16 : \
+ (n) (1ULL 15) ? 15 : \
+ (n) (1ULL 14) ? 14 : \
+ (n) (1ULL 13) ? 13 : \
+ (n) (1ULL 12) ? 12 : \
+ (n) (1ULL 11) ? 11 : \
+ (n) (1ULL 10) ? 10 : \
+
[ewg] Re: [PATCH] IB/ehca: Remove superfluous bitmasks from QP control block
looks fine, applied for 2.6.31 ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
RE: [ewg] RFC: Do we wish to take MPI out of OFED?
Hi, I vote to remove. This is our Open MPI team leader answer: I think it should be taken out from the following reasons: ompi related build errors or bugs can affect OFED release dates many customers prefer their own mpi packages almost all linux distros contain pre-compiled mpi rpms which can be installed with yum/apt-get/... having MPI as part of OFED comlicates its release process and scripts. Regards, Anatoly. -Original Message- From: ewg-boun...@lists.openfabrics.org [mailto:ewg-boun...@lists.openfabrics.org] On Behalf Of Tziporet Koren Sent: Tuesday, June 02, 2009 22:30 To: EWG; OpenFabrics General Subject: [ewg] RFC: Do we wish to take MPI out of OFED? Hello, In the EWG meeting yesterday there was a suggestion to take out all MPI packages including MPI tests out from OFED. Here are some of the reasons for keeping MPI in or out of OFED. Main reasons to take MPI out of OFED: - MPI is not developed under OFA - Need to synchronize between different projects - Some customers prefer to install a different MPI version then the one in OFED Main reasons to keep MPI in OFED: - All participants test with the same MPI versions, and when installing OFED it is ensured that MPI will work fine with this version. - Customers convenience in install (no need to go to more sites to get MPI) - MPI is an important RDMA ULP and although it is not developed in OFA it is widely used by OFED customers Before we decide to do such a change I would like to get the more opinions from the comunity. Thanks, Tziporet ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
