__ __ __ __ _____ _ _ _____ _ _ _ | \/ | \ \ / / | __ \ (_) | | / ____| | | | | | \ / |_ __\ V / | |__) | __ ___ ____ _| |_ ___ | (___ | |__ ___| | | | |\/| | '__|> < | ___/ '__| \ \ / / _` | __/ _ \ \___ \| '_ \ / _ \ | | | | | | |_ / . \ | | | | | |\ V / (_| | || __/ ____) | | | | __/ | | |_| |_|_(_)_/ \_\ |_| |_| |_| \_/ \__,_|\__\___| |_____/|_| |_|\___V 2.1 if you need WebShell for Seo everyday contact me on Telegram Telegram Address : @jackleetFor_More_Tools:
<!DOCTYPE html>
<html lang="en" data-content_root="../">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="viewport" content="width=device-width, initial-scale=1" />
<title>Network Function Representors — The Linux Kernel documentation</title>
<link rel="stylesheet" type="text/css" href="../_static/pygments.css?v=fa44fd50" />
<link rel="stylesheet" type="text/css" href="../_static/alabaster.css?v=3918102e" />
<script src="../_static/documentation_options.js?v=5929fcd5"></script>
<script src="../_static/doctools.js?v=9bcbadda"></script>
<script src="../_static/sphinx_highlight.js?v=dc90522c"></script>
<link rel="index" title="Index" href="../genindex.html" />
<link rel="search" title="Search" href="../search.html" />
<link rel="next" title="RxRPC Network Protocol" href="rxrpc.html" />
<link rel="prev" title="Linux wireless regulatory documentation" href="regulatory.html" />
<link rel="stylesheet" href="../_static/custom.css" type="text/css" />
</head><body>
<div class="document">
<div class="sphinxsidebar" role="navigation" aria-label="Main">
<div class="sphinxsidebarwrapper">
<p class="logo"><a href="../index.html">
<img class="logo" src="../_static/logo.svg" alt="Logo of The Linux Kernel"/>
</a></p>
<h1 class="logo"><a href="../index.html">The Linux Kernel</a></h1>
<p class="blurb">6.18.50</p>
<search id="searchbox" style="display: none" role="search">
<h3 id="searchlabel">Quick search</h3>
<div class="searchformwrapper">
<form class="search" action="../search.html" method="get">
<input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
<input type="submit" value="Go" />
</form>
</div>
</search>
<script>document.getElementById('searchbox').style.display = "block"</script>
<p>
<h3 class="kernel-toc-contents">Contents</h3>
<input type="checkbox" class="kernel-toc-toggle" id = "kernel-toc-toggle" checked>
<label class="kernel-toc-title" for="kernel-toc-toggle"></label>
<div class="kerneltoc" id="kerneltoc">
<ul>
<li class="toctree-l1"><a class="reference internal" href="../process/development-process.html">Development process</a></li>
<li class="toctree-l1"><a class="reference internal" href="../process/submitting-patches.html">Submitting patches</a></li>
<li class="toctree-l1"><a class="reference internal" href="../process/code-of-conduct.html">Code of conduct</a></li>
<li class="toctree-l1"><a class="reference internal" href="../maintainer/index.html">Maintainer handbook</a></li>
<li class="toctree-l1"><a class="reference internal" href="../process/index.html">All development-process docs</a></li>
</ul>
<ul class="current">
<li class="toctree-l1"><a class="reference internal" href="../core-api/index.html">Core API</a></li>
<li class="toctree-l1"><a class="reference internal" href="../driver-api/index.html">Driver APIs</a></li>
<li class="toctree-l1 current"><a class="reference internal" href="../subsystem-apis.html">Subsystems</a><ul class="current">
<li class="toctree-l2"><a class="reference internal" href="../subsystem-apis.html#core-subsystems">Core subsystems</a></li>
<li class="toctree-l2"><a class="reference internal" href="../subsystem-apis.html#human-interfaces">Human interfaces</a></li>
<li class="toctree-l2 current"><a class="reference internal" href="../subsystem-apis.html#networking-interfaces">Networking interfaces</a><ul class="current">
<li class="toctree-l3 current"><a class="reference internal" href="index.html">Networking</a></li>
<li class="toctree-l3"><a class="reference internal" href="../netlabel/index.html">NetLabel</a></li>
<li class="toctree-l3"><a class="reference internal" href="../infiniband/index.html">InfiniBand</a></li>
<li class="toctree-l3"><a class="reference internal" href="../isdn/index.html">ISDN</a></li>
<li class="toctree-l3"><a class="reference internal" href="../mhi/index.html">MHI</a></li>
</ul>
</li>
<li class="toctree-l2"><a class="reference internal" href="../subsystem-apis.html#storage-interfaces">Storage interfaces</a></li>
<li class="toctree-l2"><a class="reference internal" href="../subsystem-apis.html#other-subsystems">Other subsystems</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="../locking/index.html">Locking</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../process/license-rules.html">Licensing rules</a></li>
<li class="toctree-l1"><a class="reference internal" href="../doc-guide/index.html">Writing documentation</a></li>
<li class="toctree-l1"><a class="reference internal" href="../dev-tools/index.html">Development tools</a></li>
<li class="toctree-l1"><a class="reference internal" href="../dev-tools/testing-overview.html">Testing guide</a></li>
<li class="toctree-l1"><a class="reference internal" href="../kernel-hacking/index.html">Hacking guide</a></li>
<li class="toctree-l1"><a class="reference internal" href="../trace/index.html">Tracing</a></li>
<li class="toctree-l1"><a class="reference internal" href="../fault-injection/index.html">Fault injection</a></li>
<li class="toctree-l1"><a class="reference internal" href="../livepatch/index.html">Livepatching</a></li>
<li class="toctree-l1"><a class="reference internal" href="../rust/index.html">Rust</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../admin-guide/index.html">Administration</a></li>
<li class="toctree-l1"><a class="reference internal" href="../kbuild/index.html">Build system</a></li>
<li class="toctree-l1"><a class="reference internal" href="../admin-guide/reporting-issues.html">Reporting issues</a></li>
<li class="toctree-l1"><a class="reference internal" href="../tools/index.html">Userspace tools</a></li>
<li class="toctree-l1"><a class="reference internal" href="../userspace-api/index.html">Userspace API</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../firmware-guide/index.html">Firmware</a></li>
<li class="toctree-l1"><a class="reference internal" href="../devicetree/index.html">Firmware and Devicetree</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../arch/index.html">CPU architectures</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../staging/index.html">Unsorted documentation</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../translations/index.html">Translations</a></li>
</ul>
</div>
<script type="text/javascript"> <!--
var sbar = document.getElementsByClassName("sphinxsidebar")[0];
let currents = document.getElementsByClassName("current")
if (currents.length) {
sbar.scrollTop = currents[currents.length - 1].offsetTop;
}
--> </script>
<div role="note" aria-label="source link">
<h3>This Page</h3>
<ul class="this-page-menu">
<li><a href="../_sources/networking/representors.rst.txt"
rel="nofollow">Show Source</a></li>
</ul>
</div>
</div>
</div>
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<section id="network-function-representors">
<span id="representors"></span><h1>Network Function Representors<a class="headerlink" href="#network-function-representors" title="Link to this heading">¶</a></h1>
<p>This document describes the semantics and usage of representor netdevices, as
used to control internal switching on SmartNICs. For the closely-related port
representors on physical (multi-port) switches, see
<a class="reference internal" href="switchdev.html#switchdev"><span class="std std-ref">Documentation/networking/switchdev.rst</span></a>.</p>
<section id="motivation">
<h2>Motivation<a class="headerlink" href="#motivation" title="Link to this heading">¶</a></h2>
<p>Since the mid-2010s, network cards have started offering more complex
virtualisation capabilities than the legacy SR-IOV approach (with its simple
MAC/VLAN-based switching model) can support. This led to a desire to offload
software-defined networks (such as OpenVSwitch) to these NICs to specify the
network connectivity of each function. The resulting designs are variously
called SmartNICs or DPUs.</p>
<p>Network function representors bring the standard Linux networking stack to
virtual switches and IOV devices. Just as each physical port of a Linux-
controlled switch has a separate netdev, so does each virtual port of a virtual
switch.
When the system boots, and before any offload is configured, all packets from
the virtual functions appear in the networking stack of the PF via the
representors. The PF can thus always communicate freely with the virtual
functions.
The PF can configure standard Linux forwarding between representors, the uplink
or any other netdev (routing, bridging, TC classifiers).</p>
<p>Thus, a representor is both a control plane object (representing the function in
administrative commands) and a data plane object (one end of a virtual pipe).
As a virtual link endpoint, the representor can be configured like any other
netdevice; in some cases (e.g. link state) the representee will follow the
representor’s configuration, while in others there are separate APIs to
configure the representee.</p>
</section>
<section id="definitions">
<h2>Definitions<a class="headerlink" href="#definitions" title="Link to this heading">¶</a></h2>
<p>This document uses the term “switchdev function” to refer to the PCIe function
which has administrative control over the virtual switch on the device.
Typically, this will be a PF, but conceivably a NIC could be configured to grant
these administrative privileges instead to a VF or SF (subfunction).
Depending on NIC design, a multi-port NIC might have a single switchdev function
for the whole device or might have a separate virtual switch, and hence
switchdev function, for each physical network port.
If the NIC supports nested switching, there might be separate switchdev
functions for each nested switch, in which case each switchdev function should
only create representors for the ports on the (sub-)switch it directly
administers.</p>
<p>A “representee” is the object that a representor represents. So for example in
the case of a VF representor, the representee is the corresponding VF.</p>
</section>
<section id="what-does-a-representor-do">
<h2>What does a representor do?<a class="headerlink" href="#what-does-a-representor-do" title="Link to this heading">¶</a></h2>
<p>A representor has three main roles.</p>
<ol class="arabic simple">
<li><p>It is used to configure the network connection the representee sees, e.g.
link up/down, MTU, etc. For instance, bringing the representor
administratively UP should cause the representee to see a link up / carrier
on event.</p></li>
<li><p>It provides the slow path for traffic which does not hit any offloaded
fast-path rules in the virtual switch. Packets transmitted on the
representor netdevice should be delivered to the representee; packets
transmitted by the representee which fail to match any switching rule should
be received on the representor netdevice. (That is, there is a virtual pipe
connecting the representor to the representee, similar in concept to a veth
pair.)
This allows software switch implementations (such as OpenVSwitch or a Linux
bridge) to forward packets between representees and the rest of the network.</p></li>
<li><p>It acts as a handle by which switching rules (such as TC filters) can refer
to the representee, allowing these rules to be offloaded.</p></li>
</ol>
<p>The combination of 2) and 3) means that the behaviour (apart from performance)
should be the same whether a TC filter is offloaded or not. E.g. a TC rule
on a VF representor applies in software to packets received on that representor
netdevice, while in hardware offload it would apply to packets transmitted by
the representee VF. Conversely, a mirred egress redirect to a VF representor
corresponds in hardware to delivery directly to the representee VF.</p>
</section>
<section id="what-functions-should-have-a-representor">
<h2>What functions should have a representor?<a class="headerlink" href="#what-functions-should-have-a-representor" title="Link to this heading">¶</a></h2>
<p>Essentially, for each virtual port on the device’s internal switch, there
should be a representor.
Some vendors have chosen to omit representors for the uplink and the physical
network port, which can simplify usage (the uplink netdev becomes in effect the
physical port’s representor) but does not generalise to devices with multiple
ports or uplinks.</p>
<p>Thus, the following should all have representors:</p>
<blockquote>
<div><ul class="simple">
<li><p>VFs belonging to the switchdev function.</p></li>
<li><p>Other PFs on the local PCIe controller, and any VFs belonging to them.</p></li>
<li><p>PFs and VFs on external PCIe controllers on the device (e.g. for any embedded
System-on-Chip within the SmartNIC).</p></li>
<li><p>PFs and VFs with other personalities, including network block devices (such
as a vDPA virtio-blk PF backed by remote/distributed storage), if (and only
if) their network access is implemented through a virtual switch port. <a class="footnote-reference brackets" href="#id2" id="id1" role="doc-noteref"><span class="fn-bracket">[</span>1<span class="fn-bracket">]</span></a>
Note that such functions can require a representor despite the representee
not having a netdev.</p></li>
<li><p>Subfunctions (SFs) belonging to any of the above PFs or VFs, if they have
their own port on the switch (as opposed to using their parent PF’s port).</p></li>
<li><p>Any accelerators or plugins on the device whose interface to the network is
through a virtual switch port, even if they do not have a corresponding PCIe
PF or VF.</p></li>
</ul>
</div></blockquote>
<p>This allows the entire switching behaviour of the NIC to be controlled through
representor TC rules.</p>
<p>It is a common misunderstanding to conflate virtual ports with PCIe virtual
functions or their netdevs. While in simple cases there will be a 1:1
correspondence between VF netdevices and VF representors, more advanced device
configurations may not follow this.
A PCIe function which does not have network access through the internal switch
(not even indirectly through the hardware implementation of whatever services
the function provides) should <em>not</em> have a representor (even if it has a
netdev).
Such a function has no switch virtual port for the representor to configure or
to be the other end of the virtual pipe.
The representor represents the virtual port, not the PCIe function nor the ‘end
user’ netdevice.</p>
<aside class="footnote-list brackets">
<aside class="footnote brackets" id="id2" role="doc-footnote">
<span class="label"><span class="fn-bracket">[</span><a role="doc-backlink" href="#id1">1</a><span class="fn-bracket">]</span></span>
<p>The concept here is that a hardware IP stack in the device performs the
translation between block DMA requests and network packets, so that only
network packets pass through the virtual port onto the switch. The network
access that the IP stack “sees” would then be configurable through tc rules;
e.g. its traffic might all be wrapped in a specific VLAN or VxLAN. However,
any needed configuration of the block device <em>qua</em> block device, not being a
networking entity, would not be appropriate for the representor and would
thus use some other channel such as devlink.
Contrast this with the case of a virtio-blk implementation which forwards the
DMA requests unchanged to another PF whose driver then initiates and
terminates IP traffic in software; in that case the DMA traffic would <em>not</em>
run over the virtual switch and the virtio-blk PF should thus <em>not</em> have a
representor.</p>
</aside>
</aside>
</section>
<section id="how-are-representors-created">
<h2>How are representors created?<a class="headerlink" href="#how-are-representors-created" title="Link to this heading">¶</a></h2>
<p>The driver instance attached to the switchdev function should, for each virtual
port on the switch, create a pure-software netdevice which has some form of
in-kernel reference to the switchdev function’s own netdevice or driver private
data (<code class="docutils literal notranslate"><span class="pre">netdev_priv()</span></code>).
This may be by enumerating ports at probe time, reacting dynamically to the
creation and destruction of ports at run time, or a combination of the two.</p>
<p>The operations of the representor netdevice will generally involve acting
through the switchdev function. For example, <code class="docutils literal notranslate"><span class="pre">ndo_start_xmit()</span></code> might send
the packet through a hardware TX queue attached to the switchdev function, with
either packet metadata or queue configuration marking it for delivery to the
representee.</p>
</section>
<section id="how-are-representors-identified">
<h2>How are representors identified?<a class="headerlink" href="#how-are-representors-identified" title="Link to this heading">¶</a></h2>
<p>The representor netdevice should <em>not</em> directly refer to a PCIe device (e.g.
through <code class="docutils literal notranslate"><span class="pre">net_dev->dev.parent</span></code> / <code class="docutils literal notranslate"><span class="pre">SET_NETDEV_DEV()</span></code>), either of the
representee or of the switchdev function.
Instead, the driver should use the <code class="docutils literal notranslate"><span class="pre">SET_NETDEV_DEVLINK_PORT</span></code> macro to
assign a devlink port instance to the netdevice before registering the
netdevice; the kernel uses the devlink port to provide the <code class="docutils literal notranslate"><span class="pre">phys_switch_id</span></code>
and <code class="docutils literal notranslate"><span class="pre">phys_port_name</span></code> sysfs nodes.
(Some legacy drivers implement <code class="docutils literal notranslate"><span class="pre">ndo_get_port_parent_id()</span></code> and
<code class="docutils literal notranslate"><span class="pre">ndo_get_phys_port_name()</span></code> directly, but this is deprecated.) See
<a class="reference internal" href="devlink/devlink-port.html#devlink-port"><span class="std std-ref">Documentation/networking/devlink/devlink-port.rst</span></a> for the
details of this API.</p>
<p>It is expected that userland will use this information (e.g. through udev rules)
to construct an appropriately informative name or alias for the netdevice. For
instance if the switchdev function is <code class="docutils literal notranslate"><span class="pre">eth4</span></code> then a representor with a
<code class="docutils literal notranslate"><span class="pre">phys_port_name</span></code> of <code class="docutils literal notranslate"><span class="pre">p0pf1vf2</span></code> might be renamed <code class="docutils literal notranslate"><span class="pre">eth4pf1vf2rep</span></code>.</p>
<p>There are as yet no established conventions for naming representors which do not
correspond to PCIe functions (e.g. accelerators and plugins).</p>
</section>
<section id="how-do-representors-interact-with-tc-rules">
<h2>How do representors interact with TC rules?<a class="headerlink" href="#how-do-representors-interact-with-tc-rules" title="Link to this heading">¶</a></h2>
<p>Any TC rule on a representor applies (in software TC) to packets received by
that representor netdevice. Thus, if the delivery part of the rule corresponds
to another port on the virtual switch, the driver may choose to offload it to
hardware, applying it to packets transmitted by the representee.</p>
<p>Similarly, since a TC mirred egress action targeting the representor would (in
software) send the packet through the representor (and thus indirectly deliver
it to the representee), hardware offload should interpret this as delivery to
the representee.</p>
<p>As a simple example, if <code class="docutils literal notranslate"><span class="pre">PORT_DEV</span></code> is the physical port representor and
<code class="docutils literal notranslate"><span class="pre">REP_DEV</span></code> is a VF representor, the following rules:</p>
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>tc filter add dev $REP_DEV parent ffff: protocol ipv4 flower \
action mirred egress redirect dev $PORT_DEV
tc filter add dev $PORT_DEV parent ffff: protocol ipv4 flower skip_sw \
action mirred egress mirror dev $REP_DEV
</pre></div>
</div>
<p>would mean that all IPv4 packets from the VF are sent out the physical port, and
all IPv4 packets received on the physical port are delivered to the VF in
addition to <code class="docutils literal notranslate"><span class="pre">PORT_DEV</span></code>. (Note that without <code class="docutils literal notranslate"><span class="pre">skip_sw</span></code> on the second rule,
the VF would get two copies, as the packet reception on <code class="docutils literal notranslate"><span class="pre">PORT_DEV</span></code> would
trigger the TC rule again and mirror the packet to <code class="docutils literal notranslate"><span class="pre">REP_DEV</span></code>.)</p>
<p>On devices without separate port and uplink representors, <code class="docutils literal notranslate"><span class="pre">PORT_DEV</span></code> would
instead be the switchdev function’s own uplink netdevice.</p>
<p>Of course the rules can (if supported by the NIC) include packet-modifying
actions (e.g. VLAN push/pop), which should be performed by the virtual switch.</p>
<p>Tunnel encapsulation and decapsulation are rather more complicated, as they
involve a third netdevice (a tunnel netdev operating in metadata mode, such as
a VxLAN device created with <code class="docutils literal notranslate"><span class="pre">ip</span> <span class="pre">link</span> <span class="pre">add</span> <span class="pre">vxlan0</span> <span class="pre">type</span> <span class="pre">vxlan</span> <span class="pre">external</span></code>) and
require an IP address to be bound to the underlay device (e.g. switchdev
function uplink netdev or port representor). TC rules such as:</p>
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>tc filter add dev $REP_DEV parent ffff: flower \
action tunnel_key set id $VNI src_ip $LOCAL_IP dst_ip $REMOTE_IP \
dst_port 4789 \
action mirred egress redirect dev vxlan0
tc filter add dev vxlan0 parent ffff: flower enc_src_ip $REMOTE_IP \
enc_dst_ip $LOCAL_IP enc_key_id $VNI enc_dst_port 4789 \
action tunnel_key unset action mirred egress redirect dev $REP_DEV
</pre></div>
</div>
<p>where <code class="docutils literal notranslate"><span class="pre">LOCAL_IP</span></code> is an IP address bound to <code class="docutils literal notranslate"><span class="pre">PORT_DEV</span></code>, and <code class="docutils literal notranslate"><span class="pre">REMOTE_IP</span></code> is
another IP address on the same subnet, mean that packets sent by the VF should
be VxLAN encapsulated and sent out the physical port (the driver has to deduce
this by a route lookup of <code class="docutils literal notranslate"><span class="pre">LOCAL_IP</span></code> leading to <code class="docutils literal notranslate"><span class="pre">PORT_DEV</span></code>, and also
perform an ARP/neighbour table lookup to find the MAC addresses to use in the
outer Ethernet frame), while UDP packets received on the physical port with UDP
port 4789 should be parsed as VxLAN and, if their VSID matches <code class="docutils literal notranslate"><span class="pre">$VNI</span></code>,
decapsulated and forwarded to the VF.</p>
<p>If this all seems complicated, just remember the ‘golden rule’ of TC offload:
the hardware should ensure the same final results as if the packets were
processed through the slow path, traversed software TC (except ignoring any
<code class="docutils literal notranslate"><span class="pre">skip_hw</span></code> rules and applying any <code class="docutils literal notranslate"><span class="pre">skip_sw</span></code> rules) and were transmitted or
received through the representor netdevices.</p>
</section>
<section id="configuring-the-representee-s-mac">
<h2>Configuring the representee’s MAC<a class="headerlink" href="#configuring-the-representee-s-mac" title="Link to this heading">¶</a></h2>
<p>The representee’s link state is controlled through the representor. Setting the
representor administratively UP or DOWN should cause carrier ON or OFF at the
representee.</p>
<p>Setting an MTU on the representor should cause that same MTU to be reported to
the representee.
(On hardware that allows configuring separate and distinct MTU and MRU values,
the representor MTU should correspond to the representee’s MRU and vice-versa.)</p>
<p>Currently there is no way to use the representor to set the station permanent
MAC address of the representee; other methods available to do this include:</p>
<blockquote>
<div><ul class="simple">
<li><p>legacy SR-IOV (<code class="docutils literal notranslate"><span class="pre">ip</span> <span class="pre">link</span> <span class="pre">set</span> <span class="pre">DEVICE</span> <span class="pre">vf</span> <span class="pre">NUM</span> <span class="pre">mac</span> <span class="pre">LLADDR</span></code>)</p></li>
<li><p>devlink port function (see <strong>devlink-port(8)</strong> and
<a class="reference internal" href="devlink/devlink-port.html#devlink-port"><span class="std std-ref">Documentation/networking/devlink/devlink-port.rst</span></a>)</p></li>
</ul>
</div></blockquote>
</section>
</section>
</div>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="footer">
©The kernel development community.
|
Powered by <a href="https://www.sphinx-doc.org/">Sphinx 8.1.3</a>
& <a href="https://alabaster.readthedocs.io">Alabaster 0.7.16</a>
|
<a href="../_sources/networking/representors.rst.txt"
rel="nofollow">Page source</a>
</div>
</body>
</html>| Name | Type | Size | Permission | Actions |
|---|---|---|---|---|
| caif | Folder | 0755 |
|
|
| device_drivers | Folder | 0755 |
|
|
| devlink | Folder | 0755 |
|
|
| diagnostic | Folder | 0755 |
|
|
| dsa | Folder | 0755 |
|
|
| mac80211_hwsim | Folder | 0755 |
|
|
| net_cachelines | Folder | 0755 |
|
|
| pse-pd | Folder | 0755 |
|
|
| 6lowpan.html | File | 9.97 KB | 0644 |
|
| 6pack.html | File | 18.06 KB | 0644 |
|
| af_xdp.html | File | 71.08 KB | 0644 |
|
| alias.html | File | 9.71 KB | 0644 |
|
| arcnet-hardware.html | File | 153.3 KB | 0644 |
|
| arcnet.html | File | 37.48 KB | 0644 |
|
| atm.html | File | 8.24 KB | 0644 |
|
| ax25.html | File | 8.75 KB | 0644 |
|
| bareudp.html | File | 10.56 KB | 0644 |
|
| batman-adv.html | File | 16.81 KB | 0644 |
|
| bonding.html | File | 140.89 KB | 0644 |
|
| bridge.html | File | 53.36 KB | 0644 |
|
| can.html | File | 120.11 KB | 0644 |
|
| can_ucan_protocol.html | File | 25.27 KB | 0644 |
|
| cdc_mbim.html | File | 25.28 KB | 0644 |
|
| checksum-offloads.html | File | 16.15 KB | 0644 |
|
| dctcp.html | File | 10.32 KB | 0644 |
|
| devmem.html | File | 24.33 KB | 0644 |
|
| dns_resolver.html | File | 15.11 KB | 0644 |
|
| driver.html | File | 20.41 KB | 0644 |
|
| eql.html | File | 31.48 KB | 0644 |
|
| ethtool-netlink.html | File | 274 KB | 0644 |
|
| failover.html | File | 8.43 KB | 0644 |
|
| fib_trie.html | File | 16.04 KB | 0644 |
|
| filter.html | File | 42.43 KB | 0644 |
|
| gen_stats.html | File | 14.2 KB | 0644 |
|
| generic-hdlc.html | File | 14.67 KB | 0644 |
|
| generic_netlink.html | File | 8.11 KB | 0644 |
|
| gtp.html | File | 20.55 KB | 0644 |
|
| ieee802154.html | File | 25.03 KB | 0644 |
|
| ila.html | File | 21.79 KB | 0644 |
|
| index.html | File | 108.18 KB | 0644 |
|
| ioam6-sysctl.html | File | 8.48 KB | 0644 |
|
| iou-zcrx.html | File | 16.63 KB | 0644 |
|
| ip-sysctl.html | File | 154.81 KB | 0644 |
|
| ip_dynaddr.html | File | 9.97 KB | 0644 |
|
| ipsec.html | File | 9.71 KB | 0644 |
|
| ipv6.html | File | 9.87 KB | 0644 |
|
| ipvlan.html | File | 16.87 KB | 0644 |
|
| ipvs-sysctl.html | File | 20.73 KB | 0644 |
|
| iso15765-2.html | File | 39.91 KB | 0644 |
|
| j1939.html | File | 99.33 KB | 0644 |
|
| kapi.html | File | 1.78 MB | 0644 |
|
| kcm.html | File | 21.67 KB | 0644 |
|
| l2tp.html | File | 47.74 KB | 0644 |
|
| lapb-module.html | File | 22.56 KB | 0644 |
|
| mac80211-injection.html | File | 12.37 KB | 0644 |
|
| mctp.html | File | 35.16 KB | 0644 |
|
| mpls-sysctl.html | File | 9.64 KB | 0644 |
|
| mptcp-sysctl.html | File | 13.33 KB | 0644 |
|
| mptcp.html | File | 19.74 KB | 0644 |
|
| msg_zerocopy.html | File | 19.72 KB | 0644 |
|
| multi-pf-netdev.html | File | 17.48 KB | 0644 |
|
| multiqueue.html | File | 13.21 KB | 0644 |
|
| napi.html | File | 43.36 KB | 0644 |
|
| net_dim.html | File | 76.45 KB | 0644 |
|
| net_failover.html | File | 16.3 KB | 0644 |
|
| netconsole.html | File | 31.44 KB | 0644 |
|
| netdev-features.html | File | 17.75 KB | 0644 |
|
| netdevices.html | File | 43.33 KB | 0644 |
|
| netfilter-sysctl.html | File | 8.43 KB | 0644 |
|
| netif-msg.html | File | 12.93 KB | 0644 |
|
| netmem.html | File | 14.84 KB | 0644 |
|
| nexthop-group-resilient.html | File | 24.56 KB | 0644 |
|
| nf_conntrack-sysctl.html | File | 15.77 KB | 0644 |
|
| nf_flowtable.html | File | 21.24 KB | 0644 |
|
| nfc.html | File | 13.73 KB | 0644 |
|
| oa-tc6-framework.html | File | 39.07 KB | 0644 |
|
| openvswitch.html | File | 21.15 KB | 0644 |
|
| operstates.html | File | 18.28 KB | 0644 |
|
| packet_mmap.html | File | 55.34 KB | 0644 |
|
| page_pool.html | File | 59.25 KB | 0644 |
|
| phonet.html | File | 16.92 KB | 0644 |
|
| phy-link-topology.html | File | 15.77 KB | 0644 |
|
| phy.html | File | 40.5 KB | 0644 |
|
| pktgen.html | File | 24.97 KB | 0644 |
|
| plip.html | File | 18.56 KB | 0644 |
|
| ppp_generic.html | File | 37.23 KB | 0644 |
|
| proc_net_tcp.html | File | 11.13 KB | 0644 |
|
| psp.html | File | 18.66 KB | 0644 |
|
| radiotap-headers.html | File | 14.73 KB | 0644 |
|
| rds.html | File | 29.39 KB | 0644 |
|
| regulatory.html | File | 18.44 KB | 0644 |
|
| representors.html | File | 25.79 KB | 0644 |
|
| rxrpc.html | File | 130.88 KB | 0644 |
|
| scaling.html | File | 40.25 KB | 0644 |
|
| sctp.html | File | 9.73 KB | 0644 |
|
| secid.html | File | 8.42 KB | 0644 |
|
| seg6-sysctl.html | File | 9.53 KB | 0644 |
|
| segmentation-offloads.html | File | 17.81 KB | 0644 |
|
| sfp-phylink.html | File | 41.09 KB | 0644 |
|
| skbuff.html | File | 29.22 KB | 0644 |
|
| smc-sysctl.html | File | 10.42 KB | 0644 |
|
| snmp_counter.html | File | 91.51 KB | 0644 |
|
| sriov.html | File | 9.46 KB | 0644 |
|
| statistics.html | File | 31.78 KB | 0644 |
|
| strparser.html | File | 19.15 KB | 0644 |
|
| switchdev.html | File | 39.55 KB | 0644 |
|
| sysfs-tagging.html | File | 10.95 KB | 0644 |
|
| tc-actions-env-rules.html | File | 8.87 KB | 0644 |
|
| tc-queue-filters.html | File | 9.33 KB | 0644 |
|
| tcp-thin.html | File | 10.33 KB | 0644 |
|
| tcp_ao.html | File | 35.85 KB | 0644 |
|
| team.html | File | 7.93 KB | 0644 |
|
| timestamping.html | File | 59.83 KB | 0644 |
|
| tipc.html | File | 384.61 KB | 0644 |
|
| tls-handshake.html | File | 21.18 KB | 0644 |
|
| tls-offload.html | File | 42.72 KB | 0644 |
|
| tls.html | File | 39.38 KB | 0644 |
|
| tproxy.html | File | 13.18 KB | 0644 |
|
| tuntap.html | File | 19 KB | 0644 |
|
| udplite.html | File | 23.04 KB | 0644 |
|
| vrf.html | File | 28.46 KB | 0644 |
|
| vxlan.html | File | 11.95 KB | 0644 |
|
| x25-iface.html | File | 10.9 KB | 0644 |
|
| x25.html | File | 10.07 KB | 0644 |
|
| xdp-rx-metadata.html | File | 27.46 KB | 0644 |
|
| xfrm_device.html | File | 19.14 KB | 0644 |
|
| xfrm_proc.html | File | 11.37 KB | 0644 |
|
| xfrm_sync.html | File | 15.85 KB | 0644 |
|
| xfrm_sysctl.html | File | 8.07 KB | 0644 |
|
| xsk-tx-metadata.html | File | 18.64 KB | 0644 |
|