2 files changed, 43 insertions, 1 deletions

diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index 7373115407e4..c97932c88ea3 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -26,12 +26,36 @@ ip_no_pmtu_disc - INTEGER
         discarded. Outgoing frames are handled the same as in mode 1,
         implicitly setting IP_PMTUDISC_DONT on every created socket.
 
-        Possible values: 0-2
+        Mode 3 is a hardend pmtu discover mode. The kernel will only
+        accept fragmentation-needed errors if the underlying protocol
+        can verify them besides a plain socket lookup. Current
+        protocols for which pmtu events will be honored are TCP, SCTP
+        and DCCP as they verify e.g. the sequence number or the
+        association. This mode should not be enabled globally but is
+        only intended to secure e.g. name servers in namespaces where
+        TCP path mtu must still work but path MTU information of other
+        protocols should be discarded. If enabled globally this mode
+        could break other protocols.
+
+        Possible values: 0-3
         Default: FALSE
 
 min_pmtu - INTEGER
         default 552 - minimum discovered Path MTU
 
+ip_forward_use_pmtu - BOOLEAN
+        By default we don't trust protocol path MTUs while forwarding
+        because they could be easily forged and can lead to unwanted
+        fragmentation by the router.
+        You only need to enable this if you have user-space software
+        which tries to discover path mtus by itself and depends on the
+        kernel honoring this information. This is normally not the
+        case.
+        Default: 0 (disabled)
+        Possible values:
+        0 - disabled
+        1 - enabled
+
 route/max_size - INTEGER
         Maximum number of routes allowed in the kernel.  Increase
         this when using large numbers of interfaces and/or routes.
diff --git a/Documentation/networking/packet_mmap.txt b/Documentation/networking/packet_mmap.txt
index 723bf3d33a6e..91ffe1d9e8ca 100644
--- a/Documentation/networking/packet_mmap.txt
+++ b/Documentation/networking/packet_mmap.txt
@@ -98,6 +98,11 @@ by the kernel.
 The destruction of the socket and all associated resources
 is done by a simple call to close(fd).
 
+Similarly as without PACKET_MMAP, it is possible to use one socket
+for capture and transmission. This can be done by mapping the
+allocated RX and TX buffer ring with a single mmap() call.
+See "Mapping and use of the circular buffer (ring)".
+
 Next I will describe PACKET_MMAP settings and its constraints,
 also the mapping of the circular buffer in the user process and 
 the use of this buffer.
@@ -414,6 +419,19 @@ tp_block_size/tp_frame_size frames there will be a gap between
 the frames. This is because a frame cannot be spawn across two
 blocks. 
 
+To use one socket for capture and transmission, the mapping of both the
+RX and TX buffer ring has to be done with one call to mmap:
+
+    ...
+    setsockopt(fd, SOL_PACKET, PACKET_RX_RING, &foo, sizeof(foo));
+    setsockopt(fd, SOL_PACKET, PACKET_TX_RING, &bar, sizeof(bar));
+    ...
+    rx_ring = mmap(0, size * 2, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
+    tx_ring = rx_ring + size;
+
+RX must be the first as the kernel maps the TX ring memory right
+after the RX one.
+
 At the beginning of each frame there is an status field (see 
 struct tpacket_hdr). If this field is 0 means that the frame is ready
 to be used for the kernel, If not, there is a frame the user can read