Re: [PATCH 2/2] Ad IB_MTU_1500|9000 enums.

2013-04-19 Thread Jeff Squyres (jsquyres)
On Apr 12, 2013, at 11:40 AM, Jeff Squyres (jsquyres) jsquy...@cisco.com 
wrote:

 As an aside I like the use of RDMA_MTU_* for these values.  Again to 
 distinguish them from the IBTA values.  But I know that is poor form.
 
 So what's the right way to move forward on this?  Is it this:
 
 enum ib_mtu {
   IB_MTU_256  = 1,
   IB_MTU_512  = 2,
   IB_MTU_1024 = 3,
   IB_MTU_2048 = 4,
   IB_MTU_4096 = 5,
   RDMA_MTU_1500 = 1500,
   RDMA_MTU_9000 = 9000
 };


Bump.

-- 
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 1/2] Use autoreconf in autogen.sh

2013-04-19 Thread Jeff Squyres (jsquyres)
Bump.

Any thoughts on these two patches?  They're pretty trivial, enable use with 
modern versions of Autotools, and now feature the proper Signed-off-by line.


On Apr 13, 2013, at 8:15 AM, Jeff Squyres jsquy...@cisco.com 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.
 
 Signed-off-by: Jeff Squyres jsquy...@cisco.com
 ---
 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
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


[PATCH] infiniband-diags: updates for new autoconf tools

2013-04-19 Thread Ira Weiny


Signed-off-by: Ira Weiny ira.we...@intel.com
---
 NEWS |2 +
 autogen.sh   |6 +-
 configure.ac |  255 ++
 configure.in |  255 --
 4 files changed, 258 insertions(+), 260 deletions(-)
 create mode 100644 NEWS
 create mode 100644 configure.ac
 delete mode 100644 configure.in

diff --git a/NEWS b/NEWS
new file mode 100644
index 000..84c99e7
--- /dev/null
+++ b/NEWS
@@ -0,0 +1,2 @@
+New automake requires this file.
+
diff --git a/autogen.sh b/autogen.sh
index 7d2821a..3745b11 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -4,9 +4,5 @@
 test -d config || mkdir config
 
 set -x
-aclocal -I config
-libtoolize --force --copy
-autoheader
 doc/generate
-automake --foreign --add-missing --copy
-autoconf
+autoreconf -ifv -I config
diff --git a/configure.ac b/configure.ac
new file mode 100644
index 000..a85d2ed
--- /dev/null
+++ b/configure.ac
@@ -0,0 +1,255 @@
+dnl Process this file with autoconf to produce a configure script.
+
+AC_PREREQ(2.57)
+AC_INIT(infiniband-diags, 1.6.1, linux-rdma@vger.kernel.org)
+AC_CONFIG_AUX_DIR(config)
+AC_CONFIG_MACRO_DIR(config)
+AM_CONFIG_HEADER(config.h)
+AM_INIT_AUTOMAKE
+
+AC_SUBST(RELEASE, ${RELEASE:-unknown})
+AC_SUBST(TARBALL, ${TARBALL:-${PACKAGE}-${VERSION}.tar.gz})
+
+dnl support debug mode
+AC_ARG_ENABLE(debug,
+[  --enable-debug Turn on debug mode],
+[case ${enableval} in
+  yes) debug=true ;;
+  no)  debug=false ;;
+  *) AC_MSG_ERROR(bad value ${enableval} for --enable-debug) ;;
+esac],[debug=false])
+AM_CONDITIONAL(DEBUG, test x$debug = xtrue)
+
+dnl Checks for programs
+AC_PROG_CC
+AC_PROG_LIBTOOL
+
+AC_CHECK_PROG(have_dash, [dash], true, false)
+AM_CONDITIONAL(HAVE_DASH, test x$have_dash = xtrue)
+
+dnl Checks for libraries
+AC_CHECK_LIB(ibumad, umad_init, [],
+   AC_MSG_ERROR([umad_init() not found. diags require libibumad.]))
+AC_CHECK_LIB(ibmad, mad_dump_mlnx_ext_port_info, [],
+   AC_MSG_ERROR([mad_dump_mlnx_ext_port_info() not found.
+   diags require libibmad with mad_dump_mlnx_ext_port_info support.]))
+AC_CHECK_LIB(ibmad, mad_dump_classportinfo, [],
+   AC_MSG_ERROR([mad_dump_classportinfo() not found. diags requires a more 
recent libibmad.]))
+AC_CHECK_MEMBER([struct umad_port.link_layer],
+   [ac_have_umad_port_link_layer=yes],
+   [ac_have_umad_port_link_layer=no],
+   [#include infiniband/umad.h])
+if test $ac_have_umad_port_link_layer = yes; then
+   AC_DEFINE([HAVE_UMAD_PORT_LINK_LAYER], 1, [Define to 1 if struct umad_port 
has link_layer member])
+fi
+AC_CHECK_LIB(osmcomp, cl_qmap_insert, [],
+   AC_MSG_ERROR([cl_qmap_insert() not found. diags require libosmcomp.]))
+
+dnl Checks for header files.
+AC_HEADER_STDC
+AC_CHECK_HEADERS([stdlib.h string.h unistd.h fcntl.h inttypes.h netinet/in.h 
sys/ioctl.h])
+AC_CHECK_HEADER(infiniband/umad.h, [],
+   AC_MSG_ERROR([infiniband/umad.h not found. diags require libibumad.])
+)
+AC_CHECK_HEADER(infiniband/mad.h, [],
+   AC_MSG_ERROR([infiniband/mad.h not found. diags require libibmad.])
+)
+
+dnl Checks for library functions
+AC_FUNC_ERROR_AT_LINE
+AC_FUNC_VPRINTF
+AC_CHECK_FUNCS([strchr strrchr strtol strtoul memset strtoull])
+
+dnl Checks for typedefs, structures, and compiler characteristics.
+AC_C_CONST
+
+dnl Define a configure directory
+IBDIAG_CONFIG_PATH_TMP1=`eval echo ${sysconfdir}`
+IBDIAG_CONFIG_PATH_TMP2=`echo $IBDIAG_CONFIG_PATH_TMP1 | sed 
's/^NONE/$ac_default_prefix/'`
+IBDIAG_CONFIG_PATH=`eval echo $IBDIAG_CONFIG_PATH_TMP2`/infiniband-diags
+AC_SUBST(IBDIAG_CONFIG_PATH)
+AC_DEFINE_UNQUOTED([IBDIAG_CONFIG_PATH], $IBDIAG_CONFIG_PATH, [Define the 
path to configurations])
+
+dnl Check if we should include test utilities
+AC_MSG_CHECKING(for --enable-test-utils)
+AC_ARG_ENABLE(test-utils,
+[  --enable-test-utils build additional test utilities (default=no)],
+[case ${enableval} in
+  yes) tutils=yes ;;
+  no)  tutils=no ;;
+  *) AC_MSG_ERROR(bad value ${enableval} for --enable-test-utils) ;;
+esac],[tutils=no])
+AM_CONDITIONAL(ENABLE_TEST_UTILS, test x$tutils = xyes)
+AC_MSG_RESULT(${tutils=no})
+
+dnl Check if we should include compat utils
+AC_MSG_CHECKING(for --enable-compat-utils)
+AC_ARG_ENABLE(compat-utils,
+[  --enable-compat-utils build deprecated compatibility utilities 
(default=no)],
+[case ${enableval} in
+  yes) cutils=yes ;;
+  no)  cutils=no ;;
+  *) AC_MSG_ERROR(bad value ${enableval} for --enable-compat-utils) ;;
+esac],[cutils=no])
+AM_CONDITIONAL(ENABLE_COMPAT_UTILS, test x$cutils = xyes)
+AC_MSG_RESULT(${cutils=no})
+
+dnl Check for perl and perl install location
+AC_MSG_CHECKING(for --with-perl-path )
+AC_ARG_WITH(perl-path,
+AC_HELP_STRING([--with-perl-path=path],
+   [define perl location]),
+[ case $withval in
+no)
+;;
+*)
+withperlpath=yes
+PERL=$withval
+;;
+esac ]
+)

[PATCH] infiniband-diags: add .gitignore

2013-04-19 Thread Ira Weiny


Signed-off-by: Ira Weiny ira.we...@intel.com
---
 .gitignore |   43 +++
 1 files changed, 43 insertions(+), 0 deletions(-)
 create mode 100644 .gitignore

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 000..390c6d7
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,43 @@
+*.o
+*.lo
+*~
+configure
+Makefile.in
+autom4te.cache
+aclocal.m4
+stamp-h.in
+config.h.in
+config.log
+config.h
+.libs
+.deps
+libibverbs.spec
+Makefile
+config.status
+stamp-h1
+libtool
+INSTALL
+infiniband-diags.spec
+include/ibdiag_version.h
+doc/man/*.8
+scripts/dump_lfts.sh
+scripts/dump_mfts.sh
+scripts/ibcheckerrors
+scripts/ibcheckerrs
+scripts/ibchecknet
+scripts/ibchecknode
+scripts/ibcheckport
+scripts/ibcheckportstate
+scripts/ibcheckportwidth
+scripts/ibcheckstate
+scripts/ibcheckwidth
+scripts/ibclearcounters
+scripts/ibclearerrors
+scripts/ibdatacounters
+scripts/ibdatacounts
+scripts/ibhosts
+scripts/iblinkinfo.pl
+scripts/ibnodes
+scripts/ibqueryerrors.pl
+scripts/ibrouters
+scripts/ibswitches
-- 
1.7.0.7

--
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] infiniband-diags: remove doc/man/ibclearcounters.8.in

2013-04-19 Thread Ira Weiny


ibclearcounters is part of the compatibility package and the man page remains in
the man directory.

Signed-off-by: Ira Weiny ira.we...@intel.com
---
 doc/man/ibclearcounters.8.in |  101 --
 1 files changed, 0 insertions(+), 101 deletions(-)
 delete mode 100644 doc/man/ibclearcounters.8.in

diff --git a/doc/man/ibclearcounters.8.in b/doc/man/ibclearcounters.8.in
deleted file mode 100644
index 106c643..000
--- a/doc/man/ibclearcounters.8.in
+++ /dev/null
@@ -1,101 +0,0 @@
-.\ Man page generated from reStructeredText.
-.
-.TH IBCLEARCOUNTERS 8 @BUILD_DATE@  Open IB Diagnostics
-.SH NAME
-IBCLEARCOUNTERS \- 
-.
-.nr rst2man-indent-level 0
-.
-.de1 rstReportMargin
-\\$1 \\n[an-margin]
-level \\n[rst2man-indent-level]
-level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
--
-\\n[rst2man-indent0]
-\\n[rst2man-indent1]
-\\n[rst2man-indent2]
-..
-.de1 INDENT
-.\ .rstReportMargin pre:
-. RS \\$1
-. nr rst2man-indent\\n[rst2man-indent-level] \\n[an-margin]
-. nr rst2man-indent-level +1
-.\ .rstReportMargin post:
-..
-.de UNINDENT
-. RE
-.\ indent \\n[an-margin]
-.\ old: \\n[rst2man-indent\\n[rst2man-indent-level]]
-.nr rst2man-indent-level -1
-.\ new: \\n[rst2man-indent\\n[rst2man-indent-level]]
-.in \\n[rst2man-indent\\n[rst2man-indent-level]]u
-..
-.SH clear port counters in IB subnet
-.SS SYNOPSIS
-.sp
-ibclearcounters [\-h] [topology\-file | \-C ca_name \-P ca_port \-t(imeout) 
timeout_ms]
-.SS DESCRIPTION
-.sp
-ibclearcounters is a script that clears the PMA port counters by either walking
-the IB subnet topology or using an already saved topology file.
-.SS OPTIONS
-.SS Port Selection flags
-.\ Define the common option -C
-.
-.sp
-\fB\-C, \-\-Ca ca_name\fPuse the specified ca_name.
-.\ Define the common option -P
-.
-.sp
-\fB\-P, \-\-Port ca_port\fPuse the specified ca_port.
-.\ Explanation of local port selection
-.
-.SS Local port Selection
-.sp
-Multiple port/Multiple CA support: when no IB device or port is specified
-(see the local umad parameters below), the libibumad library
-selects the port to use by the following criteria:
-.INDENT 0.0
-.INDENT 3.5
-.INDENT 0.0
-.IP 1. 3
-.
-the first port that is ACTIVE.
-.IP 2. 3
-.
-if not found, the first port that is UP (physical link up).
-.UNINDENT
-.sp
-If a port and/or CA name is specified, the libibumad library attempts
-to fulfill the user request, and will fail if it is not possible.
-.sp
-For example:
-.sp
-.nf
-.ft C
-ibaddr # use the first port (criteria #1 above)
-ibaddr \-C mthca1   # pick the best port from mthca1 only.
-ibaddr \-P 2# use the second (active/up) port from the first 
available IB device.
-ibaddr \-C mthca0 \-P 2  # use the specified port only.
-.ft P
-.fi
-.UNINDENT
-.UNINDENT
-.SS Configuration flags
-.\ Define the common option -t
-.
-.sp
-\fB\-t, \-\-timeout timeout_ms\fP override the default timeout for the 
solicited mads.
-.SS SEE ALSO
-.sp
-\fBibnetdiscover(8), perfquery(8)\fP
-.SS AUTHOR
-.INDENT 0.0
-.TP
-.B Hal Rosenstock
-.
- \fI\%h...@voltaire.com\fP 
-.UNINDENT
-.\ Generated by docutils manpage writer.
-.\ 
-.
-- 
1.7.0.7

--
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: IPoIB header prefetch for fragmented SKB

2013-04-19 Thread Eric Dumazet
I dont think so : a total of 52 bytes are pulled.

(20 bytes for IPv4 header, 32 bytes for TCP header (TS))

On Fri, Apr 19, 2013 at 11:07 AM, Markus Stockhausen
markus.stockhau...@gmx.de wrote:


 Am 17.04.13 21:10 schrieb Eric Dumazet unter eduma...@google.com:

Please try :

diff --git a/drivers/infiniband/ulp/ipoib/ipoib_ib.c
b/drivers/infiniband/ulp/ipoib/ipoib_ib.c
index 2cfa76f..9bdff21 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_ib.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_ib.c
@@ -112,6 +112,8 @@ static void ipoib_ud_skb_put_frags(struct
ipoib_dev_priv *priv,
if (ipoib_ud_need_sg(priv-max_ib_mtu)) {
skb_frag_t *frag = skb_shinfo(skb)-frags[0];
unsigned int size;
+
+   prefetch(page_address(frag-page.p));
/*
 * There is only two buffers needed for max_payload = 4K,
 * first buf size is IPOIB_UD_HEAD_SIZE

 Thanks to both of you for spending time on this.

 Sorry to tell you that the above patch does not give any performance
 improvements. So I put a debug message inside inside pskb_may_pull()
 just in front of __pskb_pull_tail() to give an idea what happens.

 During a netserver/netperf run with an MTU of 2044 bytes I can read
 the following repeating messages:

 [   52.909805] 0 bytes inline, 1988 bytes in fragment, pull 20 bytes
 [   52.909807] 20 bytes inline, 1968 bytes in fragment, pull 40 bytes
 [   52.909809] 40 bytes inline, 1948 bytes in fragment, pull 52 bytes
 [   52.909812] 0 bytes inline, 1988 bytes in fragment, pull 20 bytes
 [   52.909814] 20 bytes inline, 1968 bytes in fragment, pull 40 bytes
 [   52.909816] 40 bytes inline, 1948 bytes in fragment, pull 52 bytes


 Now I'm getting lost somehow. From 2044 bytes 1988 are left in the
 fragment and 112 have to be pulled into the linear part. This is
 achieved by 3 steps. So we are far beyond the cache line size of 64
 bytes.

 Any ideas?

 Markus


--
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: IPoIB header prefetch for fragmented SKB

2013-04-19 Thread Eric Dumazet
This pulls cannot explain a major performance problem.

Its a memcpy( ... 20 bytes). No more no less.

I have NICs here, reaching 20Gbp on a single TCP flow, were the pull is done.

Something else is going on.

On Fri, Apr 19, 2013 at 11:09 AM, Eric Dumazet eduma...@google.com wrote:
 I dont think so : a total of 52 bytes are pulled.

 (20 bytes for IPv4 header, 32 bytes for TCP header (TS))

 On Fri, Apr 19, 2013 at 11:07 AM, Markus Stockhausen
 markus.stockhau...@gmx.de wrote:


 Am 17.04.13 21:10 schrieb Eric Dumazet unter eduma...@google.com:

Please try :

diff --git a/drivers/infiniband/ulp/ipoib/ipoib_ib.c
b/drivers/infiniband/ulp/ipoib/ipoib_ib.c
index 2cfa76f..9bdff21 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_ib.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_ib.c
@@ -112,6 +112,8 @@ static void ipoib_ud_skb_put_frags(struct
ipoib_dev_priv *priv,
if (ipoib_ud_need_sg(priv-max_ib_mtu)) {
skb_frag_t *frag = skb_shinfo(skb)-frags[0];
unsigned int size;
+
+   prefetch(page_address(frag-page.p));
/*
 * There is only two buffers needed for max_payload = 4K,
 * first buf size is IPOIB_UD_HEAD_SIZE

 Thanks to both of you for spending time on this.

 Sorry to tell you that the above patch does not give any performance
 improvements. So I put a debug message inside inside pskb_may_pull()
 just in front of __pskb_pull_tail() to give an idea what happens.

 During a netserver/netperf run with an MTU of 2044 bytes I can read
 the following repeating messages:

 [   52.909805] 0 bytes inline, 1988 bytes in fragment, pull 20 bytes
 [   52.909807] 20 bytes inline, 1968 bytes in fragment, pull 40 bytes
 [   52.909809] 40 bytes inline, 1948 bytes in fragment, pull 52 bytes
 [   52.909812] 0 bytes inline, 1988 bytes in fragment, pull 20 bytes
 [   52.909814] 20 bytes inline, 1968 bytes in fragment, pull 40 bytes
 [   52.909816] 40 bytes inline, 1948 bytes in fragment, pull 52 bytes


 Now I'm getting lost somehow. From 2044 bytes 1988 are left in the
 fragment and 112 have to be pulled into the linear part. This is
 achieved by 3 steps. So we are far beyond the cache line size of 64
 bytes.

 Any ideas?

 Markus


--
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: IPoIB header prefetch for fragmented SKB

2013-04-19 Thread Roland Dreier
On Wed, Apr 17, 2013 at 12:10 PM, Eric Dumazet eduma...@google.com wrote:
 +   prefetch(page_address(frag-page.p));

Would it also make sense to do a

prefetchw(skb-data);

here?  (That's where we'll copy the header, right?)
--
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 1/2] Use autoreconf in autogen.sh

2013-04-19 Thread Hefty, Sean
 Any thoughts on these two patches?  They're pretty trivial, enable use with
 modern versions of Autotools, and now feature the proper Signed-off-by line.

It may help if you identify the library this patch is against.  :)
--
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: IPoIB header prefetch for fragmented SKB

2013-04-19 Thread Eric Dumazet
Almost no driver care to do that, but you could try anyway ;)


On Fri, Apr 19, 2013 at 5:18 PM, Roland Dreier rol...@kernel.org wrote:
 On Wed, Apr 17, 2013 at 12:10 PM, Eric Dumazet eduma...@google.com wrote:
 +   prefetch(page_address(frag-page.p));

 Would it also make sense to do a

 prefetchw(skb-data);

 here?  (That's where we'll copy the header, right?)
--
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 2/2] Ad IB_MTU_1500|9000 enums.

2013-04-19 Thread Doug Ledford
On 04/19/2013 11:24 AM, Jeff Squyres (jsquyres) wrote:
 On Apr 12, 2013, at 11:40 AM, Jeff Squyres (jsquyres) jsquy...@cisco.com 
 wrote:
 
 As an aside I like the use of RDMA_MTU_* for these values.  Again to 
 distinguish them from the IBTA values.  But I know that is poor form.

 So what's the right way to move forward on this?  Is it this:

 enum ib_mtu {
   IB_MTU_256  = 1,
   IB_MTU_512  = 2,
   IB_MTU_1024 = 3,
   IB_MTU_2048 = 4,
   IB_MTU_4096 = 5,
   RDMA_MTU_1500 = 1500,
   RDMA_MTU_9000 =9000
 };
 
 
 Bump.
 

This seems reasonable, but still concerns me a bit.  The original
version was flat out wrong because you can't re-arrange any exposed enum
like this without requiring that all user space apps be recompiled.
This is especially true because ibv_mtu_enum_to_int is an inline, so any
compiled programs won't have been updated by a shared library update,
yet the new enum values can end up showing up, so the apps break when
they start seeing -1 as the return value, or when they interpret 1500 as
2048, etc.

I wonder if the correct way forward isn't to leave these two functions
alone (as inlines you can't change them without a recompile anyway).
However, I would officially change the documentation to specify that
both enum ib_mtu in the queue_pair structs and the result of
ib_mtu_enum_to_int is not exact on non-IB link layers and is deprecated
in favor of a new function: ib_qp_mtu() (or similar) that takes a queue
pair and returns the real mtu for that queue pair based on params and
device the queue pair is on (I could also see it being
ibv_dev_mtu(struct ibv_device *) instead if you want to query the mtu
before you make a queue pair instead).  Then for both IBoE and USNIC
devices, I would just store the actual MTU in the internal ibv device
struct and return that when requested.

This maintains 100% back compatibility with existing apps but allows a
path for people to get better performance/utilization by using the new
function instead of the old one.

--
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