Whamcloud - gitweb
LUDOC-235 ptllnd: Remove references to ptllnd 39/27339/3
authorCory Spitz <spitzcor@cray.com>
Tue, 30 May 2017 22:18:37 +0000 (17:18 -0500)
committerJoseph Gmitter <joseph.gmitter@intel.com>
Wed, 31 May 2017 13:22:54 +0000 (13:22 +0000)
LU-1422 (resolved for 2.6.0) removed the ptllnd from the source
tree.  References to the ptllnd should have been removed from the
manual at that time.

Signed-off-by: Cory Spitz <spitzcor@cray.com>
Change-Id: I99d0d472c63993307eecc3306f8b7d75bd808647
Reviewed-on: https://review.whamcloud.com/27339
Tested-by: Jenkins
Reviewed-by: Joseph Gmitter <joseph.gmitter@intel.com>
ConfigurationFilesModuleParameters.xml
ManagingSecurity.xml
UnderstandingLustreNetworking.xml

index e526884..56e94de 100644 (file)
@@ -491,134 +491,6 @@ forwarding (&quot;&quot;)</title>
       </informaltable>
     </section>
     <section remap="h3">
-      <title><indexterm>
-          <primary>configuring</primary>
-          <secondary>portals</secondary>
-        </indexterm>Portals LND Linux (ptllnd)</title>
-      <para>The Portals LND Linux (<literal>ptllnd</literal>) can be used as a interface layer to communicate with Sandia Portals networking devices. This version is intended to work on Cray XT3 Linux nodes that use Cray Portals as a network transport.</para>
-      <para><emphasis role="bold">Message Buffers</emphasis></para>
-      <para>When <literal>ptllnd</literal> starts up, it allocates and posts sufficient message buffers to allow all expected peers (set by concurrent_peers) to send one unsolicited message. The first message that a peer actually sends is (so-called) &quot;<literal>HELLO</literal>&quot; message, used to negotiate how much additional buffering to setup (typically 8 messages). If 10000 peers actually exist, then enough buffers are posted for 80000 messages.</para>
-      <para>The maximum message size is set by the <literal>max_msg_size</literal> module parameter (default value is 512). This parameter sets the bulk transfer breakpoint. Below this breakpoint, payload data is sent in the message itself. Above this breakpoint, a buffer descriptor is sent and the receiver gets the actual payload.</para>
-      <para>The buffer size is set by the <literal>rxb_npages</literal> module parameter (default value is <literal>1</literal>). The default conservatively avoids allocation problems due to kernel memory fragmentation. However, increasing this value to 2 is probably not risky.</para>
-      <para>The <literal>ptllnd</literal> also keeps an additional <literal>rxb_nspare</literal> buffers (default value is 8) posted to account for full buffers being handled.</para>
-      <para>Assuming a 4K page size with 10000 peers, 1258 buffers can be expected to be posted at startup, increasing to a maximum of 10008 as peers that are actually connected. By doubling <literal>rxb_npages</literal> halving <literal>max_msg_size</literal>, this number can be reduced by a factor of 4.</para>
-      <para><emphasis role="bold">ME/MD Queue Length</emphasis></para>
-      <para>The <literal>ptllnd</literal> uses a single portal set by the portal module parameter (default value of 9) for both message and bulk buffers. Message buffers are always attached with <literal>PTL_INS_AFTER</literal> and match anything sent with &quot;message&quot; matchbits. Bulk buffers are always attached with <literal>PTL_INS_BEFORE</literal> and match only specific matchbits for that particular bulk transfer.</para>
-      <para>This scheme assumes that the majority of ME/MDs posted are for &quot;message&quot; buffers, and that the overhead of searching through the preceding &quot;bulk&quot; buffers is acceptable. Since the number of &quot;bulk&quot; buffers posted at any time is also dependent on the bulk transfer breakpoint set by <literal>max_msg_size</literal>, this seems like an issue worth measuring at scale.</para>
-      <para><emphasis role="bold">TX Descriptors</emphasis></para>
-      <para>The <literal>ptllnd</literal> has a pool of so-called &quot;tx descriptors&quot;, which it uses not only for outgoing messages, but also to hold state for bulk transfers requested by incoming messages. This pool should scale with the total number of peers.</para>
-      <para>To enable the building of the Portals LND (<literal>ptllnd.ko</literal>) configure with this option:</para>
-      <screen>./configure --with-portals=<replaceable>/path/to/portals/headers</replaceable></screen>
-      <informaltable frame="all">
-        <tgroup cols="2">
-          <colspec colname="c1" colwidth="50*"/>
-          <colspec colname="c2" colwidth="50*"/>
-          <thead>
-            <row>
-              <entry>
-                <para><emphasis role="bold">Variable</emphasis></para>
-              </entry>
-              <entry>
-                <para><emphasis role="bold">Description</emphasis></para>
-              </entry>
-            </row>
-          </thead>
-          <tbody>
-            <row>
-              <entry>
-                <para> <literal>ntx</literal></para>
-                <para> <literal>(256)</literal></para>
-              </entry>
-              <entry>
-                <para>Total number of messaging descriptors.</para>
-              </entry>
-            </row>
-            <row>
-              <entry>
-                <para> <literal>concurrent_peers</literal></para>
-                <para> <literal>(1152)</literal></para>
-              </entry>
-              <entry>
-                <para>Maximum number of concurrent peers. Peers that attempt to connect beyond the maximum are not allowed.</para>
-              </entry>
-            </row>
-            <row>
-              <entry>
-                <para> <literal>peer_hash_table_size</literal></para>
-                <para> <literal>(101)</literal></para>
-              </entry>
-              <entry>
-                <para>Number of hash table slots for the peers. This number should scale with <literal>concurrent_peers</literal>. The size of the peer hash table is set by the module parameter <literal>peer_hash_table_size</literal> which defaults to a value of 101. This number should be prime to ensure the peer hash table is populated evenly. It is advisable to increase this value to 1001 for ~10000 peers.</para>
-              </entry>
-            </row>
-            <row>
-              <entry>
-                <para> <literal>cksum</literal></para>
-                <para> <literal>(0)</literal></para>
-              </entry>
-              <entry>
-                <para>Set to non-zero to enable message (not RDMA) checksums for outgoing packets. Incoming packets are always check-summed if necessary, independent of this value.</para>
-              </entry>
-            </row>
-            <row>
-              <entry>
-                <para> <literal>timeout</literal></para>
-                <para> <literal>(50)</literal></para>
-              </entry>
-              <entry>
-                <para>Amount of time (in seconds) that a request can linger in a peers-active queue before the peer is considered dead.</para>
-              </entry>
-            </row>
-            <row>
-              <entry>
-                <para> <literal>portal</literal></para>
-                <para> <literal>(9)</literal></para>
-              </entry>
-              <entry>
-                <para>Portal ID to use for the <literal>ptllnd</literal> traffic.</para>
-              </entry>
-            </row>
-            <row>
-              <entry>
-                <para> <literal>rxb_npages</literal></para>
-                <para> <literal>(64 * #cpus)</literal></para>
-              </entry>
-              <entry>
-                <para>Number of pages in an RX buffer.</para>
-              </entry>
-            </row>
-            <row>
-              <entry>
-                <para> <literal>credits</literal></para>
-                <para> <literal>(128)</literal></para>
-              </entry>
-              <entry>
-                <para>Maximum total number of concurrent sends that are outstanding to a single peer at a given time.</para>
-              </entry>
-            </row>
-            <row>
-              <entry>
-                <para> <literal>peercredits</literal></para>
-                <para> <literal>(8)</literal></para>
-              </entry>
-              <entry>
-                <para>Maximum number of concurrent sends that are outstanding to a single peer at a given time.</para>
-              </entry>
-            </row>
-            <row>
-              <entry>
-                <para> <literal>max_msg_size</literal></para>
-                <para> <literal>(512)</literal></para>
-              </entry>
-              <entry>
-                <para>Maximum immediate message size. This MUST be the same on all nodes in a cluster. A peer that connects with a different <literal>max_msg_size</literal> value will be rejected.</para>
-              </entry>
-            </row>
-          </tbody>
-        </tgroup>
-      </informaltable>
-    </section>
-    <section remap="h3">
       <title><indexterm><primary>configuring</primary><secondary>MX LND</secondary></indexterm>MX LND</title>
       <para><literal>MXLND</literal> supports a number of load-time parameters using Linux&apos;s module parameter system. The following variables are available:</para>
       <informaltable frame="all">
index 6035c7f..f83ca48 100644 (file)
@@ -198,7 +198,7 @@ lctl get_param mdt.*.nosquash_nids</screen>
            &lt;number&gt; &apos;-&apos; &lt;number&gt; &apos;/&apos; &lt;number&gt;
 &lt;net&gt;        :== &lt;netname&gt; | &lt;netname&gt;&lt;number&gt;
 &lt;netname&gt;    :== &quot;lo&quot; | &quot;tcp&quot; | &quot;o2ib&quot; | &quot;cib&quot; | &quot;openib&quot; | &quot;iib&quot; | 
-           &quot;vib&quot; | &quot;ra&quot; | &quot;elan&quot; | &quot;gm&quot; | &quot;mx&quot; | &quot;ptl&quot;
+           &quot;vib&quot; | &quot;ra&quot; | &quot;elan&quot; | &quot;gm&quot; | &quot;mx&quot;
 &lt;number&gt;     :== &lt;nonnegative decimal&gt; | &lt;hexadecimal&gt;</screen>
       <note>
         <para>For networks using numeric addresses (e.g. elan), the address range must be specified in the <literal>&lt;numaddr_range&gt;</literal> syntax. For networks using IP addresses, the address range must be in the <literal>&lt;ipaddr_range&gt;</literal>. For example, if elan is using numeric addresses, <literal>1.2.3.4@elan</literal> is incorrect.</para>
index 4dd940c..27a65b1 100644 (file)
         <para> TCP (any network carrying TCP traffic, including GigE, 10GigE, and IPoIB)</para>
       </listitem>
       <listitem>
-        <para> Cray: Seastar</para>
-      </listitem>
-      <listitem>
         <para> Myrinet: MX</para>
       </listitem>
       <listitem>