RE: [PATCH V2] libibverbs: Allow arbitrary int values for MTU
Jeff's patch doesn't break old binaries, old binaries, running with normal IB MTUs work fine. The structure layouts all stay the same, etc. FWIW, I did a simple test to confirm this. I installed a stock git HEAD libibverbs into $HOME/libibverbs-HEAD and a libibverbs with the MTU patch in $HOME/libibverbs-mtu-patch. The mlx4 driver was installed into both trees (I used some fairly old Mellanox HCAs+Dell servers for this test). This creates a bit of pain for anyone (like, hypothetically, say, for example, me) who wants to release source that supports both the older and newer version of libibverbs.
Re: [PATCH v3 11/13] IB/srp: Make HCA completion vector configurable
On 7/15/2013 9:23 PM, Bart Van Assche wrote: On 15/07/2013 7:29, Sagi Grimberg wrote: srp_daemon is a package designated for the customer to automatically detect targets in the IB fabric. From our experience here in Mellanox, customers/users like automatic plugplay tools. They are reluctant to build their own scriptology to enhance performance and settle with srp_daemon which is preferred over use of ibsrpdm and manual adding new targets. Regardless, the completion vectors assignment is meaningless without setting proper IRQ affinity, so in the worst case where the user didn't set his IRQ affinity, this assignment will perform like the default completion vector assignment as all IRQs are directed without any masking i.e. core 0. From my experiments in NUMA systems, optimal performance is gained where all IRQs are directed to half of the cores on the NUMA node close to the HCA, and all traffic generators share the other half of the cores on the same NUMA node. So based on that knowledge, I thought that srp_daemon/srp driver will assign it's CQs across the HCAs completion vectors, and the user is encouraged to set the IRQ affinity as described above to gain optimal performance. Adding connections over the far NUMA node don't seem to benefit performance too much... As I mentioned, a use-case I see that may raise a problem here, is if the user would like to maintain multiple SRP connections and reserve some completion vectors for other IB applications on the system. in this case the user will be able to disable srp_daemon/srp driver completion vectors assignment. So, this was just an idea, and easy implementation that would potentially give the user semi-automatic performance optimized configuration... Hello Sagi, I agree with you that it would help a lot if completion vector assignment could be automated such that end users do not have to care about assigning completion vector numbers. The challenge is to find an approach that is general enough such that it works for all possible use cases. One possible approach is to let a tool that has knowledge about the application fill in completion vector numbers in srp_daemon.conf and let srp_daemon use the values generated by this tool. That approach would avoid that srp_daemon has to have any knowledge about the application but would still allow srp_daemon to assign the completion vector numbers. Bart. Hey Bart, This sounds like a nice Idea, but there an inherent problem about applications coming and going while the connections are static (somewhat), how can you control pinning an arbitrary application running (over SRP devices of-course) at certain point of time. So will you agree at least to give target-comp_vector a default of IB_CQ_VECTOR_LEAST_ATTACHED? From my point of view, a user that don't have a slightest clue about completion vectors and performance optimization, this is somewhat better than doing nothing... -Sagi -- 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 11/13] IB/srp: Make HCA completion vector configurable
On 16/07/2013 4:11, Sagi Grimberg wrote: This sounds like a nice Idea, but there an inherent problem about applications coming and going while the connections are static (somewhat), how can you control pinning an arbitrary application running (over SRP devices of-course) at certain point of time. So will you agree at least to give target-comp_vector a default of IB_CQ_VECTOR_LEAST_ATTACHED? From my point of view, a user that don't have a slightest clue about completion vectors and performance optimization, this is somewhat better than doing nothing... Hello Sagi, That sounds like an interesting proposal to me. But did the patch that adds the IB_CQ_VECTOR_LEAST_ATTACHED feature ever get accepted in the upstream Linux kernel ? I have tried to find that symbol in Linux kernel v3.11-rc1 but couldn't find it. Maybe I have overlooked something ? Bart. -- 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 11/13] IB/srp: Make HCA completion vector configurable
On 7/16/2013 1:58 PM, Bart Van Assche wrote: On 16/07/2013 4:11, Sagi Grimberg wrote: This sounds like a nice Idea, but there an inherent problem about applications coming and going while the connections are static (somewhat), how can you control pinning an arbitrary application running (over SRP devices of-course) at certain point of time. So will you agree at least to give target-comp_vector a default of IB_CQ_VECTOR_LEAST_ATTACHED? From my point of view, a user that don't have a slightest clue about completion vectors and performance optimization, this is somewhat better than doing nothing... Hello Sagi, That sounds like an interesting proposal to me. But did the patch that adds the IB_CQ_VECTOR_LEAST_ATTACHED feature ever get accepted in the upstream Linux kernel ? I have tried to find that symbol in Linux kernel v3.11-rc1 but couldn't find it. Maybe I have overlooked something ? Bart. Oh you're right! I'll ask Vu, from git blame on old OFED I see that He wrote the code... Perhaps this should be added as well. -Sagi -- 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] mlx5: qp: variable may be used uninitialized
in the sq_overhead() function, if qp_typ is equal to IB_QPT_RC,
size will be used uninitialized.
Signed-off-by: Andi Shyti a...@etezian.org
---
drivers/infiniband/hw/mlx5/qp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/mlx5/qp.c b/drivers/infiniband/hw/mlx5/qp.c
index 16ac54c..045f8cd 100644
--- a/drivers/infiniband/hw/mlx5/qp.c
+++ b/drivers/infiniband/hw/mlx5/qp.c
@@ -199,7 +199,7 @@ static int set_rq_size(struct mlx5_ib_dev *dev, struct
ib_qp_cap *cap,
static int sq_overhead(enum ib_qp_type qp_type)
{
- int size;
+ int size = 0;
switch (qp_type) {
case IB_QPT_XRC_INI:
--
1.8.3.2
--
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 V2] libibverbs: Allow arbitrary int values for MTU
On Tue, Jul 16, 2013 at 08:04:08AM +, Hefty, Sean wrote: Jeff's patch doesn't break old binaries, old binaries, running with normal IB MTUs work fine. The structure layouts all stay the same, etc. FWIW, I did a simple test to confirm this. I installed a stock git HEAD libibverbs into $HOME/libibverbs-HEAD and a libibverbs with the MTU patch in $HOME/libibverbs-mtu-patch. The mlx4 driver was installed into both trees (I used some fairly old Mellanox HCAs+Dell servers for this test). This creates a bit of pain for anyone (like, hypothetically, say, for example, me) who wants to release source that supports both the older and newer version of libibverbs. But it is so minor. An autoconf test for the ibv_mtu_to_num function in the headers. If it is not defined then define your own in your private headers. All the other source remains the same, the only change is you must call the conversion functions. A source change is completely unvaoidable. Supporting the new MTU values requires updated source. Jason -- 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 11/13] IB/srp: Make HCA completion vector configurable
On 14/07/2013 3:43, Sagi Grimberg wrote: Just wrote a small patch to allow srp_daemon spread connection across HCA's completion vectors. Hello Sagi, How about the following approach: - Add support for reading the completion vector from srp_daemon.conf, similar to how several other parameters are already read from that file. - If the completion vector parameter has not been set in srp_daemon.conf, let srp_daemon assign a completion vector such that IB interrupts for different SRP hosts use different completion vectors. Bart. -- 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 V2] libibverbs: Allow arbitrary int values for MTU
On Jul 16, 2013, at 10:47 AM, Jason Gunthorpe jguntho...@obsidianresearch.com wrote: A source change is completely unvaoidable. Supporting the new MTU values requires updated source. I don't really care one way or the other; I'll submit whatever patch people want. :-) But FWIW, I tend to believe the Doug/Jason position: - MTU really needs to be a plain integer (not an enum) - forcing application source change/adaptation is the safest way to move forward - doing it this way preserves ABI, so existing binaries are safe -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ -- 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 3.11-rc1] mlx5 core: Fix __udivdi3 when compiling for 32 bit arches
From: Randy Dunlap rdun...@infradead.org Date: Mon, 15 Jul 2013 08:52:18 -0700 On 07/15/13 07:56, Tim Gardner wrote: Cc: Eli Cohen e...@mellanox.com Signed-off-by: Tim Gardner tim.gard...@canonical.com I reported this last week and Eli wrote: I have this fixed in my tree and we run the driver on i386. I will check on Sunday why it is not in the patches submitted. Anyway, the patch works for me. Acked-by: Randy Dunlap rdun...@infradead.org Reported-by: Randy Dunlap rdun...@infradead.org 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
[PATCH librdmacm 4/8] configure: Apply updates proposed by autoupdate
'autoupdate' is a tool to help developer to update configure.ac. This patch applies a few fixes as suggested by autoupdate. Signed-off-by: Yann Droneaud ydrone...@opteya.com --- configure.ac | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/configure.ac b/configure.ac index 20c2f94..a9e95c0 100644 --- a/configure.ac +++ b/configure.ac @@ -1,18 +1,18 @@ dnl Process this file with autoconf to produce a configure script. -AC_PREREQ(2.57) -AC_INIT(librdmacm, 1.0.17, linux-rdma@vger.kernel.org) +AC_PREREQ([2.63]) +AC_INIT([librdmacm],[1.0.17],[linux-rdma@vger.kernel.org]) AC_CONFIG_SRCDIR([src/cma.c]) AC_CONFIG_AUX_DIR(config) AC_CONFIG_MACRO_DIR(config) -AC_CONFIG_HEADERS(config.h) +AC_CONFIG_HEADERS([config.h]) AM_INIT_AUTOMAKE([foreign]) m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([yes])]) -AM_PROG_LIBTOOL +LT_INIT AC_ARG_WITH([valgrind], -AC_HELP_STRING([--with-valgrind], +AS_HELP_STRING([--with-valgrind], [Enable valgrind annotations - default NO])) if test $with_valgrind != test $with_valgrind != no; then @@ -50,8 +50,8 @@ AC_CHECK_MEMBER(struct ibv_path_record.service_id, [], dnl Check for gcc atomic intrinsics AC_MSG_CHECKING(compiler support for atomics) -AC_TRY_LINK([int i = 0;], -[ return __sync_add_and_fetch(i, 1) != __sync_sub_and_fetch(i, 1); ], +AC_LINK_IFELSE([AC_LANG_PROGRAM([[int i = 0;]], + [[ return __sync_add_and_fetch(i, 1) != __sync_sub_and_fetch(i, 1); ]])], [ AC_MSG_RESULT(yes) ], [ AC_MSG_RESULT(no) -- 1.8.3.1 -- 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 librdmacm 5/8] configure: Use automake's option subdir-objects
Following advice in Autotool Mythbuster [1], option subdir-objects can be used to have Makefiles create object files in the same directory than theirs source files. It reduces clobbering in the build directory. [1] Autotool Mythbuster, by Diego Elio Flameeyes Petten`o http://www.flameeyes.eu/autotools-mythbuster/automake/nonrecursive.html Signed-off-by: Yann Droneaud ydrone...@opteya.com --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index a9e95c0..807470f 100644 --- a/configure.ac +++ b/configure.ac @@ -6,7 +6,7 @@ AC_CONFIG_SRCDIR([src/cma.c]) AC_CONFIG_AUX_DIR(config) AC_CONFIG_MACRO_DIR(config) AC_CONFIG_HEADERS([config.h]) -AM_INIT_AUTOMAKE([foreign]) +AM_INIT_AUTOMAKE([foreign subdir-objects]) m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([yes])]) LT_INIT -- 1.8.3.1 -- 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 librdmacm 7/8] Remove executable mode bit on plain text files
Source code and man page should not be executable. Signed-off-by: Yann Droneaud ydrone...@opteya.com --- include/rdma/rdma_cma.h | 0 man/rdma_accept.3 | 0 man/rdma_connect.3| 0 man/rdma_create_qp.3 | 0 man/rdma_getaddrinfo.3| 0 man/rdma_join_multicast.3 | 0 man/rdma_notify.3 | 0 src/acm.c | 0 src/addrinfo.c| 0 src/cma.c | 0 10 files changed, 0 insertions(+), 0 deletions(-) mode change 100755 = 100644 include/rdma/rdma_cma.h mode change 100755 = 100644 man/rdma_accept.3 mode change 100755 = 100644 man/rdma_connect.3 mode change 100755 = 100644 man/rdma_create_qp.3 mode change 100755 = 100644 man/rdma_getaddrinfo.3 mode change 100755 = 100644 man/rdma_join_multicast.3 mode change 100755 = 100644 man/rdma_notify.3 mode change 100755 = 100644 src/acm.c mode change 100755 = 100644 src/addrinfo.c mode change 100755 = 100644 src/cma.c diff --git a/include/rdma/rdma_cma.h b/include/rdma/rdma_cma.h old mode 100755 new mode 100644 diff --git a/man/rdma_accept.3 b/man/rdma_accept.3 old mode 100755 new mode 100644 diff --git a/man/rdma_connect.3 b/man/rdma_connect.3 old mode 100755 new mode 100644 diff --git a/man/rdma_create_qp.3 b/man/rdma_create_qp.3 old mode 100755 new mode 100644 diff --git a/man/rdma_getaddrinfo.3 b/man/rdma_getaddrinfo.3 old mode 100755 new mode 100644 diff --git a/man/rdma_join_multicast.3 b/man/rdma_join_multicast.3 old mode 100755 new mode 100644 diff --git a/man/rdma_notify.3 b/man/rdma_notify.3 old mode 100755 new mode 100644 diff --git a/src/acm.c b/src/acm.c old mode 100755 new mode 100644 diff --git a/src/addrinfo.c b/src/addrinfo.c old mode 100755 new mode 100644 diff --git a/src/cma.c b/src/cma.c old mode 100755 new mode 100644 -- 1.8.3.1 -- 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 librdmacm 2/8] Makefile.am: Fix an automake warning
From: Bart Van Assche bvanass...@acm.org Fix the following automake warning message: Makefile.am:1: `INCLUDES' is the old name for `AM_CPPFLAGS' (or `*_CPPFLAGS') A quote from the automake manual: INCLUDES This does the same job as AM_CPPFLAGS (or any per-target _CPPFLAGS variable if it is used). It is an older name for the same functionality. This variable is deprecated; we suggest using AM_CPPFLAGS and per-target _CPPFLAGS instead. Signed-off-by: Bart Van Assche bvanass...@acm.org Signed-off-by: Yann Droneaud ydrone...@opteya.com --- Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index 3198165..e1be9f3 100644 --- a/Makefile.am +++ b/Makefile.am @@ -1,4 +1,4 @@ -INCLUDES = -I$(srcdir)/include +AM_CPPFLAGS = -I$(srcdir)/include rslibdir = $(libdir)/rsocket lib_LTLIBRARIES = src/librdmacm.la -- 1.8.3.1 -- 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 librdmacm 3/8] autogen.sh: Use autoreconf in autogen.sh
From: Jeff Squyres jsquy...@cisco.com The old sequence of Autotools commands listed in autogen.sh is no longer correct. Instead, just use the single autoreconf command, which will invoke all the Right Autotools commands in the correct order. Signed-off-by: Jeff Squyres jsquy...@cisco.com Signed-off-by: Yann Droneaud ydrone...@opteya.com --- autogen.sh | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/autogen.sh b/autogen.sh index f433312..6c9233e 100755 --- a/autogen.sh +++ b/autogen.sh @@ -1,9 +1,4 @@ #! /bin/sh set -x -test -d ./config || mkdir ./config -aclocal -I config -libtoolize --force --copy -autoheader -automake --foreign --add-missing --copy -autoconf +autoreconf -ifv -I config -- 1.8.3.1 -- 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 librdmacm 6/8] Add .gitignore rules
Add the list of files/patterns to be exclueded from git status output. Additionally it will prevent such files/patterns to be added and committed. Signed-off-by: Yann Droneaud ydrone...@opteya.com --- .gitignore | 64 + examples/.gitignore | 22 ++ src/.gitignore | 9 3 files changed, 95 insertions(+) create mode 100644 .gitignore create mode 100644 examples/.gitignore create mode 100644 src/.gitignore diff --git a/.gitignore b/.gitignore new file mode 100644 index 000..cea1f71 --- /dev/null +++ b/.gitignore @@ -0,0 +1,64 @@ +# - see gitignore(5) +# +# http://www.kernel.org/pub/software/scm/git/docs/gitignore.html +# http://git-scm.com/docs/gitignore.html +# +# - ignore files in this current directory with a leading / +# so that files with the same name is a subdirectory +# would not be ignored by mistake. +# +# per directory .gitignore would be used to ignore specific +# files/patterns +# +# - more examples can be found at +# +# https://github.com/github/gitignore +# http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository#Ignoring-Files +# + +# global ignore rules: +# +# backup files +# +*~ + +# local (eg. current directory) rules: +# +# /pattern + +# +# files created by autoreconf (autoconf, automake, libtool) +# + +/INSTALL +/config.guess +/config.sub +/missing +/depcomp +/install-sh +/configure +/aclocal.m4 +/autom4te.cache/ +/config.h.in +/Makefile.in +/compile +/config + +# +# files created by autoscan +# + +/autoscan.log +/configure.scan + +# +# files created by ./configure +# + +/config.h +/config.status +/config.log +/Makefile +/stamp-h1 +/libtool +/librdmacm.spec diff --git a/examples/.gitignore b/examples/.gitignore new file mode 100644 index 000..ed17494 --- /dev/null +++ b/examples/.gitignore @@ -0,0 +1,22 @@ +# files produced by ./configure +/.deps + +# files produced by make (libtool) +/*.o +/*.lo +/*.la +/.libs +/.dirstamp + +/mckey +/rcopy +/rdma_client +/rdma_server +/rdma_xclient +/rdma_xserver +/riostream +/rping +/rstream +/ucmatose +/udaddy +/udpong diff --git a/src/.gitignore b/src/.gitignore new file mode 100644 index 000..139417a --- /dev/null +++ b/src/.gitignore @@ -0,0 +1,9 @@ +# files produced by ./configure +/.deps + +# files produced by make (libtool) +/*.o +/*.lo +/*.la +/.libs +/.dirstamp -- 1.8.3.1 -- 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 librdmacm 8/8] Open files with close on exec flag
File opened by librdmacm are not supposed to be inherited across
exec*(), most of the files are of no use for another program, and
others cannot be used without the associated memory mapping.
This patch changes fopen() open() and socket() to always set
close on exec flag.
This patch also add checks to configure to guess if fopen() supports
e flag. If O_CLOEXEC and SOCK_CLOEXEC are supported, fopen() should
support e. If not supported, its discarded according to POSIX. Many
operating systems have support for fopen(e).
You might find more information about close on exec in the following articles:
- Excuse me son, but your code is leaking !!! by Dan Walsh
http://danwalsh.livejournal.com/53603.html
- Secure File Descriptor Handling by Ulrich Drepper
http://udrepper.livejournal.com/20407.html
Note: this patch won't set close on exec flag on file descriptors
created by the kernel for completion channel and such.
This is addressed by another kernel patch.
Signed-off-by: Yann Droneaud ydrone...@opteya.com
---
configure.ac | 24
src/acm.c| 4 ++--
src/cma.c| 2 +-
3 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/configure.ac b/configure.ac
index 807470f..31b1a0e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -78,6 +78,30 @@ AC_CHECK_HEADER(infiniband/acm.h,
AC_DEFINE(DEFINE_ACM_MSG, 1, [adding ACM message definition]),
[#include infiniband/acm.h]), [])
+dnl Checks close on exec support
+AC_CHECK_HEADERS([fcntl.h sys/socket.h])
+
+AC_CHECK_DECLS([O_CLOEXEC],,[AC_DEFINE([O_CLOEXEC],[0], [Defined to 0 if not
provided])],
+[[
+#ifdef HAVE_FCNTL_H
+# include fcntl.h
+#endif
+]])
+AC_CHECK_DECLS([SOCK_CLOEXEC],,[AC_DEFINE([SOCK_CLOEXEC],[0],[Defined to 0 if
not provided])],
+[[
+#ifdef HAVE_SYS_SOCKET_H
+# include sys/socket.h
+#endif
+]])
+
+AC_CACHE_CHECK(for close on exec modifier for fopen(),
ac_cv_feature_stream_cloexec_flag,
+ [if test $ac_cv_have_decl_O_CLOEXEC = yes ; then
+if test $ac_cv_have_decl_SOCK_CLOEXEC = yes ; then
+ac_cv_feature_stream_cloexec_flag=e
+fi
+fi])
+AC_DEFINE_UNQUOTED([STREAM_CLOEXEC], $ac_cv_feature_stream_cloexec_flag,
[fopen() modifier for setting close on exec flag])
+
AC_CACHE_CHECK(whether ld accepts --version-script, ac_cv_version_script,
if test -n `$LD --help /dev/null 2/dev/null | grep version-script`;
then
ac_cv_version_script=yes
diff --git a/src/acm.c b/src/acm.c
index c9ca5b5..6e8e173 100644
--- a/src/acm.c
+++ b/src/acm.c
@@ -80,7 +80,7 @@ static int ucma_set_server_port(void)
{
FILE *f;
- if ((f = fopen(/var/run/ibacm.port, r))) {
+ if ((f = fopen(/var/run/ibacm.port, r STREAM_CLOEXEC))) {
fscanf(f, %hu, (unsigned short *) server_port);
fclose(f);
}
@@ -100,7 +100,7 @@ void ucma_ib_init(void)
if (!ucma_set_server_port())
goto out;
- sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
+ sock = socket(AF_INET, SOCK_STREAM | SOCK_CLOEXEC, IPPROTO_TCP);
if (sock 0)
goto out;
diff --git a/src/cma.c b/src/cma.c
index 2fb9913..baebecd 100644
--- a/src/cma.c
+++ b/src/cma.c
@@ -328,7 +328,7 @@ struct rdma_event_channel *rdma_create_event_channel(void)
if (!channel)
return NULL;
- channel-fd = open(/dev/infiniband/rdma_cm, O_RDWR);
+ channel-fd = open(/dev/infiniband/rdma_cm, O_RDWR | O_CLOEXEC);
if (channel-fd 0) {
fprintf(stderr, PFX Fatal: unable to open
/dev/infiniband/rdma_cm\n);
goto err;
--
1.8.3.1
--
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 librdmacm 1/8] Add foreign option to AM_INIT_AUTOMAKE
From: Bart Van Assche bvanass...@acm.org Switch to the modern form of the AM_INIT_AUTOMAKE macro and tell automake that the librdmacm package does not follow the GNU standards. This change makes it possible to use 'autoreconf' for the librdmacm package. Signed-off-by: Bart Van Assche bvanass...@acm.org Signed-off-by: Yann Droneaud ydrone...@opteya.com --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 35d79dd..20c2f94 100644 --- a/configure.ac +++ b/configure.ac @@ -6,7 +6,7 @@ AC_CONFIG_SRCDIR([src/cma.c]) AC_CONFIG_AUX_DIR(config) AC_CONFIG_MACRO_DIR(config) AC_CONFIG_HEADERS(config.h) -AM_INIT_AUTOMAKE(librdmacm, 1.0.17) +AM_INIT_AUTOMAKE([foreign]) m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([yes])]) AM_PROG_LIBTOOL -- 1.8.3.1 -- 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 V2] libibverbs: Allow arbitrary int values for MTU
On Tue, Jul 16, 2013 at 10:11 AM, Jeff Squyres (jsquyres) jsquy...@cisco.com wrote: - doing it this way preserves ABI, so existing binaries are safe I still don't get this. Wouldn't an existing binary be pretty surprised to get a value wildly out of range of the enum? - R. -- 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 -next] IB/mlx5: use module_pci_driver to simplify the code
From: Wei Yongjun yongjun_...@trendmicro.com.cn
Use the module_pci_driver() macro to make the code simpler
by eliminating module_init and module_exit calls.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
drivers/infiniband/hw/mlx5/main.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/infiniband/hw/mlx5/main.c
b/drivers/infiniband/hw/mlx5/main.c
index 8000fff..0cdc185 100644
--- a/drivers/infiniband/hw/mlx5/main.c
+++ b/drivers/infiniband/hw/mlx5/main.c
@@ -1490,15 +1490,4 @@ static struct pci_driver mlx5_ib_driver = {
.remove = remove_one
};
-static int __init mlx5_ib_init(void)
-{
- return pci_register_driver(mlx5_ib_driver);
-}
-
-static void __exit mlx5_ib_cleanup(void)
-{
- pci_unregister_driver(mlx5_ib_driver);
-}
-
-module_init(mlx5_ib_init);
-module_exit(mlx5_ib_cleanup);
+module_pci_driver(mlx5_ib_driver);
--
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 V2] libibverbs: Allow arbitrary int values for MTU
A source change is completely unvaoidable. Supporting the new MTU
values requires updated source.
I don't really care one way or the other; I'll submit whatever patch people
want. :-)
But FWIW, I tend to believe the Doug/Jason position:
- MTU really needs to be a plain integer (not an enum)
- forcing application source change/adaptation is the safest way to move
forward
- doing it this way preserves ABI, so existing binaries are safe
I don't remember. Is it known how the mtu is communicated with the kernel?
Looking at kern-abi.h, the mtu fields are:
struct ibv_query_port_resp {
__u8 max_mtu;
__u8 active_mtu;
struct ibv_kern_qp_attr {
__u32 path_mtu;
struct ibv_query_qp_resp {
__u8 path_mtu;
struct ibv_modify_qp {
__u8 path_mtu;
In most cases, we only have 8 bits available to/from the kernel. (There are at
least 16 bits of reserved space in these structures.)
- Sean
--
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 librdmacm 3/8] autogen.sh: Use autoreconf in autogen.sh
Thanks - I pulled in these patches, but see below: diff --git a/autogen.sh b/autogen.sh index f433312..6c9233e 100755 --- a/autogen.sh +++ b/autogen.sh @@ -1,9 +1,4 @@ #! /bin/sh set -x -test -d ./config || mkdir ./config Without the above line, the build fails. I added it back in. If there's some other way of ensuring that this directory exists, please let me know. - Sean -- 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
