[PATCH 1/4] Add IBV_*_USNIC enums for the Cisco Ethernet Virtual NIC.

[PATCH 1/4] Add IBV_*_USNIC enums for the Cisco Ethernet Virtual NIC.

[Jeff Squyres]

Per off-list conversation with Roland, add some new enums for the
Cisco Ethernet Virtual NIC (it's not an RNIC/iWARP device, so it
doesn't fit in the same category as RDMA_NODE_RNIC / RDMA_TRANSPORT_IWARP).

"USNIC" = "Userspace NIC".

---
 examples/devinfo.c         | 1 +
 include/infiniband/verbs.h | 6 ++++--
 src/enum_strs.c            | 5 +++--
 src/init.c                 | 5 ++++-
 4 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/examples/devinfo.c b/examples/devinfo.c
index 7dc0463..98a6b4b 100644
--- a/examples/devinfo.c
+++ b/examples/devinfo.c
@@ -72,6 +72,7 @@ static const char *transport_str(enum ibv_transport_type transport)
 	switch (transport) {
 	case IBV_TRANSPORT_IB:    return "InfiniBand";
 	case IBV_TRANSPORT_IWARP: return "iWARP";
+	case IBV_TRANSPORT_USNIC: return "USNIC";
 	default:		  return "invalid transport";
 	}
 }
diff --git a/include/infiniband/verbs.h b/include/infiniband/verbs.h
index 6acfc81..6a6944c 100644
--- a/include/infiniband/verbs.h
+++ b/include/infiniband/verbs.h
@@ -68,13 +68,15 @@ enum ibv_node_type {
 	IBV_NODE_CA 		= 1,
 	IBV_NODE_SWITCH,
 	IBV_NODE_ROUTER,
-	IBV_NODE_RNIC
+	IBV_NODE_RNIC,
+	IBV_NODE_USNIC
 };
 
 enum ibv_transport_type {
 	IBV_TRANSPORT_UNKNOWN	= -1,
 	IBV_TRANSPORT_IB	= 0,
-	IBV_TRANSPORT_IWARP
+	IBV_TRANSPORT_IWARP,
+	IBV_TRANSPORT_USNIC
 };
 
 enum ibv_device_cap_flags {
diff --git a/src/enum_strs.c b/src/enum_strs.c
index 54d71a6..0d68c75 100644
--- a/src/enum_strs.c
+++ b/src/enum_strs.c
@@ -38,10 +38,11 @@ const char *ibv_node_type_str(enum ibv_node_type node_type)
 		[IBV_NODE_CA]		= "InfiniBand channel adapter",
 		[IBV_NODE_SWITCH]	= "InfiniBand switch",
 		[IBV_NODE_ROUTER]	= "InfiniBand router",
-		[IBV_NODE_RNIC]		= "iWARP NIC"
+		[IBV_NODE_RNIC]		= "iWARP NIC",
+		[IBV_NODE_USNIC]	= "Ethernet USNIC"
 	};
 
-	if (node_type < IBV_NODE_CA || node_type > IBV_NODE_RNIC)
+	if (node_type < IBV_NODE_CA || node_type > IBV_NODE_USNIC)
 		return "unknown";
 
 	return node_type_str[node_type];
diff --git a/src/init.c b/src/init.c
index 8d6786e..e4ef001 100644
--- a/src/init.c
+++ b/src/init.c
@@ -346,7 +346,7 @@ static struct ibv_device *try_driver(struct ibv_driver *driver,
 			dev->node_type = IBV_NODE_UNKNOWN;
 	} else {
 		dev->node_type = strtol(value, NULL, 10);
-		if (dev->node_type < IBV_NODE_CA || dev->node_type > IBV_NODE_RNIC)
+		if (dev->node_type < IBV_NODE_CA || dev->node_type > IBV_NODE_USNIC)
 			dev->node_type = IBV_NODE_UNKNOWN;
 	}
 
@@ -359,6 +359,9 @@ static struct ibv_device *try_driver(struct ibv_driver *driver,
 	case IBV_NODE_RNIC:
 		dev->transport_type = IBV_TRANSPORT_IWARP;
 		break;
+	case IBV_NODE_USNIC:
+		dev->transport_type = IBV_TRANSPORT_USNIC;
+		break;
 	default:
 		dev->transport_type = IBV_TRANSPORT_UNKNOWN;
 		break;
-- 
1.8.1.1

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/4] Add IBV_MTU_1500|9000 enums.

[Jeff Squyres]

Allow specification of common Ethernet MTUs.

---
 examples/devinfo.c         | 2 ++
 examples/pingpong.c        | 2 ++
 include/infiniband/verbs.h | 6 ++++--
 3 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/examples/devinfo.c b/examples/devinfo.c
index 98a6b4b..6700882 100644
--- a/examples/devinfo.c
+++ b/examples/devinfo.c
@@ -118,8 +118,10 @@ static const char *mtu_str(enum ibv_mtu max_mtu)
 	case IBV_MTU_256:  return "256";
 	case IBV_MTU_512:  return "512";
 	case IBV_MTU_1024: return "1024";
+	case IBV_MTU_1500: return "1500";
 	case IBV_MTU_2048: return "2048";
 	case IBV_MTU_4096: return "4096";
+	case IBV_MTU_9000: return "9000";
 	default:           return "invalid MTU";
 	}
 }
diff --git a/examples/pingpong.c b/examples/pingpong.c
index 90732ef..d7443a8 100644
--- a/examples/pingpong.c
+++ b/examples/pingpong.c
@@ -42,8 +42,10 @@ enum ibv_mtu pp_mtu_to_enum(int mtu)
 	case 256:  return IBV_MTU_256;
 	case 512:  return IBV_MTU_512;
 	case 1024: return IBV_MTU_1024;
+	case 1500: return IBV_MTU_1500;
 	case 2048: return IBV_MTU_2048;
 	case 4096: return IBV_MTU_4096;
+	case 9000: return IBV_MTU_9000;
 	default:   return -1;
 	}
 }
diff --git a/include/infiniband/verbs.h b/include/infiniband/verbs.h
index 6a6944c..1583c34 100644
--- a/include/infiniband/verbs.h
+++ b/include/infiniband/verbs.h
@@ -150,8 +150,10 @@ enum ibv_mtu {
 	IBV_MTU_256  = 1,
 	IBV_MTU_512  = 2,
 	IBV_MTU_1024 = 3,
-	IBV_MTU_2048 = 4,
-	IBV_MTU_4096 = 5
+	IBV_MTU_1500 = 4,
+	IBV_MTU_2048 = 5,
+	IBV_MTU_4096 = 6,
+	IBV_MTU_9000 = 7
 };
 
 enum ibv_port_state {
-- 
1.8.1.1

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/4] Use autoreconf in autogen.sh

[Jeff Squyres]

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.

---
 autogen.sh | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/autogen.sh b/autogen.sh
index fd47839..6c9233e 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -1,8 +1,4 @@
 #! /bin/sh
 
 set -x
-aclocal -I config
-libtoolize --force --copy
-autoheader
-automake --foreign --add-missing --copy
-autoconf
+autoreconf -ifv -I config
-- 
1.8.1.1

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4] Use autoreconf in autogen.sh

[Jeff Squyres (jsquyres)]

Roland --

If there are no objections, can this patch (and patch 4 of this set: https://patchwork.kernel.org/patch/2387321/) be committed?  Neither should not have any real impact other than the modernization of the libibverbs build system.


On Apr 3, 2013, at 9:06 AM, Jeff Squyres <jsquyres-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> wrote:

> 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.
> 
> ---
> autogen.sh | 6 +-----
> 1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/autogen.sh b/autogen.sh
> index fd47839..6c9233e 100755
> --- a/autogen.sh
> +++ b/autogen.sh
> @@ -1,8 +1,4 @@
> #! /bin/sh
> 
> set -x
> -aclocal -I config
> -libtoolize --force --copy
> -autoheader
> -automake --foreign --add-missing --copy
> -autoconf
> +autoreconf -ifv -I config
> -- 
> 1.8.1.1
> 


-- 
Jeff Squyres
jsquyres-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org
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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4] Use autoreconf in autogen.sh

[Or Gerlitz]

On 09/04/2013 00:59, Jeff Squyres (jsquyres) wrote:
> Roland -- If there are no objections, can this patch (and patch 4 of this set: https://patchwork.kernel.org/patch/2387321/) be committed?  Neither should not have any real impact other than the modernization of the libibverbs build system.

Jeff, the patches don't carry signed-of-by signature line... I would 
suggest you resubmit patches 3 and 4 with a signature

Or.

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/4] .gitignore updates and renameconfigure.in->.ac

[Jeff Squyres]

Added some entries to config/.gitignore for newer versions of the GNU
Autotools.  Also renamed configure.in -> configure.ac to accomodate
newer GNU Autotools

(http://lists.gnu.org/archive/html/autotools-announce/2012-11/msg00000.html
announced the intent to drop support for "configure.in" in future
versions of Autoconf).

---
 .gitignore   |  6 +++++
 configure.ac | 74 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 configure.in | 74 ------------------------------------------------------------
 3 files changed, 80 insertions(+), 74 deletions(-)
 create mode 100644 configure.ac
 delete mode 100644 configure.in

diff --git a/.gitignore b/.gitignore
index 78effef..d198dd1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -6,6 +6,7 @@ autom4te.cache
 aclocal.m4
 stamp-h.in
 config.h.in
+config.h.in~
 config.log
 config.h
 .libs
@@ -15,3 +16,8 @@ Makefile
 config.status
 stamp-h1
 libtool
+config/libtool.m4
+config/ltoptions.m4
+config/ltsugar.m4
+config/ltversion.m4
+config/lt~obsolete.m4
diff --git a/configure.ac b/configure.ac
new file mode 100644
index 0000000..efdc5ac
--- /dev/null
+++ b/configure.ac
@@ -0,0 +1,74 @@
+dnl Process this file with autoconf to produce a configure script.
+
+AC_PREREQ(2.57)
+AC_INIT(libibverbs, 1.1.6, linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org)
+AC_CONFIG_SRCDIR([src/ibverbs.h])
+AC_CONFIG_AUX_DIR(config)
+AC_CONFIG_MACRO_DIR(config)
+AC_CONFIG_HEADER(config.h)
+AM_INIT_AUTOMAKE([foreign])
+m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([yes])])
+
+dnl Checks for programs
+AC_PROG_CC
+AC_GNU_SOURCE
+AC_PROG_LN_S
+AC_PROG_LIBTOOL
+
+LT_INIT
+
+AC_ARG_WITH([valgrind],
+    AC_HELP_STRING([--with-valgrind],
+        [Enable Valgrind annotations (small runtime overhead, default NO)]))
+if test x$with_valgrind = x || test x$with_valgrind = xno; then
+    want_valgrind=no
+    AC_DEFINE([NVALGRIND], 1, [Define to 1 to disable Valgrind annotations.])
+else
+    want_valgrind=yes
+    if test -d $with_valgrind; then
+        CPPFLAGS="$CPPFLAGS -I$with_valgrind/include"
+    fi
+fi
+
+dnl Checks for libraries
+AC_CHECK_LIB(dl, dlsym, [],
+    AC_MSG_ERROR([dlsym() not found.  libibverbs requires libdl.]))
+AC_CHECK_LIB(pthread, pthread_mutex_init, [],
+    AC_MSG_ERROR([pthread_mutex_init() not found.  libibverbs requires libpthread.]))
+
+dnl Checks for header files.
+AC_HEADER_STDC
+AC_CHECK_HEADER(valgrind/memcheck.h,
+    [AC_DEFINE(HAVE_VALGRIND_MEMCHECK_H, 1,
+        [Define to 1 if you have the <valgrind/memcheck.h> header file.])],
+    [if test $want_valgrind = yes; then
+        AC_MSG_ERROR([Valgrind memcheck support requested, but <valgrind/memcheck.h> not found.])
+    fi])
+
+dnl Checks for typedefs, structures, and compiler characteristics.
+AC_C_CONST
+
+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
+    else
+	ac_cv_version_script=no
+    fi])
+
+if test $ac_cv_version_script = yes; then
+    LIBIBVERBS_VERSION_SCRIPT='-Wl,--version-script=$(srcdir)/src/libibverbs.map'
+else
+    LIBIBVERBS_VERSION_SCRIPT=
+fi
+AC_SUBST(LIBIBVERBS_VERSION_SCRIPT)
+
+AC_CACHE_CHECK(for .symver assembler support, ac_cv_asm_symver_support,
+    [AC_TRY_COMPILE(, [asm("symbol:\n.symver symbol, api@ABI\n");],
+        ac_cv_asm_symver_support=yes,
+        ac_cv_asm_symver_support=no)])
+if test $ac_cv_asm_symver_support = yes; then
+    AC_DEFINE([HAVE_SYMVER_SUPPORT], 1, [assembler has .symver support])
+fi
+
+AC_CONFIG_FILES([Makefile libibverbs.spec])
+AC_OUTPUT
diff --git a/configure.in b/configure.in
deleted file mode 100644
index efdc5ac..0000000
--- a/configure.in
+++ /dev/null
@@ -1,74 +0,0 @@
-dnl Process this file with autoconf to produce a configure script.
-
-AC_PREREQ(2.57)
-AC_INIT(libibverbs, 1.1.6, linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org)
-AC_CONFIG_SRCDIR([src/ibverbs.h])
-AC_CONFIG_AUX_DIR(config)
-AC_CONFIG_MACRO_DIR(config)
-AC_CONFIG_HEADER(config.h)
-AM_INIT_AUTOMAKE([foreign])
-m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([yes])])
-
-dnl Checks for programs
-AC_PROG_CC
-AC_GNU_SOURCE
-AC_PROG_LN_S
-AC_PROG_LIBTOOL
-
-LT_INIT
-
-AC_ARG_WITH([valgrind],
-    AC_HELP_STRING([--with-valgrind],
-        [Enable Valgrind annotations (small runtime overhead, default NO)]))
-if test x$with_valgrind = x || test x$with_valgrind = xno; then
-    want_valgrind=no
-    AC_DEFINE([NVALGRIND], 1, [Define to 1 to disable Valgrind annotations.])
-else
-    want_valgrind=yes
-    if test -d $with_valgrind; then
-        CPPFLAGS="$CPPFLAGS -I$with_valgrind/include"
-    fi
-fi
-
-dnl Checks for libraries
-AC_CHECK_LIB(dl, dlsym, [],
-    AC_MSG_ERROR([dlsym() not found.  libibverbs requires libdl.]))
-AC_CHECK_LIB(pthread, pthread_mutex_init, [],
-    AC_MSG_ERROR([pthread_mutex_init() not found.  libibverbs requires libpthread.]))
-
-dnl Checks for header files.
-AC_HEADER_STDC
-AC_CHECK_HEADER(valgrind/memcheck.h,
-    [AC_DEFINE(HAVE_VALGRIND_MEMCHECK_H, 1,
-        [Define to 1 if you have the <valgrind/memcheck.h> header file.])],
-    [if test $want_valgrind = yes; then
-        AC_MSG_ERROR([Valgrind memcheck support requested, but <valgrind/memcheck.h> not found.])
-    fi])
-
-dnl Checks for typedefs, structures, and compiler characteristics.
-AC_C_CONST
-
-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
-    else
-	ac_cv_version_script=no
-    fi])
-
-if test $ac_cv_version_script = yes; then
-    LIBIBVERBS_VERSION_SCRIPT='-Wl,--version-script=$(srcdir)/src/libibverbs.map'
-else
-    LIBIBVERBS_VERSION_SCRIPT=
-fi
-AC_SUBST(LIBIBVERBS_VERSION_SCRIPT)
-
-AC_CACHE_CHECK(for .symver assembler support, ac_cv_asm_symver_support,
-    [AC_TRY_COMPILE(, [asm("symbol:\n.symver symbol, api@ABI\n");],
-        ac_cv_asm_symver_support=yes,
-        ac_cv_asm_symver_support=no)])
-if test $ac_cv_asm_symver_support = yes; then
-    AC_DEFINE([HAVE_SYMVER_SUPPORT], 1, [assembler has .symver support])
-fi
-
-AC_CONFIG_FILES([Makefile libibverbs.spec])
-AC_OUTPUT
-- 
1.8.1.1

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 1/4] Add IBV_*_USNIC enums for the Cisco Ethernet Virtual NIC.

[Hefty, Sean]

> Per off-list conversation with Roland, add some new enums for the
> Cisco Ethernet Virtual NIC (it's not an RNIC/iWARP device, so it
> doesn't fit in the same category as RDMA_NODE_RNIC / RDMA_TRANSPORT_IWARP).
> 
> "USNIC" = "Userspace NIC".

Can we get a better patch description?

Maybe mention something about the NIC?  Does it support all verbs?  Is it for kernel users or just user space?  Does this simply export a raw ethernet interface?
 
> ---
>  examples/devinfo.c         | 1 +
>  include/infiniband/verbs.h | 6 ++++--
>  src/enum_strs.c            | 5 +++--
>  src/init.c                 | 5 ++++-
>  4 files changed, 12 insertions(+), 5 deletions(-)
> 
> diff --git a/examples/devinfo.c b/examples/devinfo.c
> index 7dc0463..98a6b4b 100644
> --- a/examples/devinfo.c
> +++ b/examples/devinfo.c
> @@ -72,6 +72,7 @@ static const char *transport_str(enum ibv_transport_type
> transport)
>  	switch (transport) {
>  	case IBV_TRANSPORT_IB:    return "InfiniBand";
>  	case IBV_TRANSPORT_IWARP: return "iWARP";
> +	case IBV_TRANSPORT_USNIC: return "USNIC";
>  	default:		  return "invalid transport";
>  	}
>  }
> diff --git a/include/infiniband/verbs.h b/include/infiniband/verbs.h
> index 6acfc81..6a6944c 100644
> --- a/include/infiniband/verbs.h
> +++ b/include/infiniband/verbs.h
> @@ -68,13 +68,15 @@ enum ibv_node_type {
>  	IBV_NODE_CA 		= 1,
>  	IBV_NODE_SWITCH,
>  	IBV_NODE_ROUTER,
> -	IBV_NODE_RNIC
> +	IBV_NODE_RNIC,
> +	IBV_NODE_USNIC
>  };
> 
>  enum ibv_transport_type {
>  	IBV_TRANSPORT_UNKNOWN	= -1,
>  	IBV_TRANSPORT_IB	= 0,
> -	IBV_TRANSPORT_IWARP
> +	IBV_TRANSPORT_IWARP,
> +	IBV_TRANSPORT_USNIC
>  };
> 
>  enum ibv_device_cap_flags {
> diff --git a/src/enum_strs.c b/src/enum_strs.c
> index 54d71a6..0d68c75 100644
> --- a/src/enum_strs.c
> +++ b/src/enum_strs.c
> @@ -38,10 +38,11 @@ const char *ibv_node_type_str(enum ibv_node_type node_type)
>  		[IBV_NODE_CA]		= "InfiniBand channel adapter",
>  		[IBV_NODE_SWITCH]	= "InfiniBand switch",
>  		[IBV_NODE_ROUTER]	= "InfiniBand router",
> -		[IBV_NODE_RNIC]		= "iWARP NIC"
> +		[IBV_NODE_RNIC]		= "iWARP NIC",
> +		[IBV_NODE_USNIC]	= "Ethernet USNIC"
>  	};
> 
> -	if (node_type < IBV_NODE_CA || node_type > IBV_NODE_RNIC)
> +	if (node_type < IBV_NODE_CA || node_type > IBV_NODE_USNIC)
>  		return "unknown";
> 
>  	return node_type_str[node_type];
> diff --git a/src/init.c b/src/init.c
> index 8d6786e..e4ef001 100644
> --- a/src/init.c
> +++ b/src/init.c
> @@ -346,7 +346,7 @@ static struct ibv_device *try_driver(struct ibv_driver
> *driver,
>  			dev->node_type = IBV_NODE_UNKNOWN;
>  	} else {
>  		dev->node_type = strtol(value, NULL, 10);
> -		if (dev->node_type < IBV_NODE_CA || dev->node_type > IBV_NODE_RNIC)
> +		if (dev->node_type < IBV_NODE_CA || dev->node_type >
> IBV_NODE_USNIC)
>  			dev->node_type = IBV_NODE_UNKNOWN;
>  	}
> 
> @@ -359,6 +359,9 @@ static struct ibv_device *try_driver(struct ibv_driver
> *driver,
>  	case IBV_NODE_RNIC:
>  		dev->transport_type = IBV_TRANSPORT_IWARP;
>  		break;
> +	case IBV_NODE_USNIC:
> +		dev->transport_type = IBV_TRANSPORT_USNIC;
> +		break;
>  	default:
>  		dev->transport_type = IBV_TRANSPORT_UNKNOWN;
>  		break;
> --
> 1.8.1.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] Add IBV_*_USNIC enums for the Cisco Ethernet Virtual NIC.

[Or Gerlitz]

On Wed, Apr 3, 2013 at 5:49 PM, Hefty, Sean <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
>> Per off-list conversation with Roland, add some new enums for the
>> Cisco Ethernet Virtual NIC (it's not an RNIC/iWARP device, so it
>> doesn't fit in the same category as RDMA_NODE_RNIC /
>> RDMA_TRANSPORT_IWARP).  "USNIC" = "Userspace NIC".

> Can we get a better patch description?
> Maybe mention something about the NIC?  Does it support all verbs?  Is it for kernel
> users or just user space?  Does this simply export a raw ethernet interface?

Jeff, I agree with Sean, there's not much point to review/discuss
these general/pre-step patches without seeing some actual device
specific kernel (if there are such or user space code if there aren't
any kernel ones) code. e.g you can submit the two kernel pre-step
patches as the two first pieces in a series that has the driver code.

Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] Add IBV_*_USNIC enums for the Cisco Ethernet Virtual NIC.

[Jeff Squyres (jsquyres)]

On Apr 3, 2013, at 2:45 PM, Or Gerlitz <or.gerlitz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> Jeff, I agree with Sean, there's not much point to review/discuss
> these general/pre-step patches without seeing some actual device
> specific kernel (if there are such or user space code if there aren't
> any kernel ones) code. e.g you can submit the two kernel pre-step
> patches as the two first pieces in a series that has the driver code.


Unfortunately, not yet.

I just sent another mail that explained our rationale: our kernel driver and libibverbs plugin code are working their way through QA.  It'll take a little time before we can submit good patches for these.  The main driving factor for submitting these new enums is so that they can be included in RHEL 6.5.

-- 
Jeff Squyres
jsquyres-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org
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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] Add IBV_*_USNIC enums for the Cisco Ethernet Virtual NIC.

[Jeff Squyres (jsquyres)]

On Apr 3, 2013, at 10:49 AM, "Hefty, Sean" <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:

> Can we get a better patch description?
> 
> Maybe mention something about the NIC?  Does it support all verbs?  Is it for kernel users or just user space?  Does this simply export a raw ethernet interface?

Sure.  For a little background, the 2nd-generation Cisco VIC has been available since last year (IIRC): http://www.cisco.com/en/US/products/ps10277/prod_module_series_home.html.  It's a converged 10G Ethernet adapter available in a variety of form factors (e.g., 2x10G on PCIe and Mezz).

We'll be providing a UD verbs kernel driver and libibverbs plugin for OS bypass.  It is currently going through QA and debugging; it'll probably take a bit more time before we can submit good patches.  The main intended use for this driver is userspace/libibverbs applications, but I suppose it could be used by kernel applications, too.  The wire protocol transport that is uses underneath will initially be a very simple L2-Ethernet based frame (DMAC, SMAC, ET, QP num, etc.).  

We are not exposing a RAW interface at this time; the libibverbs plugin will provide UD QP functionality.

After some off-list discussion with Roland, we chose to create new IBV_*_USNIC enums because none of the current enums were accurate for our device.  It's an Ethernet NIC, but it's not an RNIC.  It's an Ethernet-based transport, but it's not iWARP.

The reason we're asking for these IBV_*_USNIC enums now -- before we've submitted the driver -- is because we're targeting getting our driver included in RHEL 6.5.  There's a bit of a chicken-and-egg issue here: they'll accept our patches for a new hardware driver while that driver is being worked upstream.  But they (rightfully) won't accept patches to IB core and libibverbs until they've been vetted by the community.  Hence, even though our driver is slowly working its way through QA and not available yet, we wanted to submit these new enums upstream for community approval so that they can be included in RHEL 6.5.

Does that help?

-- 
Jeff Squyres
jsquyres-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org
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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 1/4] Add IBV_*_USNIC enums for the Cisco Ethernet Virtual NIC.

[Hefty, Sean]

> The reason we're asking for these IBV_*_USNIC enums now -- before we've
> submitted the driver -- is because we're targeting getting our driver included
> in RHEL 6.5.  There's a bit of a chicken-and-egg issue here: they'll accept our
> patches for a new hardware driver while that driver is being worked upstream.
> But they (rightfully) won't accept patches to IB core and libibverbs until
> they've been vetted by the community.  Hence, even though our driver is slowly
> working its way through QA and not available yet, we wanted to submit these new
> enums upstream for community approval so that they can be included in RHEL 6.5.

I understand the issue.

In the end, these are kernel changes with no actual users of those changes...  But then they are also just small changes to a framework...

Just thinking aloud here, but what if we added 'RDMA_NODE_VENDOR' instead?  Then other fields, such as transport, become vendor specific.

- Sean
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] Add IBV_*_USNIC enums for the Cisco Ethernet Virtual NIC.

[Jeff Squyres (jsquyres)]

Per my previous email, forgive my top reply...

RDMA_NODE_VENDOR would be great, actually. Should I work up a patch for that?

Sent from my phone. No type good. 

On Apr 4, 2013, at 10:32 AM, "Hefty, Sean" <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:

>> The reason we're asking for these IBV_*_USNIC enums now -- before we've
>> submitted the driver -- is because we're targeting getting our driver included
>> in RHEL 6.5.  There's a bit of a chicken-and-egg issue here: they'll accept our
>> patches for a new hardware driver while that driver is being worked upstream.
>> But they (rightfully) won't accept patches to IB core and libibverbs until
>> they've been vetted by the community.  Hence, even though our driver is slowly
>> working its way through QA and not available yet, we wanted to submit these new
>> enums upstream for community approval so that they can be included in RHEL 6.5.
> 
> I understand the issue.
> 
> In the end, these are kernel changes with no actual users of those changes...  But then they are also just small changes to a framework...
> 
> Just thinking aloud here, but what if we added 'RDMA_NODE_VENDOR' instead?  Then other fields, such as transport, become vendor specific.
> 
> - Sean
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 1/4] Add IBV_*_USNIC enums for the Cisco Ethernet Virtual NIC.

[Hefty, Sean]

> RDMA_NODE_VENDOR would be great, actually. Should I work up a patch for that?

I would prefer taking this approach and would be fine accepting such a change.

Roland, do you have an opinion on this?

- Sean
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] Add IBV_*_USNIC enums for the Cisco Ethernet Virtual NIC.

[Or Gerlitz]

Jeff Squyres (jsquyres) <jsquyres-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> wrote:

> Sure.  For a little background, the 2nd-generation Cisco VIC has been available
> since last year (IIRC): http://www.cisco.com/en/US/products/ps10277
> /prod_module_series_home.html.  It's a converged 10G Ethernet adapter available > in a variety of form factors (e.g., 2x10G on PCIe and Mezz).

> After some off-list discussion with Roland, we chose to create new IBV_*_USNIC
> enums because none of the current enums were accurate for our device.  It's an
> Ethernet NIC, but it's not an RNIC.  It's an Ethernet-based transport, but it's not
> iWARP.

>
> The reason we're asking for these IBV_*_USNIC enums now -- before we've submitted the driver -- is because we're targeting getting our driver included in RHEL 6.5.  There's a bit of a chicken-and-egg issue here: they'll accept our patches for a new hardware driver while that driver is being worked upstream.  But they (rightfully) won't accept patches to IB core and libibverbs until they've been vetted by the community.  Hence, even though our driver is slowly working its way through QA and not available yet, we wanted to submit these new enums upstream for community approval so that they can be included in RHEL 6.5.

> Does that help?

yes it does, but I still think we need to see the driver code in order
to conduct proper /better review and maybe even accept the proposed
changes to the IB core. You can submit it as RFC which means "you can
look on it, and give me comments, but don't pick it up yet"

Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] Add IBV_*_USNIC enums for the Cisco Ethernet Virtual NIC.

[Jeff Squyres (jsquyres)]

Forgive the top reply; I'm actually on vacation this week and currently only have email access on my phone...

I'm not sure what you're asking me to do. Are you asking us to submit our known-buggy-and-not-yet-complete driver just to get two enums approved?

Sent from my phone. No type good. 

On Apr 4, 2013, at 5:27 PM, "Or Gerlitz" <or.gerlitz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> Jeff Squyres (jsquyres) <jsquyres-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> wrote:
> 
>> Sure.  For a little background, the 2nd-generation Cisco VIC has been available
>> since last year (IIRC): http://www.cisco.com/en/US/products/ps10277
>> /prod_module_series_home.html.  It's a converged 10G Ethernet adapter available > in a variety of form factors (e.g., 2x10G on PCIe and Mezz).
> 
>> After some off-list discussion with Roland, we chose to create new IBV_*_USNIC
>> enums because none of the current enums were accurate for our device.  It's an
>> Ethernet NIC, but it's not an RNIC.  It's an Ethernet-based transport, but it's not
>> iWARP.
> 
>> 
>> The reason we're asking for these IBV_*_USNIC enums now -- before we've submitted the driver -- is because we're targeting getting our driver included in RHEL 6.5.  There's a bit of a chicken-and-egg issue here: they'll accept our patches for a new hardware driver while that driver is being worked upstream.  But they (rightfully) won't accept patches to IB core and libibverbs until they've been vetted by the community.  Hence, even though our driver is slowly working its way through QA and not available yet, we wanted to submit these new enums upstream for community approval so that they can be included in RHEL 6.5.
> 
>> Does that help?
> 
> yes it does, but I still think we need to see the driver code in order
> to conduct proper /better review and maybe even accept the proposed
> changes to the IB core. You can submit it as RFC which means "you can
> look on it, and give me comments, but don't pick it up yet"
> 
> Or.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] Add IBV_*_USNIC enums for the Cisco Ethernet Virtual NIC.

[Roland Dreier]

On Fri, Apr 5, 2013 at 11:19 AM, Jeff Squyres (jsquyres)
<jsquyres-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> wrote:
> I'm not sure what you're asking me to do. Are you asking us to submit our known-buggy-and-not-yet-complete driver just to get two enums approved?

I think the idea is that without context, it's hard to know if adding
these enums makes sense or not.  And I'm sorry but I'm not that
sympathetic to "my code isn't ready but you have to take this
out-of-context patch so I can meet Red Hat's arbitrary schedule."

 - R.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] Add IBV_*_USNIC enums for the Cisco Ethernet Virtual NIC.

[Jeff Squyres (jsquyres)]

On Apr 5, 2013, at 4:40 PM, Roland Dreier <roland-BHEL68pLQRGGvPXPguhicg@public.gmane.org> wrote:

> I think the idea is that without context, it's hard to know if adding
> these enums makes sense or not.  And I'm sorry but I'm not that
> sympathetic to "my code isn't ready but you have to take this
> out-of-context patch so I can meet Red Hat's arbitrary schedule."


Ok, fair enough.  It'll be a few weeks before we can submit usnic.ko, so I'll re-bring up the IBV_NODE_VENDOR/related patches then.

I think the MTU discussion is still relevant, however -- there seems to be a larger design issue there.  I'll go reply separately on that thread.

-- 
Jeff Squyres
jsquyres-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org
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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html