docs: networking: fix minor typos in various documentation files
This patch fixes some typos/misspelling errors in the Documentation/networking files. Signed-off-by: Olivier Gayot <olivier.gayot@sigexec.com> Signed-off-by: David S. Miller <davem@davemloft.net>
This commit is contained in:
parent
f396922d86
commit
bb38ccce88
8 changed files with 16 additions and 16 deletions
|
@ -24,10 +24,10 @@ enum lowpan_lltypes.
|
|||
|
||||
Example to evaluate the private usually you can do:
|
||||
|
||||
static inline sturct lowpan_priv_foobar *
|
||||
static inline struct lowpan_priv_foobar *
|
||||
lowpan_foobar_priv(struct net_device *dev)
|
||||
{
|
||||
return (sturct lowpan_priv_foobar *)lowpan_priv(dev)->priv;
|
||||
return (struct lowpan_priv_foobar *)lowpan_priv(dev)->priv;
|
||||
}
|
||||
|
||||
switch (dev->type) {
|
||||
|
|
|
@ -67,7 +67,7 @@ Don't be confused by terminology: The GTP User Plane goes through
|
|||
kernel accelerated path, while the GTP Control Plane goes to
|
||||
Userspace :)
|
||||
|
||||
The official homepge of the module is at
|
||||
The official homepage of the module is at
|
||||
https://osmocom.org/projects/linux-kernel-gtp-u/wiki
|
||||
|
||||
== Userspace Programs with Linux Kernel GTP-U support ==
|
||||
|
@ -120,7 +120,7 @@ If yo have questions regarding how to use the Kernel GTP module from
|
|||
your own software, or want to contribute to the code, please use the
|
||||
osmocom-net-grps mailing list for related discussion. The list can be
|
||||
reached at osmocom-net-gprs@lists.osmocom.org and the mailman
|
||||
interface for managign your subscription is at
|
||||
interface for managing your subscription is at
|
||||
https://lists.osmocom.org/mailman/listinfo/osmocom-net-gprs
|
||||
|
||||
== Issue Tracker ==
|
||||
|
|
|
@ -121,7 +121,7 @@ three options to deal with this:
|
|||
|
||||
- checksum neutral mapping
|
||||
When an address is translated the difference can be offset
|
||||
elsewhere in a part of the packet that is covered by the
|
||||
elsewhere in a part of the packet that is covered by
|
||||
the checksum. The low order sixteen bits of the identifier
|
||||
are used. This method is preferred since it doesn't require
|
||||
parsing a packet beyond the IP header and in most cases the
|
||||
|
|
|
@ -26,7 +26,7 @@ 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.
|
||||
|
||||
Mode 3 is a hardend pmtu discover mode. The kernel will only
|
||||
Mode 3 is a hardened 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
|
||||
|
|
|
@ -25,8 +25,8 @@ Quote from RFC3173:
|
|||
is implementation dependent.
|
||||
|
||||
Current IPComp implementation is indeed by the book, while as in practice
|
||||
when sending non-compressed packet to the peer(whether or not packet len
|
||||
is smaller than the threshold or the compressed len is large than original
|
||||
when sending non-compressed packet to the peer (whether or not packet len
|
||||
is smaller than the threshold or the compressed len is larger than original
|
||||
packet len), the packet is dropped when checking the policy as this packet
|
||||
matches the selector but not coming from any XFRM layer, i.e., with no
|
||||
security path. Such naked packet will not eventually make it to upper layer.
|
||||
|
|
|
@ -73,11 +73,11 @@ mode to make conn-tracking work.
|
|||
This is the default option. To configure the IPvlan port in this mode,
|
||||
user can choose to either add this option on the command-line or don't specify
|
||||
anything. This is the traditional mode where slaves can cross-talk among
|
||||
themseleves apart from talking through the master device.
|
||||
themselves apart from talking through the master device.
|
||||
|
||||
5.2 private:
|
||||
If this option is added to the command-line, the port is set in private
|
||||
mode. i.e. port wont allow cross communication between slaves.
|
||||
mode. i.e. port won't allow cross communication between slaves.
|
||||
|
||||
5.3 vepa:
|
||||
If this is added to the command-line, the port is set in VEPA mode.
|
||||
|
|
|
@ -1,4 +1,4 @@
|
|||
Kernel Connection Mulitplexor
|
||||
Kernel Connection Multiplexor
|
||||
-----------------------------
|
||||
|
||||
Kernel Connection Multiplexor (KCM) is a mechanism that provides a message based
|
||||
|
@ -31,7 +31,7 @@ KCM implements an NxM multiplexor in the kernel as diagrammed below:
|
|||
KCM sockets
|
||||
-----------
|
||||
|
||||
The KCM sockets provide the user interface to the muliplexor. All the KCM sockets
|
||||
The KCM sockets provide the user interface to the multiplexor. All the KCM sockets
|
||||
bound to a multiplexor are considered to have equivalent function, and I/O
|
||||
operations in different sockets may be done in parallel without the need for
|
||||
synchronization between threads in userspace.
|
||||
|
@ -199,7 +199,7 @@ while. Example use:
|
|||
BFP programs for message delineation
|
||||
------------------------------------
|
||||
|
||||
BPF programs can be compiled using the BPF LLVM backend. For exmple,
|
||||
BPF programs can be compiled using the BPF LLVM backend. For example,
|
||||
the BPF program for parsing Thrift is:
|
||||
|
||||
#include "bpf.h" /* for __sk_buff */
|
||||
|
@ -222,7 +222,7 @@ messages. The kernel provides necessary assurances that messages are sent
|
|||
and received atomically. This relieves much of the burden applications have
|
||||
in mapping a message based protocol onto the TCP stream. KCM also make
|
||||
application layer messages a unit of work in the kernel for the purposes of
|
||||
steerng and scheduling, which in turn allows a simpler networking model in
|
||||
steering and scheduling, which in turn allows a simpler networking model in
|
||||
multithreaded applications.
|
||||
|
||||
Configurations
|
||||
|
@ -272,7 +272,7 @@ on the socket thus waking up the application thread. When the application
|
|||
sees the error (which may just be a disconnect) it should unattach the
|
||||
socket from KCM and then close it. It is assumed that once an error is
|
||||
posted on the TCP socket the data stream is unrecoverable (i.e. an error
|
||||
may have occurred in the middle of receiving a messssge).
|
||||
may have occurred in the middle of receiving a message).
|
||||
|
||||
TCP connection monitoring
|
||||
-------------------------
|
||||
|
|
|
@ -156,7 +156,7 @@ nf_conntrack_timestamp - BOOLEAN
|
|||
nf_conntrack_udp_timeout - INTEGER (seconds)
|
||||
default 30
|
||||
|
||||
nf_conntrack_udp_timeout_stream2 - INTEGER (seconds)
|
||||
nf_conntrack_udp_timeout_stream - INTEGER (seconds)
|
||||
default 180
|
||||
|
||||
This extended timeout will be used in case there is an UDP stream
|
||||
|
|
Loading…
Reference in a new issue