lastdragon/linux-kernel
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Resguardo inicial

Browse Source
This commit is contained in:
lastdragon
2026-09-06 12:53:21 -06:00
parent 662efe3c2a
commit ad2088d178
94853 changed files with 43200404 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
linux-7.2.3/Documentation/networking/device_drivers/atm/cxacru-cf.py
+48
View File
@@ -0,0 +1,48 @@
#!/usr/bin/env python
# Copyright 2009 Simon Arlott
#
# This program is free software; you can redistribute it and/or modify it
# under the terms of the GNU General Public License as published by the Free
# Software Foundation; either version 2 of the License, or (at your option)
# any later version.
#
# This program is distributed in the hope that it will be useful, but WITHOUT
# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
# more details.
#
# You should have received a copy of the GNU General Public License along with
# this program; if not, write to the Free Software Foundation, Inc., 59
# Temple Place - Suite 330, Boston, MA 02111-1307, USA.
#
# Usage: cxacru-cf.py < cxacru-cf.bin
# Output: values string suitable for the sysfs adsl_config attribute
#
# Warning: cxacru-cf.bin with MD5 hash cdbac2689969d5ed5d4850f117702110
# contains mis-aligned values which will stop the modem from being able
# to make a connection. If the first and last two bytes are removed then
# the values become valid, but the modulation will be forced to ANSI
# T1.413 only which may not be appropriate.
#
# The original binary format is a packed list of le32 values.
import sys
import struct
i = 0
while True:
buf = sys.stdin.read(4)
if len(buf) == 0:
break
elif len(buf) != 4:
sys.stdout.write("\n")
sys.stderr.write("Error: read {0} not 4 bytes\n".format(len(buf)))
sys.exit(1)
if i > 0:
sys.stdout.write(" ")
sys.stdout.write("{0:x}={1}".format(i, struct.unpack("<I", buf)[0]))
i += 1
sys.stdout.write("\n")
linux-7.2.3/Documentation/networking/device_drivers/atm/cxacru.rst
+120
View File
@@ -0,0 +1,120 @@
.. SPDX-License-Identifier: GPL-2.0
========================
ATM cxacru device driver
========================
Firmware is required for this device: http://accessrunner.sourceforge.net/
While it is capable of managing/maintaining the ADSL connection without the
module loaded, the device will sometimes stop responding after unloading the
driver and it is necessary to unplug/remove power to the device to fix this.
Note: support for cxacru-cf.bin has been removed. It was not loaded correctly
so it had no effect on the device configuration. Fixing it could have stopped
existing devices working when an invalid configuration is supplied.
There is a script cxacru-cf.py to convert an existing file to the sysfs form.
Detected devices will appear as ATM devices named "cxacru". In /sys/class/atm/
these are directories named cxacruN where N is the device number. A symlink
named device points to the USB interface device's directory which contains
several sysfs attribute files for retrieving device statistics:
* adsl_controller_version
* adsl_headend
* adsl_headend_environment
- Information about the remote headend.
* adsl_config
- Configuration writing interface.
- Write parameters in hexadecimal format <index>=<value>,
separated by whitespace, e.g.:
"1=0 a=5"
- Up to 7 parameters at a time will be sent and the modem will restart
the ADSL connection when any value is set. These are logged for future
reference.
* downstream_attenuation (dB)
* downstream_bits_per_frame
* downstream_rate (kbps)
* downstream_snr_margin (dB)
- Downstream stats.
* upstream_attenuation (dB)
* upstream_bits_per_frame
* upstream_rate (kbps)
* upstream_snr_margin (dB)
* transmitter_power (dBm/Hz)
- Upstream stats.
* downstream_crc_errors
* downstream_fec_errors
* downstream_hec_errors
* upstream_crc_errors
* upstream_fec_errors
* upstream_hec_errors
- Error counts.
* line_startable
- Indicates that ADSL support on the device
is/can be enabled, see adsl_start.
* line_status
- "initialising"
- "down"
- "attempting to activate"
- "training"
- "channel analysis"
- "exchange"
- "waiting"
- "up"
Changes between "down" and "attempting to activate"
if there is no signal.
* link_status
- "not connected"
- "connected"
- "lost"
* mac_address
* modulation
- "" (when not connected)
- "ANSI T1.413"
- "ITU-T G.992.1 (G.DMT)"
- "ITU-T G.992.2 (G.LITE)"
* startup_attempts
- Count of total attempts to initialise ADSL.
To enable/disable ADSL, the following can be written to the adsl_state file:
- "start"
- "stop
- "restart" (stops, waits 1.5s, then starts)
- "poll" (used to resume status polling if it was disabled due to failure)
Changes in adsl/line state are reported via kernel log messages::
[4942145.150704] ATM dev 0: ADSL state: running
[4942243.663766] ATM dev 0: ADSL line: down
[4942249.665075] ATM dev 0: ADSL line: attempting to activate
[4942253.654954] ATM dev 0: ADSL line: training
[4942255.666387] ATM dev 0: ADSL line: channel analysis
[4942259.656262] ATM dev 0: ADSL line: exchange
[2635357.696901] ATM dev 0: ADSL line: up (8128 kb/s down | 832 kb/s up)
linux-7.2.3/Documentation/networking/device_drivers/atm/index.rst
+11
View File
@@ -0,0 +1,11 @@
.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
Asynchronous Transfer Mode (ATM) Device Drivers
===============================================
Contents:
.. toctree::
:maxdepth: 2
cxacru
linux-7.2.3/Documentation/networking/device_drivers/can/can327.rst
+331
View File
@@ -0,0 +1,331 @@
.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-3-Clause)
can327: ELM327 driver for Linux SocketCAN
==========================================
Authors
--------
Max Staudt <max@enpas.org>
Motivation
-----------
This driver aims to lower the initial cost for hackers interested in
working with CAN buses.
CAN adapters are expensive, few, and far between.
ELM327 interfaces are cheap and plentiful.
Let's use ELM327s as CAN adapters.
Introduction
-------------
This driver is an effort to turn abundant ELM327 based OBD interfaces
into full fledged (as far as possible) CAN interfaces.
Since the ELM327 was never meant to be a stand alone CAN controller,
the driver has to switch between its modes as quickly as possible in
order to fake full-duplex operation.
As such, can327 is a best effort driver. However, this is more than
enough to implement simple request-response protocols (such as OBD II),
and to monitor broadcast messages on a bus (such as in a vehicle).
Most ELM327s come as nondescript serial devices, attached via USB or
Bluetooth. The driver cannot recognize them by itself, and as such it
is up to the user to attach it in form of a TTY line discipline
(similar to PPP, SLIP, slcan, ...).
This driver is meant for ELM327 versions 1.4b and up, see below for
known limitations in older controllers and clones.
Data sheet
-----------
The official data sheets can be found at ELM electronics' home page:
https://www.elmelectronics.com/
How to attach the line discipline
----------------------------------
Every ELM327 chip is factory programmed to operate at a serial setting
of 38400 baud/s, 8 data bits, no parity, 1 stopbit.
If you have kept this default configuration, the line discipline can
be attached on a command prompt as follows::
sudo ldattach \
--debug \
--speed 38400 \
--eightbits \
--noparity \
--onestopbit \
--iflag -ICRNL,INLCR,-IXOFF \
30 \
/dev/ttyUSB0
To change the ELM327's serial settings, please refer to its data
sheet. This needs to be done before attaching the line discipline.
Once the ldisc is attached, the CAN interface starts out unconfigured.
Set the speed before starting it::
# The interface needs to be down to change parameters
sudo ip link set can0 down
sudo ip link set can0 type can bitrate 500000
sudo ip link set can0 up
500000 bit/s is a common rate for OBD-II diagnostics.
If you're connecting straight to a car's OBD port, this is the speed
that most cars (but not all!) expect.
After this, you can set out as usual with candump, cansniffer, etc.
How to check the controller version
------------------------------------
Use a terminal program to attach to the controller.
After issuing the "``AT WS``" command, the controller will respond with
its version::
>AT WS
ELM327 v1.4b
>
Note that clones may claim to be any version they like.
It is not indicative of their actual feature set.
Communication example
----------------------
This is a short and incomplete introduction on how to talk to an ELM327.
It is here to guide understanding of the controller's and the driver's
limitation (listed below) as well as manual testing.
The ELM327 has two modes:
- Command mode
- Reception mode
In command mode, it expects one command per line, terminated by CR.
By default, the prompt is a "``>``", after which a command can be
entered::
>ATE1
OK
>
The init script in the driver switches off several configuration options
that are only meaningful in the original OBD scenario the chip is meant
for, and are actually a hindrance for can327.
When a command is not recognized, such as by an older version of the
ELM327, a question mark is printed as a response instead of OK::
>ATUNKNOWN
?
>
At present, can327 does not evaluate this response. See the section
below on known limitations for details.
When a CAN frame is to be sent, the target address is configured, after
which the frame is sent as a command that consists of the data's hex
dump::
>ATSH123
OK
>DEADBEEF12345678
OK
>
The above interaction sends the SFF frame "``DE AD BE EF 12 34 56 78``"
with (11 bit) CAN ID ``0x123``.
For this to function, the controller must be configured for SFF sending
mode (using "``AT PB``", see code or datasheet).
Once a frame has been sent and wait-for-reply mode is on (``ATR1``,
configured on ``listen-only=off``), or when the reply timeout expires
and the driver sets the controller into monitoring mode (``ATMA``),
the ELM327 will send one line for each received CAN frame, consisting
of CAN ID, DLC, and data::
123 8 DEADBEEF12345678
For EFF (29 bit) CAN frames, the address format is slightly different,
which can327 uses to tell the two apart::
12 34 56 78 8 DEADBEEF12345678
The ELM327 will receive both SFF and EFF frames - the current CAN
config (``ATPB``) does not matter.
If the ELM327's internal UART sending buffer runs full, it will abort
the monitoring mode, print "BUFFER FULL" and drop back into command
mode. Note that in this case, unlike with other error messages, the
error message may appear on the same line as the last (usually
incomplete) data frame::
12 34 56 78 8 DEADBEEF123 BUFFER FULL
Known limitations of the controller
------------------------------------
- Clone devices ("v1.5" and others)
Sending RTR frames is not supported and will be dropped silently.
Receiving RTR with DLC 8 will appear to be a regular frame with
the last received frame's DLC and payload.
"``AT CSM``" (CAN Silent Monitoring, i.e. don't send CAN ACKs) is
not supported, and is hard coded to ON. Thus, frames are not ACKed
while listening: "``AT MA``" (Monitor All) will always be "silent".
However, immediately after sending a frame, the ELM327 will be in
"receive reply" mode, in which it *does* ACK any received frames.
Once the bus goes silent, or an error occurs (such as BUFFER FULL),
or the receive reply timeout runs out, the ELM327 will end reply
reception mode on its own and can327 will fall back to "``AT MA``"
in order to keep monitoring the bus.
Other limitations may apply, depending on the clone and the quality
of its firmware.
- All versions
No full duplex operation is supported. The driver will switch
between input/output mode as quickly as possible.
The length of outgoing RTR frames cannot be set. In fact, some
clones (tested with one identifying as "``v1.5``") are unable to
send RTR frames at all.
We don't have a way to get real-time notifications on CAN errors.
While there is a command (``AT CS``) to retrieve some basic stats,
we don't poll it as it would force us to interrupt reception mode.
- Versions prior to 1.4b
These versions do not send CAN ACKs when in monitoring mode (AT MA).
However, they do send ACKs while waiting for a reply immediately
after sending a frame. The driver maximizes this time to make the
controller as useful as possible.
Starting with version 1.4b, the ELM327 supports the "``AT CSM``"
command, and the "listen-only" CAN option will take effect.
- Versions prior to 1.4
These chips do not support the "``AT PB``" command, and thus cannot
change bitrate or SFF/EFF mode on-the-fly. This will have to be
programmed by the user before attaching the line discipline. See the
data sheet for details.
- Versions prior to 1.3
These chips cannot be used at all with can327. They do not support
the "``AT D1``" command, which is necessary to avoid parsing conflicts
on incoming data, as well as distinction of RTR frame lengths.
Specifically, this allows for easy distinction of SFF and EFF
frames, and to check whether frames are complete. While it is possible
to deduce the type and length from the length of the line the ELM327
sends us, this method fails when the ELM327's UART output buffer
overruns. It may abort sending in the middle of the line, which will
then be mistaken for something else.
Known limitations of the driver
--------------------------------
- No 8/7 timing.
ELM327 can only set CAN bitrates that are of the form 500000/n, where
n is an integer divisor.
However there is an exception: With a separate flag, it may set the
speed to be 8/7 of the speed indicated by the divisor.
This mode is not currently implemented.
- No evaluation of command responses.
The ELM327 will reply with OK when a command is understood, and with ?
when it is not. The driver does not currently check this, and simply
assumes that the chip understands every command.
The driver is built such that functionality degrades gracefully
nevertheless. See the section on known limitations of the controller.
- No use of hardware CAN ID filtering
An ELM327's UART sending buffer will easily overflow on heavy CAN bus
load, resulting in the "``BUFFER FULL``" message. Using the hardware
filters available through "``AT CF xxx``" and "``AT CM xxx``" would be
helpful here, however SocketCAN does not currently provide a facility
to make use of such hardware features.
Rationale behind the chosen configuration
------------------------------------------
``AT E1``
Echo on
We need this to be able to get a prompt reliably.
``AT S1``
Spaces on
We need this to distinguish 11/29 bit CAN addresses received.
Note:
We can usually do this using the line length (odd/even),
but this fails if the line is not transmitted fully to
the host (BUFFER FULL).
``AT D1``
DLC on
We need this to tell the "length" of RTR frames.
A note on CAN bus termination
------------------------------
Your adapter may have resistors soldered in which are meant to terminate
the bus. This is correct when it is plugged into a OBD-II socket, but
not helpful when trying to tap into the middle of an existing CAN bus.
If communications don't work with the adapter connected, check for the
termination resistors on its PCB and try removing them.
linux-7.2.3/Documentation/networking/device_drivers/can/ctu/ctucanfd-driver.rst
+638
View File
@@ -0,0 +1,638 @@
.. SPDX-License-Identifier: GPL-2.0-or-later
CTU CAN FD Driver
=================
Author: Martin Jerabek <martin.jerabek01@gmail.com>
About CTU CAN FD IP Core
------------------------
`CTU CAN FD <https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core>`_
is an open source soft core written in VHDL.
It originated in 2015 as Ondrej Ille's project
at the `Department of Measurement <https://meas.fel.cvut.cz/>`_
of `FEE <http://www.fel.cvut.cz/en/>`_ at `CTU <https://www.cvut.cz/en>`_.
The SocketCAN driver for Xilinx Zynq SoC based MicroZed board
`Vivado integration <https://gitlab.fel.cvut.cz/canbus/zynq/zynq-can-sja1000-top>`_
and Intel Cyclone V 5CSEMA4U23C6 based DE0-Nano-SoC Terasic board
`QSys integration <https://gitlab.fel.cvut.cz/canbus/intel-soc-ctucanfd>`_
has been developed as well as support for
`PCIe integration <https://gitlab.fel.cvut.cz/canbus/pcie-ctucanfd>`_ of the core.
In the case of Zynq, the core is connected via the APB system bus, which does
not have enumeration support, and the device must be specified in Device Tree.
This kind of devices is called platform device in the kernel and is
handled by a platform device driver.
The basic functional model of the CTU CAN FD peripheral has been
accepted into QEMU mainline. See QEMU `CAN emulation support <https://www.qemu.org/docs/master/system/devices/can.html>`_
for CAN FD buses, host connection and CTU CAN FD core emulation. The development
version of emulation support can be cloned from ctu-canfd branch of QEMU local
development `repository <https://gitlab.fel.cvut.cz/canbus/qemu-canbus>`_.
About SocketCAN
---------------
SocketCAN is a standard common interface for CAN devices in the Linux
kernel. As the name suggests, the bus is accessed via sockets, similarly
to common network devices. The reasoning behind this is in depth
described in `Linux SocketCAN <https://www.kernel.org/doc/html/latest/networking/can.html>`_.
In short, it offers a
natural way to implement and work with higher layer protocols over CAN,
in the same way as, e.g., UDP/IP over Ethernet.
Device probe
~~~~~~~~~~~~
Before going into detail about the structure of a CAN bus device driver,
let's reiterate how the kernel gets to know about the device at all.
Some buses, like PCI or PCIe, support device enumeration. That is, when
the system boots, it discovers all the devices on the bus and reads
their configuration. The kernel identifies the device via its vendor ID
and device ID, and if there is a driver registered for this identifier
combination, its probe method is invoked to populate the driver's
instance for the given hardware. A similar situation goes with USB, only
it allows for device hot-plug.
The situation is different for peripherals which are directly embedded
in the SoC and connected to an internal system bus (AXI, APB, Avalon,
and others). These buses do not support enumeration, and thus the kernel
has to learn about the devices from elsewhere. This is exactly what the
Device Tree was made for.
Device tree
~~~~~~~~~~~
An entry in device tree states that a device exists in the system, how
it is reachable (on which bus it resides) and its configuration –
registers address, interrupts and so on. An example of such a device
tree is given in .
::
/ {
/* ... */
amba: amba {
#address-cells = <1>;
#size-cells = <1>;
compatible = "simple-bus";
CTU_CAN_FD_0: CTU_CAN_FD@43c30000 {
compatible = "ctu,ctucanfd";
interrupt-parent = <&intc>;
interrupts = <0 30 4>;
clocks = <&clkc 15>;
reg = <0x43c30000 0x10000>;
};
};
};
.. _sec:socketcan:drv:
Driver structure
~~~~~~~~~~~~~~~~
The driver can be divided into two parts – platform-dependent device
discovery and set up, and platform-independent CAN network device
implementation.
.. _sec:socketcan:platdev:
Platform device driver
^^^^^^^^^^^^^^^^^^^^^^
In the case of Zynq, the core is connected via the AXI system bus, which
does not have enumeration support, and the device must be specified in
Device Tree. This kind of devices is called *platform device* in the
kernel and is handled by a *platform device driver*\ [1]_.
A platform device driver provides the following things:
- A *probe* function
- A *remove* function
- A table of *compatible* devices that the driver can handle
The *probe* function is called exactly once when the device appears (or
the driver is loaded, whichever happens later). If there are more
devices handled by the same driver, the *probe* function is called for
each one of them. Its role is to allocate and initialize resources
required for handling the device, as well as set up low-level functions
for the platform-independent layer, e.g., *read_reg* and *write_reg*.
After that, the driver registers the device to a higher layer, in our
case as a *network device*.
The *remove* function is called when the device disappears, or the
driver is about to be unloaded. It serves to free the resources
allocated in *probe* and to unregister the device from higher layers.
Finally, the table of *compatible* devices states which devices the
driver can handle. The Device Tree entry ``compatible`` is matched
against the tables of all *platform drivers*.
.. code:: c
/* Match table for OF platform binding */
static const struct of_device_id ctucan_of_match[] = {
{ .compatible = "ctu,canfd-2", },
{ .compatible = "ctu,ctucanfd", },
{ /* end of list */ },
};
MODULE_DEVICE_TABLE(of, ctucan_of_match);
static int ctucan_probe(struct platform_device *pdev);
static int ctucan_remove(struct platform_device *pdev);
static struct platform_driver ctucanfd_driver = {
.probe = ctucan_probe,
.remove = ctucan_remove,
.driver = {
.name = DRIVER_NAME,
.of_match_table = ctucan_of_match,
},
};
module_platform_driver(ctucanfd_driver);
.. _sec:socketcan:netdev:
Network device driver
^^^^^^^^^^^^^^^^^^^^^
Each network device must support at least these operations:
- Bring the device up: ``ndo_open``
- Bring the device down: ``ndo_close``
- Submit TX frames to the device: ``ndo_start_xmit``
- Signal TX completion and errors to the network subsystem: ISR
- Submit RX frames to the network subsystem: ISR and NAPI
There are two possible event sources: the device and the network
subsystem. Device events are usually signaled via an interrupt, handled
in an Interrupt Service Routine (ISR). Handlers for the events
originating in the network subsystem are then specified in
``struct net_device_ops``.
When the device is brought up, e.g., by calling ``ip link set can0 up``,
the driver’s function ``ndo_open`` is called. It should validate the
interface configuration and configure and enable the device. The
analogous opposite is ``ndo_close``, called when the device is being
brought down, be it explicitly or implicitly.
When the system should transmit a frame, it does so by calling
``ndo_start_xmit``, which enqueues the frame into the device. If the
device HW queue (FIFO, mailboxes or whatever the implementation is)
becomes full, the ``ndo_start_xmit`` implementation informs the network
subsystem that it should stop the TX queue (via ``netif_stop_queue``).
It is then re-enabled later in ISR when the device has some space
available again and is able to enqueue another frame.
All the device events are handled in ISR, namely:
#. **TX completion**. When the device successfully finishes transmitting
a frame, the frame is echoed locally. On error, an informative error
frame [2]_ is sent to the network subsystem instead. In both cases,
the software TX queue is resumed so that more frames may be sent.
#. **Error condition**. If something goes wrong (e.g., the device goes
bus-off or RX overrun happens), error counters are updated, and
informative error frames are enqueued to SW RX queue.
#. **RX buffer not empty**. In this case, read the RX frames and enqueue
them to SW RX queue. Usually NAPI is used as a middle layer (see ).
.. _sec:socketcan:napi:
NAPI
~~~~
The frequency of incoming frames can be high and the overhead to invoke
the interrupt service routine for each frame can cause significant
system load. There are multiple mechanisms in the Linux kernel to deal
with this situation. They evolved over the years of Linux kernel
development and enhancements. For network devices, the current standard
is NAPI – *the New API*. It is similar to classical top-half/bottom-half
interrupt handling in that it only acknowledges the interrupt in the ISR
and signals that the rest of the processing should be done in softirq
context. On top of that, it offers the possibility to *poll* for new
frames for a while. This has a potential to avoid the costly round of
enabling interrupts, handling an incoming IRQ in ISR, re-enabling the
softirq and switching context back to softirq.
See :ref:`Documentation/networking/napi.rst <napi>` for more information.
Integrating the core to Xilinx Zynq
-----------------------------------
The core interfaces a simple subset of the Avalon
(search for Intel **Avalon Interface Specifications**)
bus as it was originally used on
Alterra FPGA chips, yet Xilinx natively interfaces with AXI
(search for ARM **AMBA AXI and ACE Protocol Specification AXI3,
AXI4, and AXI4-Lite, ACE and ACE-Lite**).
The most obvious solution would be to use
an Avalon/AXI bridge or implement some simple conversion entity.
However, the core’s interface is half-duplex with no handshake
signaling, whereas AXI is full duplex with two-way signaling. Moreover,
even AXI-Lite slave interface is quite resource-intensive, and the
flexibility and speed of AXI are not required for a CAN core.
Thus a much simpler bus was chosen – APB (Advanced Peripheral Bus)
(search for ARM **AMBA APB Protocol Specification**).
APB-AXI bridge is directly available in
Xilinx Vivado, and the interface adaptor entity is just a few simple
combinatorial assignments.
Finally, to be able to include the core in a block diagram as a custom
IP, the core, together with the APB interface, has been packaged as a
Vivado component.
CTU CAN FD Driver design
------------------------
The general structure of a CAN device driver has already been examined
in . The next paragraphs provide a more detailed description of the CTU
CAN FD core driver in particular.
Low-level driver
~~~~~~~~~~~~~~~~
The core is not intended to be used solely with SocketCAN, and thus it
is desirable to have an OS-independent low-level driver. This low-level
driver can then be used in implementations of OS driver or directly
either on bare metal or in a user-space application. Another advantage
is that if the hardware slightly changes, only the low-level driver
needs to be modified.
The code [3]_ is in part automatically generated and in part written
manually by the core author, with contributions of the thesis’ author.
The low-level driver supports operations such as: set bit timing, set
controller mode, enable/disable, read RX frame, write TX frame, and so
on.
Configuring bit timing
~~~~~~~~~~~~~~~~~~~~~~
On CAN, each bit is divided into four segments: SYNC, PROP, PHASE1, and
PHASE2. Their duration is expressed in multiples of a Time Quantum
(details in `CAN Specification, Version 2.0 <http://esd.cs.ucr.edu/webres/can20.pdf>`_, chapter 8).
When configuring
bitrate, the durations of all the segments (and time quantum) must be
computed from the bitrate and Sample Point. This is performed
independently for both the Nominal bitrate and Data bitrate for CAN FD.
SocketCAN is fairly flexible and offers either highly customized
configuration by setting all the segment durations manually, or a
convenient configuration by setting just the bitrate and sample point
(and even that is chosen automatically per Bosch recommendation if not
specified). However, each CAN controller may have different base clock
frequency and different width of segment duration registers. The
algorithm thus needs the minimum and maximum values for the durations
(and clock prescaler) and tries to optimize the numbers to fit both the
constraints and the requested parameters.
.. code:: c
struct can_bittiming_const {
char name[16]; /* Name of the CAN controller hardware */
__u32 tseg1_min; /* Time segment 1 = prop_seg + phase_seg1 */
__u32 tseg1_max;
__u32 tseg2_min; /* Time segment 2 = phase_seg2 */
__u32 tseg2_max;
__u32 sjw_max; /* Synchronisation jump width */
__u32 brp_min; /* Bit-rate prescaler */
__u32 brp_max;
__u32 brp_inc;
};
[lst:can_bittiming_const]
A curious reader will notice that the durations of the segments PROP_SEG
and PHASE_SEG1 are not determined separately but rather combined and
then, by default, the resulting TSEG1 is evenly divided between PROP_SEG
and PHASE_SEG1. In practice, this has virtually no consequences as the
sample point is between PHASE_SEG1 and PHASE_SEG2. In CTU CAN FD,
however, the duration registers ``PROP`` and ``PH1`` have different
widths (6 and 7 bits, respectively), so the auto-computed values might
overflow the shorter register and must thus be redistributed among the
two [4]_.
Handling RX
~~~~~~~~~~~
Frame reception is handled in NAPI queue, which is enabled from ISR when
the RXNE (RX FIFO Not Empty) bit is set. Frames are read one by one
until either no frame is left in the RX FIFO or the maximum work quota
has been reached for the NAPI poll run (see ). Each frame is then passed
to the network interface RX queue.
An incoming frame may be either a CAN 2.0 frame or a CAN FD frame. The
way to distinguish between these two in the kernel is to allocate either
``struct can_frame`` or ``struct canfd_frame``, the two having different
sizes. In the controller, the information about the frame type is stored
in the first word of RX FIFO.
This brings us a chicken-egg problem: we want to allocate the ``skb``
for the frame, and only if it succeeds, fetch the frame from FIFO;
otherwise keep it there for later. But to be able to allocate the
correct ``skb``, we have to fetch the first work of FIFO. There are
several possible solutions:
#. Read the word, then allocate. If it fails, discard the rest of the
frame. When the system is low on memory, the situation is bad anyway.
#. Always allocate ``skb`` big enough for an FD frame beforehand. Then
tweak the ``skb`` internals to look like it has been allocated for
the smaller CAN 2.0 frame.
#. Add option to peek into the FIFO instead of consuming the word.
#. If the allocation fails, store the read word into driver’s data. On
the next try, use the stored word instead of reading it again.
Option 1 is simple enough, but not very satisfying if we could do
better. Option 2 is not acceptable, as it would require modifying the
private state of an integral kernel structure. The slightly higher
memory consumption is just a virtual cherry on top of the “cake”. Option
3 requires non-trivial HW changes and is not ideal from the HW point of
view.
Option 4 seems like a good compromise, with its disadvantage being that
a partial frame may stay in the FIFO for a prolonged time. Nonetheless,
there may be just one owner of the RX FIFO, and thus no one else should
see the partial frame (disregarding some exotic debugging scenarios).
Basides, the driver resets the core on its initialization, so the
partial frame cannot be “adopted” either. In the end, option 4 was
selected [5]_.
.. _subsec:ctucanfd:rxtimestamp:
Timestamping RX frames
^^^^^^^^^^^^^^^^^^^^^^
The CTU CAN FD core reports the exact timestamp when the frame has been
received. The timestamp is by default captured at the sample point of
the last bit of EOF but is configurable to be captured at the SOF bit.
The timestamp source is external to the core and may be up to 64 bits
wide. At the time of writing, passing the timestamp from kernel to
userspace is not yet implemented, but is planned in the future.
Handling TX
~~~~~~~~~~~
The CTU CAN FD core has 4 independent TX buffers, each with its own
state and priority. When the core wants to transmit, a TX buffer in
Ready state with the highest priority is selected.
The priorities are 3bit numbers in register TX_PRIORITY
(nibble-aligned). This should be flexible enough for most use cases.
SocketCAN, however, supports only one FIFO queue for outgoing
frames [6]_. The buffer priorities may be used to simulate the FIFO
behavior by assigning each buffer a distinct priority and *rotating* the
priorities after a frame transmission is completed.
In addition to priority rotation, the SW must maintain head and tail
pointers into the FIFO formed by the TX buffers to be able to determine
which buffer should be used for next frame (``txb_head``) and which
should be the first completed one (``txb_tail``). The actual buffer
indices are (obviously) modulo 4 (number of TX buffers), but the
pointers must be at least one bit wider to be able to distinguish
between FIFO full and FIFO empty – in this situation,
:math:`txb\_head \equiv txb\_tail\ (\textrm{mod}\ 4)`. An example of how
the FIFO is maintained, together with priority rotation, is depicted in
|
+------+---+---+---+---+
| TXB# | 0 | 1 | 2 | 3 |
+======+===+===+===+===+
| Seq | A | B | C | |
+------+---+---+---+---+
| Prio | 7 | 6 | 5 | 4 |
+------+---+---+---+---+
| | | T | | H |
+------+---+---+---+---+
|
+------+---+---+---+---+
| TXB# | 0 | 1 | 2 | 3 |
+======+===+===+===+===+
| Seq | | B | C | |
+------+---+---+---+---+
| Prio | 4 | 7 | 6 | 5 |
+------+---+---+---+---+
| | | T | | H |
+------+---+---+---+---+
|
+------+---+---+---+---+----+
| TXB# | 0 | 1 | 2 | 3 | 0’ |
+======+===+===+===+===+====+
| Seq | E | B | C | D | |
+------+---+---+---+---+----+
| Prio | 4 | 7 | 6 | 5 | |
+------+---+---+---+---+----+
| | | T | | | H |
+------+---+---+---+---+----+
|
.. kernel-figure:: fsm_txt_buffer_user.svg
TX Buffer states with possible transitions
.. _subsec:ctucanfd:txtimestamp:
Timestamping TX frames
^^^^^^^^^^^^^^^^^^^^^^
When submitting a frame to a TX buffer, one may specify the timestamp at
which the frame should be transmitted. The frame transmission may start
later, but not sooner. Note that the timestamp does not participate in
buffer prioritization – that is decided solely by the mechanism
described above.
Support for time-based packet transmission was recently merged to Linux
v4.19 `Time-based packet transmission <https://lwn.net/Articles/748879/>`_,
but it remains yet to be researched
whether this functionality will be practical for CAN.
Also similarly to retrieving the timestamp of RX frames, the core
supports retrieving the timestamp of TX frames – that is the time when
the frame was successfully delivered. The particulars are very similar
to timestamping RX frames and are described in .
Handling RX buffer overrun
~~~~~~~~~~~~~~~~~~~~~~~~~~
When a received frame does no more fit into the hardware RX FIFO in its
entirety, RX FIFO overrun flag (STATUS[DOR]) is set and Data Overrun
Interrupt (DOI) is triggered. When servicing the interrupt, care must be
taken first to clear the DOR flag (via COMMAND[CDO]) and after that
clear the DOI interrupt flag. Otherwise, the interrupt would be
immediately [7]_ rearmed.
**Note**: During development, it was discussed whether the internal HW
pipelining cannot disrupt this clear sequence and whether an additional
dummy cycle is necessary between clearing the flag and the interrupt. On
the Avalon interface, it indeed proved to be the case, but APB being
safe because it uses 2-cycle transactions. Essentially, the DOR flag
would be cleared, but DOI register’s Preset input would still be high
the cycle when the DOI clear request would also be applied (by setting
the register’s Reset input high). As Set had higher priority than Reset,
the DOI flag would not be reset. This has been already fixed by swapping
the Set/Reset priority (see issue #187).
Reporting Error Passive and Bus Off conditions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It may be desirable to report when the node reaches *Error Passive*,
*Error Warning*, and *Bus Off* conditions. The driver is notified about
error state change by an interrupt (EPI, EWLI), and then proceeds to
determine the core’s error state by reading its error counters.
There is, however, a slight race condition here – there is a delay
between the time when the state transition occurs (and the interrupt is
triggered) and when the error counters are read. When EPI is received,
the node may be either *Error Passive* or *Bus Off*. If the node goes
*Bus Off*, it obviously remains in the state until it is reset.
Otherwise, the node is *or was* *Error Passive*. However, it may happen
that the read state is *Error Warning* or even *Error Active*. It may be
unclear whether and what exactly to report in that case, but I
personally entertain the idea that the past error condition should still
be reported. Similarly, when EWLI is received but the state is later
detected to be *Error Passive*, *Error Passive* should be reported.
CTU CAN FD Driver Sources Reference
-----------------------------------
.. kernel-doc:: drivers/net/can/ctucanfd/ctucanfd.h
:internal:
.. kernel-doc:: drivers/net/can/ctucanfd/ctucanfd_base.c
:internal:
.. kernel-doc:: drivers/net/can/ctucanfd/ctucanfd_pci.c
:internal:
.. kernel-doc:: drivers/net/can/ctucanfd/ctucanfd_platform.c
:internal:
CTU CAN FD IP Core and Driver Development Acknowledgment
---------------------------------------------------------
* Odrej Ille <ondrej.ille@gmail.com>
* started the project as student at Department of Measurement, FEE, CTU
* invested great amount of personal time and enthusiasm to the project over years
* worked on more funded tasks
* `Department of Measurement <https://meas.fel.cvut.cz/>`_,
`Faculty of Electrical Engineering <http://www.fel.cvut.cz/en/>`_,
`Czech Technical University <https://www.cvut.cz/en>`_
* is the main investor into the project over many years
* uses project in their CAN/CAN FD diagnostics framework for `Skoda Auto <https://www.skoda-auto.cz/>`_
* `Digiteq Automotive <https://www.digiteqautomotive.com/en>`_
* funding of the project CAN FD Open Cores Support Linux Kernel Based Systems
* negotiated and paid CTU to allow public access to the project
* provided additional funding of the work
* `Department of Control Engineering <https://control.fel.cvut.cz/en>`_,
`Faculty of Electrical Engineering <http://www.fel.cvut.cz/en/>`_,
`Czech Technical University <https://www.cvut.cz/en>`_
* solving the project CAN FD Open Cores Support Linux Kernel Based Systems
* providing GitLab management
* virtual servers and computational power for continuous integration
* providing hardware for HIL continuous integration tests
* `PiKRON Ltd. <http://pikron.com/>`_
* minor funding to initiate preparation of the project open-sourcing
* Petr Porazil <porazil@pikron.com>
* design of PCIe transceiver addon board and assembly of boards
* design and assembly of MZ_APO baseboard for MicroZed/Zynq based system
* Martin Jerabek <martin.jerabek01@gmail.com>
* Linux driver development
* continuous integration platform architect and GHDL updates
* thesis `Open-source and Open-hardware CAN FD Protocol Support <https://dspace.cvut.cz/bitstream/handle/10467/80366/F3-DP-2019-Jerabek-Martin-Jerabek-thesis-2019-canfd.pdf>`_
* Jiri Novak <jnovak@fel.cvut.cz>
* project initiation, management and use at Department of Measurement, FEE, CTU
* Pavel Pisa <pisa@cmp.felk.cvut.cz>
* initiate open-sourcing, project coordination, management at Department of Control Engineering, FEE, CTU
* Jaroslav Beran<jara.beran@gmail.com>
* system integration for Intel SoC, core and driver testing and updates
* Carsten Emde (`OSADL <https://www.osadl.org/>`_)
* provided OSADL expertise to discuss IP core licensing
* pointed to possible deadlock for LGPL and CAN bus possible patent case which lead to relicense IP core design to BSD like license
* Reiner Zitzmann and Holger Zeltwanger (`CAN in Automation <https://www.can-cia.org/>`_)
* provided suggestions and help to inform community about the project and invited us to events focused on CAN bus future development directions
* Jan Charvat
* implemented CTU CAN FD functional model for QEMU which has been integrated into QEMU mainline (`docs/system/devices/can.rst <https://www.qemu.org/docs/master/system/devices/can.html>`_)
* Bachelor thesis Model of CAN FD Communication Controller for QEMU Emulator
Notes
-----
.. [1]
Other buses have their own specific driver interface to set up the
device.
.. [2]
Not to be mistaken with CAN Error Frame. This is a ``can_frame`` with
``CAN_ERR_FLAG`` set and some error info in its ``data`` field.
.. [3]
Available in CTU CAN FD repository
`<https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core>`_
.. [4]
As is done in the low-level driver functions
``ctucan_hw_set_nom_bittiming`` and
``ctucan_hw_set_data_bittiming``.
.. [5]
At the time of writing this thesis, option 1 is still being used and
the modification is queued in gitlab issue #222
.. [6]
Strictly speaking, multiple CAN TX queues are supported since v4.19
`can: enable multi-queue for SocketCAN devices <https://lore.kernel.org/patchwork/patch/913526/>`_ but no mainline driver is using
them yet.
.. [7]
Or rather in the next clock cycle
linux-7.2.3/Documentation/networking/device_drivers/can/ctu/fsm_txt_buffer_user.svg
+151
View File
@@ -0,0 +1,151 @@
<?xml version="1.0" encoding="UTF-8"?>
<svg width="113.611mm" height="86.6873mm" version="1.1" viewBox="0 0 113.611 86.6873" xmlns="http://www.w3.org/2000/svg" xmlns:cc="http://creativecommons.org/ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<defs>
<marker id="marker3667" overflow="visible" orient="auto">
<path transform="scale(-.6)" d="m8.71859 4.03374-10.9259-4.01772 10.9259-4.01772c-1.7455 2.37206-1.73544 5.61745-6e-7 8.03544z" fill="#28a4ff" fill-rule="evenodd" stroke="#28a4ff" stroke-linejoin="round" stroke-width=".625"/>
</marker>
<marker id="marker3517" overflow="visible" orient="auto">
<path transform="scale(-.6)" d="m8.71859 4.03374-10.9259-4.01772 10.9259-4.01772c-1.7455 2.37206-1.73544 5.61745-6e-7 8.03544z" fill-rule="evenodd" stroke="#000" stroke-linejoin="round" stroke-width=".625"/>
</marker>
<marker id="marker3373" overflow="visible" orient="auto">
<path transform="scale(-.6)" d="m8.71859 4.03374-10.9259-4.01772 10.9259-4.01772c-1.7455 2.37206-1.73544 5.61745-6e-7 8.03544z" fill-rule="evenodd" stroke="#000" stroke-linejoin="round" stroke-width=".625"/>
</marker>
<marker id="marker3199" overflow="visible" orient="auto">
<path transform="scale(-.6)" d="m8.71859 4.03374-10.9259-4.01772 10.9259-4.01772c-1.7455 2.37206-1.73544 5.61745-6e-7 8.03544z" fill="#28a4ff" fill-rule="evenodd" stroke="#28a4ff" stroke-linejoin="round" stroke-width=".625"/>
</marker>
<marker id="marker3037" overflow="visible" orient="auto">
<path transform="scale(-.6)" d="m8.71859 4.03374-10.9259-4.01772 10.9259-4.01772c-1.7455 2.37206-1.73544 5.61745-6e-7 8.03544z" fill="#28a4ff" fill-rule="evenodd" stroke="#28a4ff" stroke-linejoin="round" stroke-width=".625"/>
</marker>
<marker id="marker2779" overflow="visible" orient="auto">
<path transform="scale(-.6)" d="m8.71859 4.03374-10.9259-4.01772 10.9259-4.01772c-1.7455 2.37206-1.73544 5.61745-6e-7 8.03544z" fill="#28a4ff" fill-rule="evenodd" stroke="#28a4ff" stroke-linejoin="round" stroke-width=".625"/>
</marker>
<marker id="marker2477" overflow="visible" orient="auto">
<path transform="scale(.6) rotate(180) translate(0)" d="m8.71859 4.03374-10.9259-4.01772 10.9259-4.01772c-1.7455 2.37206-1.73544 5.61745-6e-7 8.03544z" fill="#28a4ff" fill-rule="evenodd" stroke="#28a4ff" stroke-linejoin="round" stroke-width=".625"/>
</marker>
<marker id="marker2074" overflow="visible" orient="auto">
<path transform="scale(.6) rotate(180) translate(0)" d="m8.71859 4.03374-10.9259-4.01772 10.9259-4.01772c-1.7455 2.37206-1.73544 5.61745-6e-7 8.03544z" fill-rule="evenodd" stroke="#000" stroke-linejoin="round" stroke-width=".625"/>
</marker>
<marker id="marker1964" overflow="visible" orient="auto">
<path transform="scale(.6) rotate(180) translate(0)" d="m8.71859 4.03374-10.9259-4.01772 10.9259-4.01772c-1.7455 2.37206-1.73544 5.61745-6e-7 8.03544z" fill-rule="evenodd" stroke="#000" stroke-linejoin="round" stroke-width=".625"/>
</marker>
<marker id="marker1856" overflow="visible" orient="auto">
<path transform="scale(.6) rotate(180) translate(0)" d="m8.71859 4.03374-10.9259-4.01772 10.9259-4.01772c-1.7455 2.37206-1.73544 5.61745-6e-7 8.03544z" fill-rule="evenodd" stroke="#000" stroke-linejoin="round" stroke-width=".625"/>
</marker>
<marker id="Arrow2Mend" overflow="visible" orient="auto">
<path transform="scale(.6) rotate(180) translate(0)" d="m8.71859 4.03374-10.9259-4.01772 10.9259-4.01772c-1.7455 2.37206-1.73544 5.61745-6e-7 8.03544z" fill-rule="evenodd" stroke="#000" stroke-linejoin="round" stroke-width=".625"/>
</marker>
<filter id="filter1204" x="-4.19953e-6" y="-5.60084e-6" width="1.00001" height="1.00001" color-interpolation-filters="sRGB">
<feGaussianBlur stdDeviation="0.00018829868"/>
</filter>
<marker id="marker2074-3" overflow="visible" orient="auto">
<path transform="scale(-.6)" d="m8.71859 4.03374-10.9259-4.01772 10.9259-4.01772c-1.7455 2.37206-1.73544 5.61745-6e-7 8.03544z" fill="#28a4ff" fill-rule="evenodd" stroke="#28a4ff" stroke-linejoin="round" stroke-width=".625"/>
</marker>
<filter id="filter1204-6" x="-4.19953e-6" y="-5.60084e-6" width="1.00001" height="1.00001" color-interpolation-filters="sRGB">
<feGaussianBlur stdDeviation="0.00018829868"/>
</filter>
<filter id="filter1204-6-9" x="-4.19953e-6" y="-5.60084e-6" width="1.00001" height="1.00001" color-interpolation-filters="sRGB">
<feGaussianBlur stdDeviation="0.00018829868"/>
</filter>
<filter id="filter1204-6-2" x="-4.19953e-6" y="-5.60084e-6" width="1.00001" height="1.00001" color-interpolation-filters="sRGB">
<feGaussianBlur stdDeviation="0.00018829868"/>
</filter>
<filter id="filter1204-6-2-9" x="-4.19953e-6" y="-5.60084e-6" width="1.00001" height="1.00001" color-interpolation-filters="sRGB">
<feGaussianBlur stdDeviation="0.00018829868"/>
</filter>
<filter id="filter1204-6-2-9-4" x="-4.19953e-6" y="-5.60084e-6" width="1.00001" height="1.00001" color-interpolation-filters="sRGB">
<feGaussianBlur stdDeviation="0.00018829868"/>
</filter>
<filter id="filter1204-6-2-9-1" x="-4.19953e-6" y="-5.60084e-6" width="1.00001" height="1.00001" color-interpolation-filters="sRGB">
<feGaussianBlur stdDeviation="0.00018829868"/>
</filter>
<filter id="filter1204-6-2-9-1-3" x="-4.19953e-6" y="-5.60084e-6" width="1.00001" height="1.00001" color-interpolation-filters="sRGB">
<feGaussianBlur stdDeviation="0.00018829868"/>
</filter>
<filter id="filter1204-6-2-9-1-3-1" x="-4.19953e-6" y="-5.60084e-6" width="1.00001" height="1.00001" color-interpolation-filters="sRGB">
<feGaussianBlur stdDeviation="0.00018829868"/>
</filter>
</defs>
<metadata>
<rdf:RDF>
<cc:Work rdf:about="">
<dc:format>image/svg+xml</dc:format>
<dc:type rdf:resource="http://purl.org/dc/dcmitype/StillImage"/>
<dc:title/>
</cc:Work>
</rdf:RDF>
</metadata>
<g transform="translate(-49.0277 -104.823)">
<g>
<path d="m130.534 165.429h-71.1816v-17.5315" fill="none" marker-end="url(#marker2477)" stroke="#28a4ff" stroke-width=".6"/>
<path d="m145.034 122.959v-11.5914h-43.1215" fill="none" marker-end="url(#marker3037)" stroke="#28a4ff" stroke-width=".6"/>
<rect x="130.679" y="122.933" width="28.2965" height="45.2319" rx="0" ry="0" fill="#e5e5e5" stroke="#717171" stroke-linecap="square" stroke-width=".499999"/>
<path d="m102.044 116.236h23.3126l-0.13388 18.8185h19.9383v3.66603" fill="none" marker-end="url(#marker3199)" stroke="#28a4ff" stroke-width=".6"/>
<path d="m59.5006 138.391v-24.2517h20.6338" fill="none" marker-end="url(#marker2779)" stroke="#28a4ff" stroke-width=".6"/>
<rect x="78.1389" y="126.411" width="28.0037" height="35.0443" rx="0" ry="0" fill="#e5e5e5" stroke="#717171" stroke-linecap="square" stroke-width=".5"/>
</g>
<g fill="#ffcb35" stroke="#000" stroke-linecap="square">
<ellipse cx="92.1408" cy="114.239" rx="10.8866" ry="4.39308" stroke-width=".5"/>
<ellipse cx="92.1408" cy="134.185" rx="10.8866" ry="4.39308" stroke-width=".499999"/>
<ellipse cx="92.1408" cy="152.199" rx="10.8866" ry="4.39308" stroke-width=".499999"/>
</g>
<g fill="#28a4ff" stroke="#000" stroke-linecap="square" stroke-width=".499999">
<ellipse cx="144.827" cy="143.316" rx="10.8866" ry="4.39308"/>
<ellipse cx="144.827" cy="159.143" rx="10.8866" ry="4.39308"/>
<ellipse cx="59.4364" cy="142.823" rx="7.36455" ry="4.39308"/>
<ellipse cx="144.827" cy="129.196" rx="10.8866" ry="4.39308"/>
<ellipse cx="143.077" cy="180.53" rx="10.8866" ry="4.39308"/>
</g>
<ellipse cx="110.386" cy="180.53" rx="10.8866" ry="4.39308" fill="#ffcb35" stroke="#000" stroke-linecap="square" stroke-width=".499999"/>
<text x="110.90907" y="179.42688" font-size="3.175px" xml:space="preserve"><tspan x="110.90907" y="179.42688" dy="0.60000002" text-align="center" text-anchor="middle">Accessible</tspan><tspan x="110.90907" y="183.39563"><tspan font-size="3.175px" text-align="center" text-anchor="middle">for S</tspan>W</tspan></text>
<text x="143.5869" y="179.52795" xml:space="preserve"><tspan x="143.5869" y="179.52795" dy="1 0 0 0 0 0" font-family="sans-serif" font-size="2.82222px" text-align="center" text-anchor="middle" style="font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal">Inaccessible</tspan><tspan x="143.5869" y="183.36786" font-size="3.175px"><tspan font-size="3.175px" text-align="center" text-anchor="middle">for S</tspan>W</tspan></text>
<g font-size="3.175px">
<text x="91.95018" y="115.29005" xml:space="preserve"><tspan x="91.95018" y="115.29005" font-size="3.175px"><tspan font-size="3.175px" text-align="center" text-anchor="middle">Ready</tspan></tspan></text>
<text x="145.25127" y="130.49019" xml:space="preserve"><tspan x="145.25127" y="130.49019" font-size="3.175px"><tspan font-size="3.175px" text-align="center" text-anchor="middle">TX OK</tspan></tspan></text>
<text x="145.31845" y="144.43121" xml:space="preserve"><tspan x="145.31845" y="144.43121" font-size="3.175px"><tspan font-size="3.175px" text-align="center" text-anchor="middle">Aborted</tspan></tspan></text>
<text x="145.40399" y="160.36035" xml:space="preserve"><tspan x="145.40399" y="160.36035" font-size="3.175px"><tspan font-size="3.175px" text-align="center" text-anchor="middle">TX failed</tspan></tspan></text>
<text x="91.823967" y="133.53941" text-align="center" text-anchor="middle" style="line-height:0.9" xml:space="preserve"><tspan x="91.823967" y="133.53941" text-align="center"><tspan font-size="3.175px" text-align="center" text-anchor="middle">TX in</tspan></tspan><tspan x="91.823967" y="136.39691" text-align="center">progress</tspan></text>
<text x="91.648918" y="151.84813" text-align="center" text-anchor="middle" style="line-height:0.9" xml:space="preserve"><tspan x="91.648918" y="151.84813" text-align="center"><tspan font-size="3.175px" text-align="center" text-anchor="middle">Abort in</tspan></tspan><tspan x="91.648918" y="154.70563" text-align="center">progress</tspan></text>
<text x="59.456043" y="143.91658" xml:space="preserve"><tspan x="59.456043" y="143.91658" font-size="3.175px"><tspan font-size="3.175px" text-align="center" text-anchor="middle">Empty</tspan></tspan></text>
</g>
<g fill="none">
<g stroke="#000">
<rect x="52.3943" y="171.63" width="106.581" height="16.601" rx="0" ry="0" stroke-linecap="square" stroke-width=".499999"/>
<g stroke-width=".6">
<path d="m106.383 159.046h26.4967" marker-end="url(#Arrow2Mend)"/>
<path d="m103.138 152.268h41.5564v-3.92426" marker-end="url(#marker1856)"/>
<path d="m106.38 129.354h17.7785"/>
<path d="m125.818 129.359h7.2418" marker-end="url(#marker1964)"/>
</g>
<path d="m124.169 129.354a0.959514 0.97091 0 0 1 0.47587-0.84557 0.959514 0.97091 0 0 1 0.96164-3e-3 0.959514 0.97091 0 0 1 0.48149 0.84231" stroke-linecap="square" stroke-width=".600001"/>
<path d="m55.7026 180.832h34.8131" marker-end="url(#marker2074)" stroke-width=".6"/>
</g>
<g>
<path d="m55.6464 185.744h34.8131" marker-end="url(#marker2074-3)" stroke="#28a4ff" stroke-width=".600001"/>
<g stroke-width=".6">
<path d="m94.0487 129.889v-10.6493" marker-end="url(#marker3373)" stroke="#000"/>
<path d="m89.7534 118.621v10.662" marker-end="url(#marker3517)" stroke="#000"/>
<path d="m92.119 138.812v7.9718" marker-end="url(#marker3667)" stroke="#28a4ff"/>
</g>
</g>
</g>
<text transform="matrix(.264583 0 0 .264583 91.8919 139.964)" x="26.959213" y="9.11724" fill="#2aa1ff" filter="url(#filter1204-6-2-9-1-3-1)" font-size="12px" stroke-width="3.77953" text-align="center" text-anchor="middle" style="line-height:1.1" xml:space="preserve"><tspan x="26.959213" y="9.11724" text-align="center">Set</tspan><tspan x="26.959213" y="22.31724" text-align="center">abort</tspan></text>
<text transform="translate(49.0277 104.823)" x="57.620724" y="16.855087" filter="url(#filter1204)" font-size="3.175px" text-align="center" text-anchor="middle" style="line-height:1.1" xml:space="preserve"><tspan x="57.620724" y="16.855087" text-align="center">Transmission</tspan><tspan x="57.620724" y="20.347588" text-align="center">unsuccessful</tspan></text>
<g font-size="12px" stroke-width="3.77953" text-anchor="middle">
<text transform="matrix(.264583 0 0 .264583 68.5988 118.913)" x="38.824219" y="9.1171875" filter="url(#filter1204)" text-align="center" style="line-height:1.1" xml:space="preserve"><tspan x="38.824219" y="9.1171875" text-align="center">Transmission</tspan><tspan x="38.824219" y="22.317188" text-align="center">starts</tspan></text>
<text transform="matrix(.264583 0 0 .264583 106.802 130.509)" x="38.824219" y="9.1171875" filter="url(#filter1204)" text-align="center" style="line-height:1.1" xml:space="preserve"><tspan x="38.824219" y="9.1171875" text-align="center">Transmission</tspan><tspan x="38.824219" y="22.317188" text-align="center">successful</tspan></text>
<text transform="matrix(.264583 0 0 .264583 107.77 145.476)" x="38.824219" y="9.1171875" filter="url(#filter1204)" text-align="center" style="line-height:1.1" xml:space="preserve"><tspan x="38.824219" y="9.1171875" text-align="center">Transmission</tspan><tspan x="38.824219" y="22.317188" text-align="center">sborted</tspan></text>
</g>
<g stroke-width="3.77953" text-anchor="middle">
<text transform="matrix(.264583 0 0 .264583 107.574 155.948)" x="38.824219" y="9.1171875" filter="url(#filter1204)" font-size="10.6667px" text-align="center" style="line-height:1.1" xml:space="preserve"><tspan x="38.824219" y="9.1171875" text-align="center">Retransmit</tspan><tspan x="38.824219" y="20.850557" text-align="center">limit reached or</tspan><tspan x="38.824219" y="32.583927" text-align="center">node went bus off</tspan><tspan x="38.824219" y="44.317299" text-align="center"/></text>
<text transform="matrix(.264583 0 0 .264583 60.7127 177.384)" x="38.824539" y="9.1173134" filter="url(#filter1204-6)" font-size="12px" text-align="center" style="line-height:1.1" xml:space="preserve"><tspan x="38.824539" y="9.1173134" font-size="12px" stroke-width="3.77953" text-align="center" text-anchor="middle">Transmission result</tspan></text>
<text transform="matrix(.264583 0 0 .264583 45.6885 173.226)" x="57.727047" y="9.11724" filter="url(#filter1204-6-9)" font-size="12px" text-align="center" style="line-height:1.1" xml:space="preserve"><tspan x="57.727047" y="9.11724" font-size="12px" stroke-width="3.77953" text-align="center" text-anchor="middle">Legend:</tspan></text>
</g>
<g fill="#2aa1ff" font-size="12px" stroke-width="3.77953" text-anchor="middle">
<text transform="matrix(.264583 0 0 .264583 57.0045 182.079)" x="57.727047" y="9.11724" filter="url(#filter1204-6-2)" text-align="center" style="line-height:1.1" xml:space="preserve"><tspan x="57.727047" y="9.11724" fill="#2aa1ff" font-size="12px" stroke-width="3.77953" text-align="center" text-anchor="middle">SW command</tspan></text>
<text transform="matrix(.264583 0 0 .264583 57.7865 110.104)" x="40.822609" y="9.11724" filter="url(#filter1204-6-2-9)" text-align="center" style="line-height:1.1" xml:space="preserve"><tspan x="40.822609" y="9.11724" fill="#2aa1ff" font-size="12px" stroke-width="3.77953" text-align="center" text-anchor="middle">Set ready</tspan></text>
<text transform="matrix(.264583 0 0 .264583 116.893 107.491)" x="28.049065" y="9.1172523" filter="url(#filter1204-6-2-9-4)" text-align="center" style="line-height:1.1" xml:space="preserve"><tspan x="28.049065" y="9.1172523" fill="#2aa1ff" font-size="12px" stroke-width="3.77953" text-align="center" text-anchor="middle">Set ready</tspan></text>
<text transform="matrix(.264583 0 0 .264583 87.5687 166.324)" x="28.049065" y="9.1172523" filter="url(#filter1204-6-2-9-1)" text-align="center" style="line-height:1.1" xml:space="preserve"><tspan x="28.049065" y="9.1172523" fill="#2aa1ff" font-size="12px" stroke-width="3.77953" text-align="center" text-anchor="middle">Set empty</tspan></text>
<text transform="matrix(.264583 0 0 .264583 106.53 113.074)" x="30.228771" y="8.9063139" filter="url(#filter1204-6-2-9-1-3)" text-align="center" style="line-height:1.1" xml:space="preserve"><tspan x="30.228771" y="8.9063139" fill="#2aa1ff" font-size="12px" stroke-width="3.77953" text-align="center" text-anchor="middle">Set abort</tspan></text>
</g>
</g>
</svg>
Side by Side

After

Width:  |  Height:  |  Size: 16 KiB

linux-7.2.3/Documentation/networking/device_drivers/can/freescale/flexcan.rst
+54
View File
@@ -0,0 +1,54 @@
.. SPDX-License-Identifier: GPL-2.0+
=============================
Flexcan CAN Controller driver
=============================
Authors: Marc Kleine-Budde <mkl@pengutronix.de>,
Dario Binacchi <dario.binacchi@amarulasolutions.com>
On/off RTR frames reception
===========================
For most flexcan IP cores the driver supports 2 RX modes:
- FIFO
- mailbox
The older flexcan cores (integrated into the i.MX25, i.MX28, i.MX35
and i.MX53 SOCs) only receive RTR frames if the controller is
configured for RX-FIFO mode.
The RX FIFO mode uses a hardware FIFO with a depth of 6 CAN frames,
while the mailbox mode uses a software FIFO with a depth of up to 62
CAN frames. With the help of the bigger buffer, the mailbox mode
performs better under high system load situations.
As reception of RTR frames is part of the CAN standard, all flexcan
cores come up in a mode where RTR reception is possible.
With the "rx-rtr" private flag the ability to receive RTR frames can
be waived at the expense of losing the ability to receive RTR
messages. This trade off is beneficial in certain use cases.
"rx-rtr" on
Receive RTR frames. (default)
The CAN controller can and will receive RTR frames.
On some IP cores the controller cannot receive RTR frames in the
more performant "RX mailbox" mode and will use "RX FIFO" mode
instead.
"rx-rtr" off
Waive ability to receive RTR frames. (not supported on all IP cores)
This mode activates the "RX mailbox mode" for better performance, on
some IP cores RTR frames cannot be received anymore.
The setting can only be changed if the interface is down::
ip link set dev can0 down
ethtool --set-priv-flags can0 rx-rtr {off|on}
ip link set dev can0 up
linux-7.2.3/Documentation/networking/device_drivers/can/index.rst
+15
View File
@@ -0,0 +1,15 @@
.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
Controller Area Network (CAN) Device Drivers
============================================
Device drivers for CAN devices.
Contents:
.. toctree::
:maxdepth: 2
can327
ctu/ctucanfd-driver
freescale/flexcan
linux-7.2.3/Documentation/networking/device_drivers/cellular/index.rst
+11
View File
@@ -0,0 +1,11 @@
.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
Cellular Modem Device Drivers
=============================
Contents:
.. toctree::
:maxdepth: 2
qualcomm/rmnet
linux-7.2.3/Documentation/networking/device_drivers/cellular/qualcomm/rmnet.rst
+210
View File
@@ -0,0 +1,210 @@
.. SPDX-License-Identifier: GPL-2.0
============
Rmnet Driver
============
1. Introduction
===============
rmnet driver is used for supporting the Multiplexing and aggregation
Protocol (MAP). This protocol is used by all recent chipsets using Qualcomm
Technologies, Inc. modems.
This driver can be used to register onto any physical network device in
IP mode. Physical transports include USB, HSIC, PCIe and IP accelerator.
Multiplexing allows for creation of logical netdevices (rmnet devices) to
handle multiple private data networks (PDN) like a default internet, tethering,
multimedia messaging service (MMS) or IP media subsystem (IMS). Hardware sends
packets with MAP headers to rmnet. Based on the multiplexer id, rmnet
routes to the appropriate PDN after removing the MAP header.
Aggregation is required to achieve high data rates. This involves hardware
sending aggregated bunch of MAP frames. rmnet driver will de-aggregate
these MAP frames and send them to appropriate PDN's.
2. Packet format
================
a. MAP packet v1 (data / control)
---------------------------------
MAP header fields are in big endian format.
Packet format::
Bit 0 1 2-7 8-15 16-31
Function Command / Data Reserved Pad Multiplexer ID Payload length
Bit 32-x
Function Raw bytes
Command (1)/ Data (0) bit value is to indicate if the packet is a MAP command
or data packet. Command packet is used for transport level flow control. Data
packets are standard IP packets.
Reserved bits must be zero when sent and ignored when received.
Padding is the number of bytes to be appended to the payload to
ensure 4 byte alignment.
Multiplexer ID is to indicate the PDN on which data has to be sent.
Payload length includes the padding length but does not include MAP header
length.
b. Map packet v4 (data / control)
---------------------------------
MAP header fields are in big endian format.
Packet format::
Bit 0 1 2-7 8-15 16-31
Function Command / Data Reserved Pad Multiplexer ID Payload length
Bit 32-(x-33) (x-32)-x
Function Raw bytes Checksum offload header
Command (1)/ Data (0) bit value is to indicate if the packet is a MAP command
or data packet. Command packet is used for transport level flow control. Data
packets are standard IP packets.
Reserved bits must be zero when sent and ignored when received.
Padding is the number of bytes to be appended to the payload to
ensure 4 byte alignment.
Multiplexer ID is to indicate the PDN on which data has to be sent.
Payload length includes the padding length but does not include MAP header
length.
Checksum offload header, has the information about the checksum processing done
by the hardware.Checksum offload header fields are in big endian format.
Packet format::
Bit 0-14 15 16-31
Function Reserved Valid Checksum start offset
Bit 31-47 48-64
Function Checksum length Checksum value
Reserved bits must be zero when sent and ignored when received.
Valid bit indicates whether the partial checksum is calculated and is valid.
Set to 1, if its is valid. Set to 0 otherwise.
Padding is the number of bytes to be appended to the payload to
ensure 4 byte alignment.
Checksum start offset, Indicates the offset in bytes from the beginning of the
IP header, from which modem computed checksum.
Checksum length is the Length in bytes starting from CKSUM_START_OFFSET,
over which checksum is computed.
Checksum value, indicates the checksum computed.
c. MAP packet v5 (data / control)
---------------------------------
MAP header fields are in big endian format.
Packet format::
Bit 0 1 2-7 8-15 16-31
Function Command / Data Next header Pad Multiplexer ID Payload length
Bit 32-x
Function Raw bytes
Command (1)/ Data (0) bit value is to indicate if the packet is a MAP command
or data packet. Command packet is used for transport level flow control. Data
packets are standard IP packets.
Next header is used to indicate the presence of another header, currently is
limited to checksum header.
Padding is the number of bytes to be appended to the payload to
ensure 4 byte alignment.
Multiplexer ID is to indicate the PDN on which data has to be sent.
Payload length includes the padding length but does not include MAP header
length.
d. Checksum offload header v5
-----------------------------
Checksum offload header fields are in big endian format.
Packet format::
Bit 0 - 6 7 8-15 16-31
Function Header Type Next Header Checksum Valid Reserved
Header Type is to indicate the type of header, this usually is set to CHECKSUM
Header types
= ===============
0 Reserved
1 Reserved
2 checksum header
= ===============
Checksum Valid is to indicate whether the header checksum is valid. Value of 1
implies that checksum is calculated on this packet and is valid, value of 0
indicates that the calculated packet checksum is invalid.
Reserved bits must be zero when sent and ignored when received.
e. MAP packet v1/v5 (command specific)
--------------------------------------
Packet format::
Bit 0 1 2-7 8 - 15 16 - 31
Function Command Reserved Pad Multiplexer ID Payload length
Bit 32 - 39 40 - 45 46 - 47 48 - 63
Function Command name Reserved Command Type Reserved
Bit 64 - 95
Function Transaction ID
Bit 96 - 127
Function Command data
Command 1 indicates disabling flow while 2 is enabling flow
Command types
= ==========================================
0 for MAP command request
1 is to acknowledge the receipt of a command
2 is for unsupported commands
3 is for error during processing of commands
= ==========================================
f. Aggregation
--------------
Aggregation is multiple MAP packets (can be data or command) delivered to
rmnet in a single linear skb. rmnet will process the individual
packets and either ACK the MAP command or deliver the IP packet to the
network stack as needed
Packet format::
MAP header|IP Packet|Optional padding|MAP header|IP Packet|Optional padding....
MAP header|IP Packet|Optional padding|MAP header|Command Packet|Optional pad...
3. Userspace configuration
==========================
rmnet userspace configuration is done through netlink using iproute2
https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/
The driver uses rtnl_link_ops for communication.
linux-7.2.3/Documentation/networking/device_drivers/ethernet/3com/3c509.rst
+249
View File
@@ -0,0 +1,249 @@
.. SPDX-License-Identifier: GPL-2.0
=============================================================================
Linux and the 3Com EtherLink III Series Ethercards (driver v1.18c and higher)
=============================================================================
This file contains the instructions and caveats for v1.18c and higher versions
of the 3c509 driver. You should not use the driver without reading this file.
release 1.0
28 February 2002
Current maintainer (corrections to):
Maciej W. Rozycki <macro@orcam.me.uk>
Introduction
============
The following are notes and information on using the 3Com EtherLink III series
ethercards in Linux. These cards are commonly known by the most widely-used
card's 3Com model number, 3c509. They are all 10mb/s ISA-bus cards and shouldn't
be (but sometimes are) confused with the similarly-numbered PCI-bus "3c905"
(aka "Vortex" or "Boomerang") series. Kernel support for the 3c509 family is
provided by the module 3c509.c, which has code to support all of the following
models:
- 3c509 (original ISA card)
- 3c509B (later revision of the ISA card; supports full-duplex)
- 3c589 (PCMCIA)
- 3c589B (later revision of the 3c589; supports full-duplex)
- 3c579 (EISA)
Large portions of this documentation were heavily borrowed from the guide
written the original author of the 3c509 driver, Donald Becker. The master
copy of that document, which contains notes on older versions of the driver,
currently resides on Scyld web server: http://www.scyld.com/.
Special Driver Features
=======================
Overriding card settings
The driver allows boot- or load-time overriding of the card's detected IOADDR,
IRQ, and transceiver settings, although this capability shouldn't generally be
needed except to enable full-duplex mode (see below). An example of the syntax
for LILO parameters for doing this::
ether=10,0x310,3,0x3c509,eth0
This configures the first found 3c509 card for IRQ 10, base I/O 0x310, and
transceiver type 3 (10base2). The flag "0x3c509" must be set to avoid conflicts
with other card types when overriding the I/O address. When the driver is
loaded as a module, only the IRQ may be overridden. For example,
setting two cards to IRQ10 and IRQ11 is done by using the irq module
option::
options 3c509 irq=10,11
Full-duplex mode
================
The v1.18c driver added support for the 3c509B's full-duplex capabilities.
In order to enable and successfully use full-duplex mode, three conditions
must be met:
(a) You must have a Etherlink III card model whose hardware supports full-
duplex operations. Currently, the only members of the 3c509 family that are
positively known to support full-duplex are the 3c509B (ISA bus) and 3c589B
(PCMCIA) cards. Cards without the "B" model designation do *not* support
full-duplex mode; these include the original 3c509 (no "B"), the original
3c589, the 3c529 (MCA bus), and the 3c579 (EISA bus).
(b) You must be using your card's 10baseT transceiver (i.e., the RJ-45
connector), not its AUI (thick-net) or 10base2 (thin-net/coax) interfaces.
AUI and 10base2 network cabling is physically incapable of full-duplex
operation.
(c) Most importantly, your 3c509B must be connected to a link partner that is
itself full-duplex capable. This is almost certainly one of two things: a full-
duplex-capable Ethernet switch (*not* a hub), or a full-duplex-capable NIC on
another system that's connected directly to the 3c509B via a crossover cable.
Full-duplex mode can be enabled using 'ethtool'.
.. warning::
Extremely important caution concerning full-duplex mode
Understand that the 3c509B's hardware's full-duplex support is much more
limited than that provide by more modern network interface cards. Although
at the physical layer of the network it fully supports full-duplex operation,
the card was designed before the current Ethernet auto-negotiation (N-way)
spec was written. This means that the 3c509B family ***cannot and will not
auto-negotiate a full-duplex connection with its link partner under any
circumstances, no matter how it is initialized***. If the full-duplex mode
of the 3c509B is enabled, its link partner will very likely need to be
independently _forced_ into full-duplex mode as well; otherwise various nasty
failures will occur - at the very least, you'll see massive numbers of packet
collisions. This is one of very rare circumstances where disabling auto-
negotiation and forcing the duplex mode of a network interface card or switch
would ever be necessary or desirable.
Available Transceiver Types
===========================
For versions of the driver v1.18c and above, the available transceiver types are:
== =========================================================================
0 transceiver type from EEPROM config (normally 10baseT); force half-duplex
1 AUI (thick-net / DB15 connector)
2 (undefined)
3 10base2 (thin-net == coax / BNC connector)
4 10baseT (RJ-45 connector); force half-duplex mode
8 transceiver type and duplex mode taken from card's EEPROM config settings
12 10baseT (RJ-45 connector); force full-duplex mode
== =========================================================================
Prior to driver version 1.18c, only transceiver codes 0-4 were supported. Note
that the new transceiver codes 8 and 12 are the *only* ones that will enable
full-duplex mode, no matter what the card's detected EEPROM settings might be.
This insured that merely upgrading the driver from an earlier version would
never automatically enable full-duplex mode in an existing installation;
it must always be explicitly enabled via one of these code in order to be
activated.
The transceiver type can be changed using 'ethtool'.
Interpretation of error messages and common problems
----------------------------------------------------
Error Messages
^^^^^^^^^^^^^^
eth0: Infinite loop in interrupt, status 2011.
These are "mostly harmless" message indicating that the driver had too much
work during that interrupt cycle. With a status of 0x2011 you are receiving
packets faster than they can be removed from the card. This should be rare
or impossible in normal operation. Possible causes of this error report are:
- a "green" mode enabled that slows the processor down when there is no
keyboard activity.
- some other device or device driver hogging the bus or disabling interrupts.
Check /proc/interrupts for excessive interrupt counts. The timer tick
interrupt should always be incrementing faster than the others.
No received packets
^^^^^^^^^^^^^^^^^^^
If a 3c509, 3c562 or 3c589 can successfully transmit packets, but never
receives packets (as reported by /proc/net/dev or 'ifconfig') you likely
have an interrupt line problem. Check /proc/interrupts to verify that the
card is actually generating interrupts. If the interrupt count is not
increasing you likely have a physical conflict with two devices trying to
use the same ISA IRQ line. The common conflict is with a sound card on IRQ10
or IRQ5, and the easiest solution is to move the 3c509 to a different
interrupt line. If the device is receiving packets but 'ping' doesn't work,
you have a routing problem.
Tx Carrier Errors Reported in /proc/net/dev
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
If an EtherLink III appears to transmit packets, but the "Tx carrier errors"
field in /proc/net/dev increments as quickly as the Tx packet count, you
likely have an unterminated network or the incorrect media transceiver selected.
3c509B card is not detected on machines with an ISA PnP BIOS.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
While the updated driver works with most PnP BIOS programs, it does not work
with all. This can be fixed by disabling PnP support using the 3Com-supplied
setup program.
3c509 card is not detected on overclocked machines
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Increase the delay time in id_read_eeprom() from the current value, 500,
to an absurdly high value, such as 5000.
Decoding Status and Error Messages
----------------------------------
The bits in the main status register are:
===== ======================================
value description
===== ======================================
0x01 Interrupt latch
0x02 Tx overrun, or Rx underrun
0x04 Tx complete
0x08 Tx FIFO room available
0x10 A complete Rx packet has arrived
0x20 A Rx packet has started to arrive
0x40 The driver has requested an interrupt
0x80 Statistics counter nearly full
===== ======================================
The bits in the transmit (Tx) status word are:
===== ============================================
value description
===== ============================================
0x02 Out-of-window collision.
0x04 Status stack overflow (normally impossible).
0x08 16 collisions.
0x10 Tx underrun (not enough PCI bus bandwidth).
0x20 Tx jabber.
0x40 Tx interrupt requested.
0x80 Status is valid (this should always be set).
===== ============================================
When a transmit error occurs the driver produces a status message such as::
eth0: Transmit error, Tx status register 82
The two values typically seen here are:
0x82
^^^^
Out of window collision. This typically occurs when some other Ethernet
host is incorrectly set to full duplex on a half duplex network.
0x88
^^^^
16 collisions. This typically occurs when the network is exceptionally busy
or when another host doesn't correctly back off after a collision. If this
error is mixed with 0x82 errors it is the result of a host incorrectly set
to full duplex (see above).
Both of these errors are the result of network problems that should be
corrected. They do not represent driver malfunction.
Revision history (this file)
============================
28Feb02 v1.0 DR New; major portions based on Becker original 3c509 docs
linux-7.2.3/Documentation/networking/device_drivers/ethernet/3com/vortex.rst
+459
View File
@@ -0,0 +1,459 @@
.. SPDX-License-Identifier: GPL-2.0
=========================
3Com Vortex device driver
=========================
Andrew Morton
30 April 2000
This document describes the usage and errata of the 3Com "Vortex" device
driver for Linux, 3c59x.c.
The driver was written by Donald Becker <becker@scyld.com>
Don is no longer the prime maintainer of this version of the driver.
Please report problems to one or more of:
- Andrew Morton
- Netdev mailing list <netdev@vger.kernel.org>
- Linux kernel mailing list <linux-kernel@vger.kernel.org>
Please note the 'Reporting and Diagnosing Problems' section at the end
of this file.
Since kernel 2.3.99-pre6, this driver incorporates the support for the
3c575-series Cardbus cards which used to be handled by 3c575_cb.c.
This driver supports the following hardware:
- 3c590 Vortex 10Mbps
- 3c592 EISA 10Mbps Demon/Vortex
- 3c597 EISA Fast Demon/Vortex
- 3c595 Vortex 100baseTx
- 3c595 Vortex 100baseT4
- 3c595 Vortex 100base-MII
- 3c900 Boomerang 10baseT
- 3c900 Boomerang 10Mbps Combo
- 3c900 Cyclone 10Mbps TPO
- 3c900 Cyclone 10Mbps Combo
- 3c900 Cyclone 10Mbps TPC
- 3c900B-FL Cyclone 10base-FL
- 3c905 Boomerang 100baseTx
- 3c905 Boomerang 100baseT4
- 3c905B Cyclone 100baseTx
- 3c905B Cyclone 10/100/BNC
- 3c905B-FX Cyclone 100baseFx
- 3c905C Tornado
- 3c920B-EMB-WNM (ATI Radeon 9100 IGP)
- 3c980 Cyclone
- 3c980C Python-T
- 3cSOHO100-TX Hurricane
- 3c555 Laptop Hurricane
- 3c556 Laptop Tornado
- 3c556B Laptop Hurricane
- 3c575 [Megahertz] 10/100 LAN CardBus
- 3c575 Boomerang CardBus
- 3CCFE575BT Cyclone CardBus
- 3CCFE575CT Tornado CardBus
- 3CCFE656 Cyclone CardBus
- 3CCFEM656B Cyclone+Winmodem CardBus
- 3CXFEM656C Tornado+Winmodem CardBus
- 3c450 HomePNA Tornado
- 3c920 Tornado
- 3c982 Hydra Dual Port A
- 3c982 Hydra Dual Port B
- 3c905B-T4
- 3c920B-EMB-WNM Tornado
Module parameters
=================
There are several parameters which may be provided to the driver when
its module is loaded. These are usually placed in ``/etc/modprobe.d/*.conf``
configuration files. Example::
options 3c59x debug=3 rx_copybreak=300
If you are using the PCMCIA tools (cardmgr) then the options may be
placed in /etc/pcmcia/config.opts::
module "3c59x" opts "debug=3 rx_copybreak=300"
The supported parameters are:
debug=N
Where N is a number from 0 to 7. Anything above 3 produces a lot
of output in your system logs. debug=1 is default.
options=N1,N2,N3,...
Each number in the list provides an option to the corresponding
network card. So if you have two 3c905's and you wish to provide
them with option 0x204 you would use::
options=0x204,0x204
The individual options are composed of a number of bitfields which
have the following meanings:
Possible media type settings
== =================================
0 10baseT
1 10Mbs AUI
2 undefined
3 10base2 (BNC)
4 100base-TX
5 100base-FX
6 MII (Media Independent Interface)
7 Use default setting from EEPROM
8 Autonegotiate
9 External MII
10 Use default setting from EEPROM
== =================================
When generating a value for the 'options' setting, the above media
selection values may be OR'ed (or added to) the following:
====== =============================================
0x8000 Set driver debugging level to 7
0x4000 Set driver debugging level to 2
0x0400 Enable Wake-on-LAN
0x0200 Force full duplex mode.
0x0010 Bus-master enable bit (Old Vortex cards only)
====== =============================================
For example::
insmod 3c59x options=0x204
will force full-duplex 100base-TX, rather than allowing the usual
autonegotiation.
global_options=N
Sets the ``options`` parameter for all 3c59x NICs in the machine.
Entries in the ``options`` array above will override any setting of
this.
full_duplex=N1,N2,N3...
Similar to bit 9 of 'options'. Forces the corresponding card into
full-duplex mode. Please use this in preference to the ``options``
parameter.
In fact, please don't use this at all! You're better off getting
autonegotiation working properly.
global_full_duplex=N1
Sets full duplex mode for all 3c59x NICs in the machine. Entries
in the ``full_duplex`` array above will override any setting of this.
flow_ctrl=N1,N2,N3...
Use 802.3x MAC-layer flow control. The 3com cards only support the
PAUSE command, which means that they will stop sending packets for a
short period if they receive a PAUSE frame from the link partner.
The driver only allows flow control on a link which is operating in
full duplex mode.
This feature does not appear to work on the 3c905 - only 3c905B and
3c905C have been tested.
The 3com cards appear to only respond to PAUSE frames which are
sent to the reserved destination address of 01:80:c2:00:00:01. They
do not honour PAUSE frames which are sent to the station MAC address.
rx_copybreak=M
The driver preallocates 32 full-sized (1536 byte) network buffers
for receiving. When a packet arrives, the driver has to decide
whether to leave the packet in its full-sized buffer, or to allocate
a smaller buffer and copy the packet across into it.
This is a speed/space tradeoff.
The value of rx_copybreak is used to decide when to make the copy.
If the packet size is less than rx_copybreak, the packet is copied.
The default value for rx_copybreak is 200 bytes.
max_interrupt_work=N
The driver's interrupt service routine can handle many receive and
transmit packets in a single invocation. It does this in a loop.
The value of max_interrupt_work governs how many times the interrupt
service routine will loop. The default value is 32 loops. If this
is exceeded the interrupt service routine gives up and generates a
warning message "eth0: Too much work in interrupt".
hw_checksums=N1,N2,N3,...
Recent 3com NICs are able to generate IPv4, TCP and UDP checksums
in hardware. Linux has used the Rx checksumming for a long time.
The "zero copy" patch which is planned for the 2.4 kernel series
allows you to make use of the NIC's DMA scatter/gather and transmit
checksumming as well.
The driver is set up so that, when the zerocopy patch is applied,
all Tornado and Cyclone devices will use S/G and Tx checksums.
This module parameter has been provided so you can override this
decision. If you think that Tx checksums are causing a problem, you
may disable the feature with ``hw_checksums=0``.
If you think your NIC should be performing Tx checksumming and the
driver isn't enabling it, you can force the use of hardware Tx
checksumming with ``hw_checksums=1``.
The driver drops a message in the logfiles to indicate whether or
not it is using hardware scatter/gather and hardware Tx checksums.
Scatter/gather and hardware checksums provide considerable
performance improvement for the sendfile() system call, but a small
decrease in throughput for send(). There is no effect upon receive
efficiency.
compaq_ioaddr=N,
compaq_irq=N,
compaq_device_id=N
"Variables to work-around the Compaq PCI BIOS32 problem"....
watchdog=N
Sets the time duration (in milliseconds) after which the kernel
decides that the transmitter has become stuck and needs to be reset.
This is mainly for debugging purposes, although it may be advantageous
to increase this value on LANs which have very high collision rates.
The default value is 5000 (5.0 seconds).
enable_wol=N1,N2,N3,...
Enable Wake-on-LAN support for the relevant interface. Donald
Becker's ``ether-wake`` application may be used to wake suspended
machines.
Also enables the NIC's power management support.
global_enable_wol=N
Sets enable_wol mode for all 3c59x NICs in the machine. Entries in
the ``enable_wol`` array above will override any setting of this.
Media selection
---------------
A number of the older NICs such as the 3c590 and 3c900 series have
10base2 and AUI interfaces.
Prior to January, 2001 this driver would autoselect the 10base2 or AUI
port if it didn't detect activity on the 10baseT port. It would then
get stuck on the 10base2 port and a driver reload was necessary to
switch back to 10baseT. This behaviour could not be prevented with a
module option override.
Later (current) versions of the driver _do_ support locking of the
media type. So if you load the driver module with
modprobe 3c59x options=0
it will permanently select the 10baseT port. Automatic selection of
other media types does not occur.
Transmit error, Tx status register 82
-------------------------------------
This is a common error which is almost always caused by another host on
the same network being in full-duplex mode, while this host is in
half-duplex mode. You need to find that other host and make it run in
half-duplex mode or fix this host to run in full-duplex mode.
As a last resort, you can force the 3c59x driver into full-duplex mode
with
options 3c59x full_duplex=1
but this has to be viewed as a workaround for broken network gear and
should only really be used for equipment which cannot autonegotiate.
Additional resources
--------------------
Details of the device driver implementation are at the top of the source file.
Additional documentation is available at Don Becker's Linux Drivers site:
http://www.scyld.com/vortex.html
Donald Becker's driver development site:
http://www.scyld.com/network.html
Donald's vortex-diag program is useful for inspecting the NIC's state:
http://www.scyld.com/ethercard_diag.html
Donald's mii-diag program may be used for inspecting and manipulating
the NIC's Media Independent Interface subsystem:
http://www.scyld.com/ethercard_diag.html#mii-diag
Donald's wake-on-LAN page:
http://www.scyld.com/wakeonlan.html
3Com's DOS-based application for setting up the NICs EEPROMs:
ftp://ftp.3com.com/pub/nic/3c90x/3c90xx2.exe
Autonegotiation notes
---------------------
The driver uses a one-minute heartbeat for adapting to changes in
the external LAN environment if link is up and 5 seconds if link is down.
This means that when, for example, a machine is unplugged from a hubbed
10baseT LAN plugged into a switched 100baseT LAN, the throughput
will be quite dreadful for up to sixty seconds. Be patient.
Cisco interoperability note from Walter Wong <wcw+@CMU.EDU>:
On a side note, adding HAS_NWAY seems to share a problem with the
Cisco 6509 switch. Specifically, you need to change the spanning
tree parameter for the port the machine is plugged into to 'portfast'
mode. Otherwise, the negotiation fails. This has been an issue
we've noticed for a while but haven't had the time to track down.
Cisco switches (Jeff Busch <jbusch@deja.com>)
My "standard config" for ports to which PC's/servers connect directly::
interface FastEthernet0/N
description machinename
load-interval 30
spanning-tree portfast
If autonegotiation is a problem, you may need to specify "speed
100" and "duplex full" as well (or "speed 10" and "duplex half").
WARNING: DO NOT hook up hubs/switches/bridges to these
specially-configured ports! The switch will become very confused.
Reporting and diagnosing problems
---------------------------------
Maintainers find that accurate and complete problem reports are
invaluable in resolving driver problems. We are frequently not able to
reproduce problems and must rely on your patience and efforts to get to
the bottom of the problem.
If you believe you have a driver problem here are some of the
steps you should take:
- Is it really a driver problem?
Eliminate some variables: try different cards, different
computers, different cables, different ports on the switch/hub,
different versions of the kernel or of the driver, etc.
- OK, it's a driver problem.
You need to generate a report. Typically this is an email to the
maintainer and/or netdev@vger.kernel.org. The maintainer's
email address will be in the driver source or in the MAINTAINERS file.
- The contents of your report will vary a lot depending upon the
problem. If it's a kernel crash then you should refer to
'Documentation/admin-guide/reporting-issues.rst'.
But for most problems it is useful to provide the following:
- Kernel version, driver version
- A copy of the banner message which the driver generates when
it is initialised. For example:
eth0: 3Com PCI 3c905C Tornado at 0xa400, 00:50:da:6a:88:f0, IRQ 19
8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface.
MII transceiver found at address 24, status 782d.
Enabling bus-master transmits and whole-frame receives.
NOTE: You must provide the ``debug=2`` modprobe option to generate
a full detection message. Please do this::
modprobe 3c59x debug=2
- If it is a PCI device, the relevant output from 'lspci -vx', eg::
00:09.0 Ethernet controller: 3Com Corporation 3c905C-TX [Fast Etherlink] (rev 74)
Subsystem: 3Com Corporation: Unknown device 9200
Flags: bus master, medium devsel, latency 32, IRQ 19
I/O ports at a400 [size=128]
Memory at db000000 (32-bit, non-prefetchable) [size=128]
Expansion ROM at <unassigned> [disabled] [size=128K]
Capabilities: [dc] Power Management version 2
00: b7 10 00 92 07 00 10 02 74 00 00 02 08 20 00 00
10: 01 a4 00 00 00 00 00 db 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 b7 10 00 10
30: 00 00 00 00 dc 00 00 00 00 00 00 00 05 01 0a 0a
- A description of the environment: 10baseT? 100baseT?
full/half duplex? switched or hubbed?
- Any additional module parameters which you may be providing to the driver.
- Any kernel logs which are produced. The more the merrier.
If this is a large file and you are sending your report to a
mailing list, mention that you have the logfile, but don't send
it. If you're reporting direct to the maintainer then just send
it.
To ensure that all kernel logs are available, add the
following line to /etc/syslog.conf::
kern.* /var/log/messages
Then restart syslogd with::
/etc/rc.d/init.d/syslog restart
(The above may vary, depending upon which Linux distribution you use).
- If your problem is reproducible then that's great. Try the
following:
1) Increase the debug level. Usually this is done via:
a) modprobe driver debug=7
b) In /etc/modprobe.d/driver.conf:
options driver debug=7
2) Recreate the problem with the higher debug level,
send all logs to the maintainer.
3) Download you card's diagnostic tool from Donald
Becker's website <http://www.scyld.com/ethercard_diag.html>.
Download mii-diag.c as well. Build these.
a) Run 'vortex-diag -aaee' and 'mii-diag -v' when the card is
working correctly. Save the output.
b) Run the above commands when the card is malfunctioning. Send
both sets of output.
Finally, please be patient and be prepared to do some work. You may
end up working on this problem for a week or more as the maintainer
asks more questions, asks for more tests, asks for patches to be
applied, etc. At the end of it all, the problem may even remain
unresolved.
linux-7.2.3/Documentation/networking/device_drivers/ethernet/altera/altera_tse.rst
+286
View File
@@ -0,0 +1,286 @@
.. SPDX-License-Identifier: GPL-2.0
.. include:: <isonum.txt>
=======================================
Altera Triple-Speed Ethernet MAC driver
=======================================
Copyright |copy| 2008-2014 Altera Corporation
This is the driver for the Altera Triple-Speed Ethernet (TSE) controllers
using the SGDMA and MSGDMA soft DMA IP components. The driver uses the
platform bus to obtain component resources. The designs used to test this
driver were built for a Cyclone(R) V SOC FPGA board, a Cyclone(R) V FPGA board,
and tested with ARM and NIOS processor hosts separately. The anticipated use
cases are simple communications between an embedded system and an external peer
for status and simple configuration of the embedded system.
For more information visit www.altera.com and www.rocketboards.org. Support
forums for the driver may be found on www.rocketboards.org, and a design used
to test this driver may be found there as well. Support is also available from
the maintainer of this driver, found in MAINTAINERS.
The Triple-Speed Ethernet, SGDMA, and MSGDMA components are all soft IP
components that can be assembled and built into an FPGA using the Altera
Quartus toolchain. Quartus 13.1 and 14.0 were used to build the design that
this driver was tested against. The sopc2dts tool is used to create the
device tree for the driver, and may be found at rocketboards.org.
The driver probe function examines the device tree and determines if the
Triple-Speed Ethernet instance is using an SGDMA or MSGDMA component. The
probe function then installs the appropriate set of DMA routines to
initialize, setup transmits, receives, and interrupt handling primitives for
the respective configurations.
The SGDMA component is to be deprecated in the near future (over the next 1-2
years as of this writing in early 2014) in favor of the MSGDMA component.
SGDMA support is included for existing designs and reference in case a
developer wishes to support their own soft DMA logic and driver support. Any
new designs should not use the SGDMA.
The SGDMA supports only a single transmit or receive operation at a time, and
therefore will not perform as well compared to the MSGDMA soft IP. Please
visit www.altera.com for known, documented SGDMA errata.
Scatter-gather DMA is not supported by the SGDMA or MSGDMA at this time.
Scatter-gather DMA will be added to a future maintenance update to this
driver.
Jumbo frames are not supported at this time.
The driver limits PHY operations to 10/100Mbps, and has not yet been fully
tested for 1Gbps. This support will be added in a future maintenance update.
1. Kernel Configuration
=======================
The kernel configuration option is ALTERA_TSE:
Device Drivers ---> Network device support ---> Ethernet driver support --->
Altera Triple-Speed Ethernet MAC support (ALTERA_TSE)
2. Driver parameters list
=========================
- debug: message level (0: no output, 16: all);
- dma_rx_num: Number of descriptors in the RX list (default is 64);
- dma_tx_num: Number of descriptors in the TX list (default is 64).
3. Command line options
=======================
Driver parameters can be also passed in command line by using::
altera_tse=dma_rx_num:128,dma_tx_num:512
4. Driver information and notes
===============================
4.1. Transmit process
---------------------
When the driver's transmit routine is called by the kernel, it sets up a
transmit descriptor by calling the underlying DMA transmit routine (SGDMA or
MSGDMA), and initiates a transmit operation. Once the transmit is complete, an
interrupt is driven by the transmit DMA logic. The driver handles the transmit
completion in the context of the interrupt handling chain by recycling
resource required to send and track the requested transmit operation.
4.2. Receive process
--------------------
The driver will post receive buffers to the receive DMA logic during driver
initialization. Receive buffers may or may not be queued depending upon the
underlying DMA logic (MSGDMA is able queue receive buffers, SGDMA is not able
to queue receive buffers to the SGDMA receive logic). When a packet is
received, the DMA logic generates an interrupt. The driver handles a receive
interrupt by obtaining the DMA receive logic status, reaping receive
completions until no more receive completions are available.
4.3. Interrupt Mitigation
-------------------------
The driver is able to mitigate the number of its DMA interrupts
using NAPI for receive operations. Interrupt mitigation is not yet supported
for transmit operations, but will be added in a future maintenance release.
4.4) Ethtool support
--------------------
Ethtool is supported. Driver statistics and internal errors can be taken using:
ethtool -S ethX command. It is possible to dump registers etc.
4.5) PHY Support
----------------
The driver is compatible with PAL to work with PHY and GPHY devices.
4.7) List of source files:
--------------------------
- Kconfig
- Makefile
- altera_tse_main.c: main network device driver
- altera_tse_ethtool.c: ethtool support
- altera_tse.h: private driver structure and common definitions
- altera_msgdma.h: MSGDMA implementation function definitions
- altera_sgdma.h: SGDMA implementation function definitions
- altera_msgdma.c: MSGDMA implementation
- altera_sgdma.c: SGDMA implementation
- altera_sgdmahw.h: SGDMA register and descriptor definitions
- altera_msgdmahw.h: MSGDMA register and descriptor definitions
- altera_utils.c: Driver utility functions
- altera_utils.h: Driver utility function definitions
5. Debug Information
====================
The driver exports debug information such as internal statistics,
debug information, MAC and DMA registers etc.
A user may use the ethtool support to get statistics:
e.g. using: ethtool -S ethX (that shows the statistics counters)
or sees the MAC registers: e.g. using: ethtool -d ethX
The developer can also use the "debug" module parameter to get
further debug information.
6. Statistics Support
=====================
The controller and driver support a mix of IEEE standard defined statistics,
RFC defined statistics, and driver or Altera defined statistics. The four
specifications containing the standard definitions for these statistics are
as follows:
- IEEE 802.3-2012 - IEEE Standard for Ethernet.
- RFC 2863 found at http://www.rfc-editor.org/rfc/rfc2863.txt.
- RFC 2819 found at http://www.rfc-editor.org/rfc/rfc2819.txt.
- Altera Triple Speed Ethernet User Guide, found at http://www.altera.com
The statistics supported by the TSE and the device driver are as follows:
"tx_packets" is equivalent to aFramesTransmittedOK defined in IEEE 802.3-2012,
Section 5.2.2.1.2. This statistics is the count of frames that are successfully
transmitted.
"rx_packets" is equivalent to aFramesReceivedOK defined in IEEE 802.3-2012,
Section 5.2.2.1.5. This statistic is the count of frames that are successfully
received. This count does not include any error packets such as CRC errors,
length errors, or alignment errors.
"rx_crc_errors" is equivalent to aFrameCheckSequenceErrors defined in IEEE
802.3-2012, Section 5.2.2.1.6. This statistic is the count of frames that are
an integral number of bytes in length and do not pass the CRC test as the frame
is received.
"rx_align_errors" is equivalent to aAlignmentErrors defined in IEEE 802.3-2012,
Section 5.2.2.1.7. This statistic is the count of frames that are not an
integral number of bytes in length and do not pass the CRC test as the frame is
received.
"tx_bytes" is equivalent to aOctetsTransmittedOK defined in IEEE 802.3-2012,
Section 5.2.2.1.8. This statistic is the count of data and pad bytes
successfully transmitted from the interface.
"rx_bytes" is equivalent to aOctetsReceivedOK defined in IEEE 802.3-2012,
Section 5.2.2.1.14. This statistic is the count of data and pad bytes
successfully received by the controller.
"tx_pause" is equivalent to aPAUSEMACCtrlFramesTransmitted defined in IEEE
802.3-2012, Section 30.3.4.2. This statistic is a count of PAUSE frames
transmitted from the network controller.
"rx_pause" is equivalent to aPAUSEMACCtrlFramesReceived defined in IEEE
802.3-2012, Section 30.3.4.3. This statistic is a count of PAUSE frames
received by the network controller.
"rx_errors" is equivalent to ifInErrors defined in RFC 2863. This statistic is
a count of the number of packets received containing errors that prevented the
packet from being delivered to a higher level protocol.
"tx_errors" is equivalent to ifOutErrors defined in RFC 2863. This statistic
is a count of the number of packets that could not be transmitted due to errors.
"rx_unicast" is equivalent to ifInUcastPkts defined in RFC 2863. This
statistic is a count of the number of packets received that were not addressed
to the broadcast address or a multicast group.
"rx_multicast" is equivalent to ifInMulticastPkts defined in RFC 2863. This
statistic is a count of the number of packets received that were addressed to
a multicast address group.
"rx_broadcast" is equivalent to ifInBroadcastPkts defined in RFC 2863. This
statistic is a count of the number of packets received that were addressed to
the broadcast address.
"tx_discards" is equivalent to ifOutDiscards defined in RFC 2863. This
statistic is the number of outbound packets not transmitted even though an
error was not detected. An example of a reason this might occur is to free up
internal buffer space.
"tx_unicast" is equivalent to ifOutUcastPkts defined in RFC 2863. This
statistic counts the number of packets transmitted that were not addressed to
a multicast group or broadcast address.
"tx_multicast" is equivalent to ifOutMulticastPkts defined in RFC 2863. This
statistic counts the number of packets transmitted that were addressed to a
multicast group.
"tx_broadcast" is equivalent to ifOutBroadcastPkts defined in RFC 2863. This
statistic counts the number of packets transmitted that were addressed to a
broadcast address.
"ether_drops" is equivalent to etherStatsDropEvents defined in RFC 2819.
This statistic counts the number of packets dropped due to lack of internal
controller resources.
"rx_total_bytes" is equivalent to etherStatsOctets defined in RFC 2819.
This statistic counts the total number of bytes received by the controller,
including error and discarded packets.
"rx_total_packets" is equivalent to etherStatsPkts defined in RFC 2819.
This statistic counts the total number of packets received by the controller,
including error, discarded, unicast, multicast, and broadcast packets.
"rx_undersize" is equivalent to etherStatsUndersizePkts defined in RFC 2819.
This statistic counts the number of correctly formed packets received less
than 64 bytes long.
"rx_oversize" is equivalent to etherStatsOversizePkts defined in RFC 2819.
This statistic counts the number of correctly formed packets greater than 1518
bytes long.
"rx_64_bytes" is equivalent to etherStatsPkts64Octets defined in RFC 2819.
This statistic counts the total number of packets received that were 64 octets
in length.
"rx_65_127_bytes" is equivalent to etherStatsPkts65to127Octets defined in RFC
2819. This statistic counts the total number of packets received that were
between 65 and 127 octets in length inclusive.
"rx_128_255_bytes" is equivalent to etherStatsPkts128to255Octets defined in
RFC 2819. This statistic is the total number of packets received that were
between 128 and 255 octets in length inclusive.
"rx_256_511_bytes" is equivalent to etherStatsPkts256to511Octets defined in
RFC 2819. This statistic is the total number of packets received that were
between 256 and 511 octets in length inclusive.
"rx_512_1023_bytes" is equivalent to etherStatsPkts512to1023Octets defined in
RFC 2819. This statistic is the total number of packets received that were
between 512 and 1023 octets in length inclusive.
"rx_1024_1518_bytes" is equivalent to etherStatsPkts1024to1518Octets define
in RFC 2819. This statistic is the total number of packets received that were
between 1024 and 1518 octets in length inclusive.
"rx_gte_1519_bytes" is a statistic defined specific to the behavior of the
Altera TSE. This statistics counts the number of received good and errored
frames between the length of 1519 and the maximum frame length configured
in the frm_length register. See the Altera TSE User Guide for More details.
"rx_jabbers" is equivalent to etherStatsJabbers defined in RFC 2819. This
statistic is the total number of packets received that were longer than 1518
octets, and had either a bad CRC with an integral number of octets (CRC Error)
or a bad CRC with a non-integral number of octets (Alignment Error).
"rx_runts" is equivalent to etherStatsFragments defined in RFC 2819. This
statistic is the total number of packets received that were less than 64 octets
in length and had either a bad CRC with an integral number of octets (CRC
error) or a bad CRC with a non-integral number of octets (Alignment Error).
linux-7.2.3/Documentation/networking/device_drivers/ethernet/amazon/ena.rst
+471
View File
@@ -0,0 +1,471 @@
.. SPDX-License-Identifier: GPL-2.0
============================================================
Linux kernel driver for Elastic Network Adapter (ENA) family
============================================================
Overview
========
ENA is a networking interface designed to make good use of modern CPU
features and system architectures.
The ENA device exposes a lightweight management interface with a
minimal set of memory mapped registers and extendible command set
through an Admin Queue.
The driver supports a range of ENA devices, is link-speed independent
(i.e., the same driver is used for 10GbE, 25GbE, 40GbE, etc), and has
a negotiated and extendible feature set.
Some ENA devices support SR-IOV. This driver is used for both the
SR-IOV Physical Function (PF) and Virtual Function (VF) devices.
ENA devices enable high speed and low overhead network traffic
processing by providing multiple Tx/Rx queue pairs (the maximum number
is advertised by the device via the Admin Queue), a dedicated MSI-X
interrupt vector per Tx/Rx queue pair, adaptive interrupt moderation,
and CPU cacheline optimized data placement.
The ENA driver supports industry standard TCP/IP offload features such as
checksum offload. Receive-side scaling (RSS) is supported for multi-core
scaling.
The ENA driver and its corresponding devices implement health
monitoring mechanisms such as watchdog, enabling the device and driver
to recover in a manner transparent to the application, as well as
debug logs.
Some of the ENA devices support a working mode called Low-latency
Queue (LLQ), which saves several more microseconds.
ENA Source Code Directory Structure
===================================
================= ======================================================
ena_com.[ch] Management communication layer. This layer is
responsible for the handling all the management
(admin) communication between the device and the
driver.
ena_eth_com.[ch] Tx/Rx data path.
ena_admin_defs.h Definition of ENA management interface.
ena_eth_io_defs.h Definition of ENA data path interface.
ena_common_defs.h Common definitions for ena_com layer.
ena_regs_defs.h Definition of ENA PCI memory-mapped (MMIO) registers.
ena_netdev.[ch] Main Linux kernel driver.
ena_ethtool.c ethtool callbacks.
ena_xdp.[ch] XDP files
ena_pci_id_tbl.h Supported device IDs.
ena_phc.[ch] PTP hardware clock infrastructure (see `PHC`_ for more info)
ena_devlink.[ch] devlink files.
ena_debugfs.[ch] debugfs files.
================= ======================================================
Management Interface:
=====================
ENA management interface is exposed by means of:
- PCIe Configuration Space
- Device Registers
- Admin Queue (AQ) and Admin Completion Queue (ACQ)
- Asynchronous Event Notification Queue (AENQ)
ENA device MMIO Registers are accessed only during driver
initialization and are not used during further normal device
operation.
AQ is used for submitting management commands, and the
results/responses are reported asynchronously through ACQ.
ENA introduces a small set of management commands with room for
vendor-specific extensions. Most of the management operations are
framed in a generic Get/Set feature command.
The following admin queue commands are supported:
- Create I/O submission queue
- Create I/O completion queue
- Destroy I/O submission queue
- Destroy I/O completion queue
- Get feature
- Set feature
- Configure AENQ
- Get statistics
Refer to ena_admin_defs.h for the list of supported Get/Set Feature
properties.
The Asynchronous Event Notification Queue (AENQ) is a uni-directional
queue used by the ENA device to send to the driver events that cannot
be reported using ACQ. AENQ events are subdivided into groups. Each
group may have multiple syndromes, as shown below
The events are:
==================== ===============
Group Syndrome
==================== ===============
Link state change **X**
Fatal error **X**
Notification Suspend traffic
Notification Resume traffic
Keep-Alive **X**
==================== ===============
ACQ and AENQ share the same MSI-X vector.
Keep-Alive is a special mechanism that allows monitoring the device's health.
A Keep-Alive event is delivered by the device every second.
The driver maintains a watchdog (WD) handler which logs the current state and
statistics. If the keep-alive events aren't delivered as expected the WD resets
the device and the driver.
Data Path Interface
===================
I/O operations are based on Tx and Rx Submission Queues (Tx SQ and Rx
SQ correspondingly). Each SQ has a completion queue (CQ) associated
with it.
The SQs and CQs are implemented as descriptor rings in contiguous
physical memory.
The ENA driver supports two Queue Operation modes for Tx SQs:
- **Regular mode:**
In this mode the Tx SQs reside in the host's memory. The ENA
device fetches the ENA Tx descriptors and packet data from host
memory.
- **Low Latency Queue (LLQ) mode or "push-mode":**
In this mode the driver pushes the transmit descriptors and the
first 96 bytes of the packet directly to the ENA device memory
space. The rest of the packet payload is fetched by the
device. For this operation mode, the driver uses a dedicated PCI
device memory BAR, which is mapped with write-combine capability.
**Note that** not all ENA devices support LLQ, and this feature is negotiated
with the device upon initialization. If the ENA device does not
support LLQ mode, the driver falls back to the regular mode.
The Rx SQs support only the regular mode.
The driver supports multi-queue for both Tx and Rx. This has various
benefits:
- Reduced CPU/thread/process contention on a given Ethernet interface.
- Cache miss rate on completion is reduced, particularly for data
cache lines that hold the sk_buff structures.
- Increased process-level parallelism when handling received packets.
- Increased data cache hit rate, by steering kernel processing of
packets to the CPU, where the application thread consuming the
packet is running.
- In hardware interrupt re-direction.
Interrupt Modes
===============
The driver assigns a single MSI-X vector per queue pair (for both Tx
and Rx directions). The driver assigns an additional dedicated MSI-X vector
for management (for ACQ and AENQ).
Management interrupt registration is performed when the Linux kernel
probes the adapter, and it is de-registered when the adapter is
removed. I/O queue interrupt registration is performed when the Linux
interface of the adapter is opened, and it is de-registered when the
interface is closed.
The management interrupt is named::
ena-mgmnt@pci:<PCI domain:bus:slot.function>
and for each queue pair, an interrupt is named::
<interface name>-Tx-Rx-<queue index>
The ENA device operates in auto-mask and auto-clear interrupt
modes. That is, once MSI-X is delivered to the host, its Cause bit is
automatically cleared and the interrupt is masked. The interrupt is
unmasked by the driver after NAPI processing is complete.
Interrupt Moderation
====================
ENA driver and device can operate in conventional or adaptive interrupt
moderation mode.
**In conventional mode** the driver instructs device to postpone interrupt
posting according to static interrupt delay value. The interrupt delay
value can be configured through `ethtool(8)`. The following `ethtool`
parameters are supported by the driver: ``tx-usecs``, ``rx-usecs``
**In adaptive interrupt** moderation mode the interrupt delay value is
updated by the driver dynamically and adjusted every NAPI cycle
according to the traffic nature.
Adaptive coalescing can be switched on/off through `ethtool(8)`'s
:code:`adaptive_rx on|off` parameter.
More information about Adaptive Interrupt Moderation (DIM) can be found in
Documentation/networking/net_dim.rst
.. _`RX copybreak`:
RX copybreak
============
The rx_copybreak is initialized by default to ENA_DEFAULT_RX_COPYBREAK
and can be configured by the ETHTOOL_STUNABLE command of the
SIOCETHTOOL ioctl.
This option controls the maximum packet length for which the RX
descriptor it was received on would be recycled. When a packet smaller
than RX copybreak bytes is received, it is copied into a new memory
buffer and the RX descriptor is returned to HW.
.. _`PHC`:
PTP Hardware Clock (PHC)
========================
.. _`ptp-userspace-api`: https://docs.kernel.org/driver-api/ptp.html#ptp-hardware-clock-user-space-api
.. _`testptp`: https://elixir.bootlin.com/linux/latest/source/tools/testing/selftests/ptp/testptp.c
ENA Linux driver supports PTP hardware clock providing timestamp reference to achieve nanosecond resolution.
**PHC support**
PHC depends on the PTP module, which needs to be either loaded as a module or compiled into the kernel.
Verify if the PTP module is present:
.. code-block:: shell
grep -w '^CONFIG_PTP_1588_CLOCK=[ym]' /boot/config-`uname -r`
- If no output is provided, the ENA driver cannot be loaded with PHC support.
**PHC activation**
The feature is turned off by default, in order to turn the feature on, the ENA driver
can be loaded in the following way:
- devlink:
.. code-block:: shell
sudo devlink dev param set pci/<domain:bus:slot.function> name enable_phc value true cmode driverinit
sudo devlink dev reload pci/<domain:bus:slot.function>
# for example:
sudo devlink dev param set pci/0000:00:06.0 name enable_phc value true cmode driverinit
sudo devlink dev reload pci/0000:00:06.0
All available PTP clock sources can be tracked here:
.. code-block:: shell
ls /sys/class/ptp
PHC support and capabilities can be verified using ethtool:
.. code-block:: shell
ethtool -T <interface>
**PHC timestamp**
To retrieve PHC timestamp, use `ptp-userspace-api`_, usage example using `testptp`_:
.. code-block:: shell
testptp -d /dev/ptp$(ethtool -T <interface> | awk '/PTP Hardware Clock:/ {print $NF}') -k 1
PHC get time requests should be within reasonable bounds,
avoid excessive utilization to ensure optimal performance and efficiency.
The ENA device restricts the frequency of PHC get time requests to a maximum
of 125 requests per second. If this limit is surpassed, the get time request
will fail, leading to an increment in the phc_err_ts statistic.
**PHC statistics**
PHC can be monitored using debugfs (if mounted):
.. code-block:: shell
sudo cat /sys/kernel/debug/<domain:bus:slot.function>/phc_stats
# for example:
sudo cat /sys/kernel/debug/0000:00:06.0/phc_stats
PHC errors must remain below 1% of all PHC requests to maintain the desired level of accuracy and reliability
================= ======================================================
**phc_cnt** | Number of successful retrieved timestamps (below expire timeout).
**phc_exp** | Number of expired retrieved timestamps (above expire timeout).
**phc_skp** | Number of skipped get time attempts (during block period).
**phc_err_dv** | Number of failed get time attempts due to device errors (entering into block state).
**phc_err_ts** | Number of failed get time attempts due to timestamp errors (entering into block state),
| This occurs if driver exceeded the request limit or device received an invalid timestamp.
================= ======================================================
PHC timeouts:
================= ======================================================
**expire** | Max time for a valid timestamp retrieval, passing this threshold will fail
| the get time request and block new requests until block timeout.
**block** | Blocking period starts once get time request expires or fails,
| all get time requests during block period will be skipped.
================= ======================================================
Statistics
==========
The user can obtain ENA device and driver statistics using `ethtool`.
The driver can collect regular or extended statistics (including
per-queue stats) from the device.
In addition the driver logs the stats to syslog upon device reset.
On supported instance types, the statistics will also include the
ENA Express data (fields prefixed with `ena_srd`). For a complete
documentation of ENA Express data refer to
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ena-express.html#ena-express-monitor
MTU
===
The driver supports an arbitrarily large MTU with a maximum that is
negotiated with the device. The driver configures MTU using the
SetFeature command (ENA_ADMIN_MTU property). The user can change MTU
via `ip(8)` and similar legacy tools.
Stateless Offloads
==================
The ENA driver supports:
- IPv4 header checksum offload
- TCP/UDP over IPv4/IPv6 checksum offloads
RSS
===
- The ENA device supports RSS that allows flexible Rx traffic
steering.
- Toeplitz and CRC32 hash functions are supported.
- Different combinations of L2/L3/L4 fields can be configured as
inputs for hash functions.
- The driver configures RSS settings using the AQ SetFeature command
(ENA_ADMIN_RSS_HASH_FUNCTION, ENA_ADMIN_RSS_HASH_INPUT and
ENA_ADMIN_RSS_INDIRECTION_TABLE_CONFIG properties).
- If the NETIF_F_RXHASH flag is set, the 32-bit result of the hash
function delivered in the Rx CQ descriptor is set in the received
SKB.
- The user can provide a hash key, hash function, and configure the
indirection table through `ethtool(8)`.
DEVLINK SUPPORT
===============
.. _`devlink`: https://www.kernel.org/doc/html/latest/networking/devlink/index.html
`devlink`_ supports reloading the driver and initiating re-negotiation with the ENA device
.. code-block:: shell
sudo devlink dev reload pci/<domain:bus:slot.function>
# for example:
sudo devlink dev reload pci/0000:00:06.0
DATA PATH
=========
Tx
--
:code:`ena_start_xmit()` is called by the stack. This function does the following:
- Maps data buffers (``skb->data`` and frags).
- Populates ``ena_buf`` for the push buffer (if the driver and device are
in push mode).
- Prepares ENA bufs for the remaining frags.
- Allocates a new request ID from the empty ``req_id`` ring. The request
ID is the index of the packet in the Tx info. This is used for
out-of-order Tx completions.
- Adds the packet to the proper place in the Tx ring.
- Calls :code:`ena_com_prepare_tx()`, an ENA communication layer that converts
the ``ena_bufs`` to ENA descriptors (and adds meta ENA descriptors as
needed).
* This function also copies the ENA descriptors and the push buffer
to the Device memory space (if in push mode).
- Writes a doorbell to the ENA device.
- When the ENA device finishes sending the packet, a completion
interrupt is raised.
- The interrupt handler schedules NAPI.
- The :code:`ena_clean_tx_irq()` function is called. This function handles the
completion descriptors generated by the ENA, with a single
completion descriptor per completed packet.
* ``req_id`` is retrieved from the completion descriptor. The ``tx_info`` of
the packet is retrieved via the ``req_id``. The data buffers are
unmapped and ``req_id`` is returned to the empty ``req_id`` ring.
* The function stops when the completion descriptors are completed or
the budget is reached.
Rx
--
- When a packet is received from the ENA device.
- The interrupt handler schedules NAPI.
- The :code:`ena_clean_rx_irq()` function is called. This function calls
:code:`ena_com_rx_pkt()`, an ENA communication layer function, which returns the
number of descriptors used for a new packet, and zero if
no new packet is found.
- :code:`ena_rx_skb()` checks packet length:
* If the packet is small (len < rx_copybreak), the driver allocates
a SKB for the new packet, and copies the packet payload into the
SKB data buffer.
- In this way the original data buffer is not passed to the stack
and is reused for future Rx packets.
* Otherwise the function unmaps the Rx buffer, sets the first
descriptor as `skb`'s linear part and the other descriptors as the
`skb`'s frags.
- The new SKB is updated with the necessary information (protocol,
checksum hw verify result, etc), and then passed to the network
stack, using the NAPI interface function :code:`napi_gro_receive()`.
Dynamic RX Buffers (DRB)
------------------------
Each RX descriptor in the RX ring is a single memory page (which is either 4KB
or 16KB long depending on system's configurations).
To reduce the memory allocations required when dealing with a high rate of small
packets, the driver tries to reuse the remaining RX descriptor's space if more
than 2KB of this page remain unused.
A simple example of this mechanism is the following sequence of events:
::
1. Driver allocates page-sized RX buffer and passes it to hardware
+----------------------+
|4KB RX Buffer |
+----------------------+
2. A 300Bytes packet is received on this buffer
3. The driver increases the ref count on this page and returns it back to
HW as an RX buffer of size 4KB - 300Bytes = 3796 Bytes
+----+--------------------+
|****|3796 Bytes RX Buffer|
+----+--------------------+
This mechanism isn't used when an XDP program is loaded, or when the
RX packet is less than rx_copybreak bytes (in which case the packet is
copied out of the RX buffer into the linear part of a new skb allocated
for it and the RX buffer remains the same size, see `RX copybreak`_).
linux-7.2.3/Documentation/networking/device_drivers/ethernet/amd/pds_core.rst
+139
View File
@@ -0,0 +1,139 @@
.. SPDX-License-Identifier: GPL-2.0+
========================================================
Linux Driver for the AMD/Pensando(R) DSC adapter family
========================================================
Copyright(c) 2023 Advanced Micro Devices, Inc
Identifying the Adapter
=======================
To find if one or more AMD/Pensando PCI Core devices are installed on the
host, check for the PCI devices::
# lspci -d 1dd8:100c
b5:00.0 Processing accelerators: Pensando Systems Device 100c
b6:00.0 Processing accelerators: Pensando Systems Device 100c
If such devices are listed as above, then the pds_core.ko driver should find
and configure them for use. There should be log entries in the kernel
messages such as these::
$ dmesg | grep pds_core
pds_core 0000:b5:00.0: 252.048 Gb/s available PCIe bandwidth (16.0 GT/s PCIe x16 link)
pds_core 0000:b5:00.0: FW: 1.60.0-73
pds_core 0000:b6:00.0: 252.048 Gb/s available PCIe bandwidth (16.0 GT/s PCIe x16 link)
pds_core 0000:b6:00.0: FW: 1.60.0-73
Driver and firmware version information can be gathered with devlink::
$ devlink dev info pci/0000:b5:00.0
pci/0000:b5:00.0:
driver pds_core
serial_number FLM18420073
versions:
fixed:
asic.id 0x0
asic.rev 0x0
running:
fw 1.51.0-73
stored:
fw.goldfw 1.15.9-C-22
fw.mainfwa 1.60.0-73
fw.mainfwb 1.60.0-57
Info versions
=============
The ``pds_core`` driver reports the following versions
.. list-table:: devlink info versions implemented
:widths: 5 5 90
* - Name
- Type
- Description
* - ``fw``
- running
- Version of firmware running on the device
* - ``fw.goldfw``
- stored
- Version of firmware stored in the goldfw slot
* - ``fw.mainfwa``
- stored
- Version of firmware stored in the mainfwa slot
* - ``fw.mainfwb``
- stored
- Version of firmware stored in the mainfwb slot
* - ``asic.id``
- fixed
- The ASIC type for this device
* - ``asic.rev``
- fixed
- The revision of the ASIC for this device
Parameters
==========
The ``pds_core`` driver implements the following generic
parameters for controlling the functionality to be made available
as auxiliary_bus devices.
.. list-table:: Generic parameters implemented
:widths: 5 5 8 82
* - Name
- Mode
- Type
- Description
* - ``enable_vnet``
- runtime
- Boolean
- Enables vDPA functionality through an auxiliary_bus device
Firmware Management
===================
The ``flash`` command can update a the DSC firmware. The downloaded firmware
will be saved into either of firmware bank 1 or bank 2, whichever is not
currently in use, and that bank will used for the next boot::
# devlink dev flash pci/0000:b5:00.0 \
file pensando/dsc_fw_1.63.0-22.tar
Health Reporters
================
The driver supports a devlink health reporter for FW status::
# devlink health show pci/0000:2b:00.0 reporter fw
pci/0000:2b:00.0:
reporter fw
state healthy error 0 recover 0
# devlink health diagnose pci/0000:2b:00.0 reporter fw
Status: healthy State: 1 Generation: 0 Recoveries: 0
Enabling the driver
===================
The driver is enabled via the standard kernel configuration system,
using the make command::
make oldconfig/menuconfig/etc.
The driver is located in the menu structure at:
-> Device Drivers
-> Network device support (NETDEVICES [=y])
-> Ethernet driver support
-> AMD devices
-> AMD/Pensando Ethernet PDS_CORE Support
Support
=======
For general Linux networking support, please use the netdev mailing
list, which is monitored by AMD/Pensando personnel::
netdev@vger.kernel.org
linux-7.2.3/Documentation/networking/device_drivers/ethernet/amd/pds_vdpa.rst
+85
View File
@@ -0,0 +1,85 @@
.. SPDX-License-Identifier: GPL-2.0+
.. note: can be edited and viewed with /usr/bin/formiko-vim
==========================================================
PCI vDPA driver for the AMD/Pensando(R) DSC adapter family
==========================================================
AMD/Pensando vDPA VF Device Driver
Copyright(c) 2023 Advanced Micro Devices, Inc
Overview
========
The ``pds_vdpa`` driver is an auxiliary bus driver that supplies
a vDPA device for use by the virtio network stack. It is used with
the Pensando Virtual Function devices that offer vDPA and virtio queue
services. It depends on the ``pds_core`` driver and hardware for the PF
and VF PCI handling as well as for device configuration services.
Using the device
================
The ``pds_vdpa`` device is enabled via multiple configuration steps and
depends on the ``pds_core`` driver to create and enable SR-IOV Virtual
Function devices. After the VFs are enabled, we enable the vDPA service
in the ``pds_core`` device to create the auxiliary devices used by pds_vdpa.
Example steps:
.. code-block:: bash
#!/bin/bash
modprobe pds_core
modprobe vdpa
modprobe pds_vdpa
PF_BDF=`ls /sys/module/pds_core/drivers/pci\:pds_core/*/sriov_numvfs | awk -F / '{print $7}'`
# Enable vDPA VF auxiliary device(s) in the PF
devlink dev param set pci/$PF_BDF name enable_vnet cmode runtime value true
# Create a VF for vDPA use
echo 1 > /sys/bus/pci/drivers/pds_core/$PF_BDF/sriov_numvfs
# Find the vDPA services/devices available
PDS_VDPA_MGMT=`vdpa mgmtdev show | grep vDPA | head -1 | cut -d: -f1`
# Create a vDPA device for use in virtio network configurations
vdpa dev add name vdpa1 mgmtdev $PDS_VDPA_MGMT mac 00:11:22:33:44:55
# Set up an ethernet interface on the vdpa device
modprobe virtio_vdpa
Enabling the driver
===================
The driver is enabled via the standard kernel configuration system,
using the make command::
make oldconfig/menuconfig/etc.
The driver is located in the menu structure at:
-> Device Drivers
-> Network device support (NETDEVICES [=y])
-> Ethernet driver support
-> Pensando devices
-> Pensando Ethernet PDS_VDPA Support
Support
=======
For general Linux networking support, please use the netdev mailing
list, which is monitored by Pensando personnel::
netdev@vger.kernel.org
For more specific support needs, please use the Pensando driver support
email::
drivers@pensando.io
linux-7.2.3/Documentation/networking/device_drivers/ethernet/amd/pds_vfio_pci.rst
+79
View File
@@ -0,0 +1,79 @@
.. SPDX-License-Identifier: GPL-2.0+
.. note: can be edited and viewed with /usr/bin/formiko-vim
==========================================================
PCI VFIO driver for the AMD/Pensando(R) DSC adapter family
==========================================================
AMD/Pensando Linux VFIO PCI Device Driver
Copyright(c) 2023 Advanced Micro Devices, Inc.
Overview
========
The ``pds-vfio-pci`` module is a PCI driver that supports Live Migration
capable Virtual Function (VF) devices in the DSC hardware.
Using the device
================
The pds-vfio-pci device is enabled via multiple configuration steps and
depends on the ``pds_core`` driver to create and enable SR-IOV Virtual
Function devices.
Shown below are the steps to bind the driver to a VF and also to the
associated auxiliary device created by the ``pds_core`` driver. This
example assumes the pds_core and pds-vfio-pci modules are already
loaded.
.. code-block:: bash
:name: example-setup-script
#!/bin/bash
PF_BUS="0000:60"
PF_BDF="0000:60:00.0"
VF_BDF="0000:60:00.1"
# Prevent non-vfio VF driver from probing the VF device
echo 0 > /sys/class/pci_bus/$PF_BUS/device/$PF_BDF/sriov_drivers_autoprobe
# Create single VF for Live Migration via pds_core
echo 1 > /sys/bus/pci/drivers/pds_core/$PF_BDF/sriov_numvfs
# Allow the VF to be bound to the pds-vfio-pci driver
echo "pds-vfio-pci" > /sys/class/pci_bus/$PF_BUS/device/$VF_BDF/driver_override
# Bind the VF to the pds-vfio-pci driver
echo "$VF_BDF" > /sys/bus/pci/drivers/pds-vfio-pci/bind
After performing the steps above, a file in /dev/vfio/<iommu_group>
should have been created.
Enabling the driver
===================
The driver is enabled via the standard kernel configuration system,
using the make command::
make oldconfig/menuconfig/etc.
The driver is located in the menu structure at:
-> Device Drivers
-> VFIO Non-Privileged userspace driver framework
-> VFIO support for PDS PCI devices
Support
=======
For general Linux networking support, please use the netdev mailing
list, which is monitored by Pensando personnel::
netdev@vger.kernel.org
For more specific support needs, please use the Pensando driver support
email::
drivers@pensando.io
linux-7.2.3/Documentation/networking/device_drivers/ethernet/aquantia/atlantic.rst
+556
View File
@@ -0,0 +1,556 @@
.. SPDX-License-Identifier: GPL-2.0
.. include:: <isonum.txt>
===============================
Marvell(Aquantia) AQtion Driver
===============================
For the aQuantia Multi-Gigabit PCI Express Family of Ethernet Adapters
.. Contents
- Identifying Your Adapter
- Configuration
- Supported ethtool options
- Command Line Parameters
- Config file parameters
- Support
- License
Identifying Your Adapter
========================
The driver in this release is compatible with AQC-100, AQC-107, AQC-108
based ethernet adapters.
SFP+ Devices (for AQC-100 based adapters)
-----------------------------------------
This release tested with passive Direct Attach Cables (DAC) and SFP+/LC
Optical Transceiver.
Configuration
=============
Viewing Link Messages
---------------------
Link messages will not be displayed to the console if the distribution is
restricting system messages. In order to see network driver link messages on
your console, set dmesg to eight by entering the following::
dmesg -n 8
.. note::
This setting is not saved across reboots.
Jumbo Frames
------------
The driver supports Jumbo Frames for all adapters. Jumbo Frames support is
enabled by changing the MTU to a value larger than the default of 1500.
The maximum value for the MTU is 16000. Use the `ip` command to
increase the MTU size. For example::
ip link set mtu 16000 dev enp1s0
ethtool
-------
The driver utilizes the ethtool interface for driver configuration and
diagnostics, as well as displaying statistical information. The latest
ethtool version is required for this functionality.
NAPI
----
NAPI (Rx polling mode) is supported in the atlantic driver.
Supported ethtool options
=========================
Viewing adapter settings
------------------------
::
ethtool <ethX>
Output example::
Settings for enp1s0:
Supported ports: [ TP ]
Supported link modes: 100baseT/Full
1000baseT/Full
10000baseT/Full
2500baseT/Full
5000baseT/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 100baseT/Full
1000baseT/Full
10000baseT/Full
2500baseT/Full
5000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 10000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: g
Wake-on: d
Link detected: yes
.. note::
AQrate speeds (2.5/5 Gb/s) will be displayed only with linux kernels > 4.10.
But you can still use these speeds::
ethtool -s eth0 autoneg off speed 2500
Viewing adapter information
---------------------------
::
ethtool -i <ethX>
Output example::
driver: atlantic
version: 5.2.0-050200rc5-generic-kern
firmware-version: 3.1.78
expansion-rom-version:
bus-info: 0000:01:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no
Viewing Ethernet adapter statistics
-----------------------------------
::
ethtool -S <ethX>
Output example::
NIC statistics:
InPackets: 13238607
InUCast: 13293852
InMCast: 52
InBCast: 3
InErrors: 0
OutPackets: 23703019
OutUCast: 23704941
OutMCast: 67
OutBCast: 11
InUCastOctects: 213182760
OutUCastOctects: 22698443
InMCastOctects: 6600
OutMCastOctects: 8776
InBCastOctects: 192
OutBCastOctects: 704
InOctects: 2131839552
OutOctects: 226938073
InPacketsDma: 95532300
OutPacketsDma: 59503397
InOctetsDma: 1137102462
OutOctetsDma: 2394339518
InDroppedDma: 0
Queue[0] InPackets: 23567131
Queue[0] OutPackets: 20070028
Queue[0] InJumboPackets: 0
Queue[0] InLroPackets: 0
Queue[0] InErrors: 0
Queue[1] InPackets: 45428967
Queue[1] OutPackets: 11306178
Queue[1] InJumboPackets: 0
Queue[1] InLroPackets: 0
Queue[1] InErrors: 0
Queue[2] InPackets: 3187011
Queue[2] OutPackets: 13080381
Queue[2] InJumboPackets: 0
Queue[2] InLroPackets: 0
Queue[2] InErrors: 0
Queue[3] InPackets: 23349136
Queue[3] OutPackets: 15046810
Queue[3] InJumboPackets: 0
Queue[3] InLroPackets: 0
Queue[3] InErrors: 0
Interrupt coalescing support
----------------------------
ITR mode, TX/RX coalescing timings could be viewed with::
ethtool -c <ethX>
and changed with::
ethtool -C <ethX> tx-usecs <usecs> rx-usecs <usecs>
To disable coalescing::
ethtool -C <ethX> tx-usecs 0 rx-usecs 0 tx-max-frames 1 tx-max-frames 1
Wake on LAN support
-------------------
WOL support by magic packet::
ethtool -s <ethX> wol g
To disable WOL::
ethtool -s <ethX> wol d
Set and check the driver message level
--------------------------------------
Set message level
::
ethtool -s <ethX> msglvl <level>
Level values:
====== =============================
0x0001 general driver status.
0x0002 hardware probing.
0x0004 link state.
0x0008 periodic status check.
0x0010 interface being brought down.
0x0020 interface being brought up.
0x0040 receive error.
0x0080 transmit error.
0x0200 interrupt handling.
0x0400 transmit completion.
0x0800 receive completion.
0x1000 packet contents.
0x2000 hardware status.
0x4000 Wake-on-LAN status.
====== =============================
By default, the level of debugging messages is set 0x0001(general driver status).
Check message level
::
ethtool <ethX> | grep "Current message level"
If you want to disable the output of messages::
ethtool -s <ethX> msglvl 0
RX flow rules (ntuple filters)
------------------------------
There are separate rules supported, that applies in that order:
1. 16 VLAN ID rules
2. 16 L2 EtherType rules
3. 8 L3/L4 5-Tuple rules
The driver utilizes the ethtool interface for configuring ntuple filters,
via ``ethtool -N <device> <filter>``.
To enable or disable the RX flow rules::
ethtool -K ethX ntuple <on|off>
When disabling ntuple filters, all the user programmed filters are
flushed from the driver cache and hardware. All needed filters must
be re-added when ntuple is re-enabled.
Because of the fixed order of the rules, the location of filters is also fixed:
- Locations 0 - 15 for VLAN ID filters
- Locations 16 - 31 for L2 EtherType filters
- Locations 32 - 39 for L3/L4 5-tuple filters (locations 32, 36 for IPv6)
The L3/L4 5-tuple (protocol, source and destination IP address, source and
destination TCP/UDP/SCTP port) is compared against 8 filters. For IPv4, up to
8 source and destination addresses can be matched. For IPv6, up to 2 pairs of
addresses can be supported. Source and destination ports are only compared for
TCP/UDP/SCTP packets.
To add a filter that directs packet to queue 5, use
``<-N|-U|--config-nfc|--config-ntuple>`` switch::
ethtool -N <ethX> flow-type udp4 src-ip 10.0.0.1 dst-ip 10.0.0.2 src-port 2000 dst-port 2001 action 5 <loc 32>
- action is the queue number.
- loc is the rule number.
For ``flow-type ip4|udp4|tcp4|sctp4|ip6|udp6|tcp6|sctp6`` you must set the loc
number within 32 - 39.
For ``flow-type ip4|udp4|tcp4|sctp4|ip6|udp6|tcp6|sctp6`` you can set 8 rules
for traffic IPv4 or you can set 2 rules for traffic IPv6. Loc number traffic
IPv6 is 32 and 36.
At the moment you can not use IPv4 and IPv6 filters at the same time.
Example filter for IPv6 filter traffic::
sudo ethtool -N <ethX> flow-type tcp6 src-ip 2001:db8:0:f101::1 dst-ip 2001:db8:0:f101::2 action 1 loc 32
sudo ethtool -N <ethX> flow-type ip6 src-ip 2001:db8:0:f101::2 dst-ip 2001:db8:0:f101::5 action -1 loc 36
Example filter for IPv4 filter traffic::
sudo ethtool -N <ethX> flow-type udp4 src-ip 10.0.0.4 dst-ip 10.0.0.7 src-port 2000 dst-port 2001 loc 32
sudo ethtool -N <ethX> flow-type tcp4 src-ip 10.0.0.3 dst-ip 10.0.0.9 src-port 2000 dst-port 2001 loc 33
sudo ethtool -N <ethX> flow-type ip4 src-ip 10.0.0.6 dst-ip 10.0.0.4 loc 34
If you set action -1, then all traffic corresponding to the filter will be discarded.
The maximum value action is 31.
The VLAN filter (VLAN id) is compared against 16 filters.
VLAN id must be accompanied by mask 0xF000. That is to distinguish VLAN filter
from L2 Ethertype filter with UserPriority since both User Priority and VLAN ID
are passed in the same 'vlan' parameter.
To add a filter that directs packets from VLAN 2001 to queue 5::
ethtool -N <ethX> flow-type ip4 vlan 2001 m 0xF000 action 1 loc 0
L2 EtherType filters allows filter packet by EtherType field or both EtherType
and User Priority (PCP) field of 802.1Q.
UserPriority (vlan) parameter must be accompanied by mask 0x1FFF. That is to
distinguish VLAN filter from L2 Ethertype filter with UserPriority since both
User Priority and VLAN ID are passed in the same 'vlan' parameter.
To add a filter that directs IP4 packess of priority 3 to queue 3::
ethtool -N <ethX> flow-type ether proto 0x800 vlan 0x600 m 0x1FFF action 3 loc 16
To see the list of filters currently present::
ethtool <-u|-n|--show-nfc|--show-ntuple> <ethX>
Rules may be deleted from the table itself. This is done using::
sudo ethtool <-N|-U|--config-nfc|--config-ntuple> <ethX> delete <loc>
- loc is the rule number to be deleted.
Rx filters is an interface to load the filter table that funnels all flow
into queue 0 unless an alternative queue is specified using "action". In that
case, any flow that matches the filter criteria will be directed to the
appropriate queue. RX filters is supported on all kernels 2.6.30 and later.
RSS for UDP
-----------
Currently, NIC does not support RSS for fragmented IP packets, which leads to
incorrect working of RSS for fragmented UDP traffic. To disable RSS for UDP the
RX Flow L3/L4 rule may be used.
Example::
ethtool -N eth0 flow-type udp4 action 0 loc 32
UDP GSO hardware offload
------------------------
UDP GSO allows to boost UDP tx rates by offloading UDP headers allocation
into hardware. A special userspace socket option is required for this,
could be validated with /kernel/tools/testing/selftests/net/::
udpgso_bench_tx -u -4 -D 10.0.1.1 -s 6300 -S 100
Will cause sending out of 100 byte sized UDP packets formed from single
6300 bytes user buffer.
UDP GSO is configured by::
ethtool -K eth0 tx-udp-segmentation on
Private flags (testing)
-----------------------
Atlantic driver supports private flags for hardware custom features::
$ ethtool --show-priv-flags ethX
Private flags for ethX:
DMASystemLoopback : off
PKTSystemLoopback : off
DMANetworkLoopback : off
PHYInternalLoopback: off
PHYExternalLoopback: off
Example::
$ ethtool --set-priv-flags ethX DMASystemLoopback on
DMASystemLoopback: DMA Host loopback.
PKTSystemLoopback: Packet buffer host loopback.
DMANetworkLoopback: Network side loopback on DMA block.
PHYInternalLoopback: Internal loopback on Phy.
PHYExternalLoopback: External loopback on Phy (with loopback ethernet cable).
Command Line Parameters
=======================
The following command line parameters are available on atlantic driver:
aq_itr -Interrupt throttling mode
---------------------------------
Accepted values: 0, 1, 0xFFFF
Default value: 0xFFFF
====== ==============================================================
0 Disable interrupt throttling.
1 Enable interrupt throttling and use specified tx and rx rates.
0xFFFF Auto throttling mode. Driver will choose the best RX and TX
interrupt throttling settings based on link speed.
====== ==============================================================
aq_itr_tx - TX interrupt throttle rate
--------------------------------------
Accepted values: 0 - 0x1FF
Default value: 0
TX side throttling in microseconds. Adapter will setup maximum interrupt delay
to this value. Minimum interrupt delay will be a half of this value
aq_itr_rx - RX interrupt throttle rate
--------------------------------------
Accepted values: 0 - 0x1FF
Default value: 0
RX side throttling in microseconds. Adapter will setup maximum interrupt delay
to this value. Minimum interrupt delay will be a half of this value
.. note::
ITR settings could be changed in runtime by ethtool -c means (see below)
Config file parameters
======================
For some fine tuning and performance optimizations,
some parameters can be changed in the {source_dir}/aq_cfg.h file.
AQ_CFG_RX_PAGEORDER
-------------------
Default value: 0
RX page order override. That's a power of 2 number of RX pages allocated for
each descriptor. Received descriptor size is still limited by
AQ_CFG_RX_FRAME_MAX.
Increasing pageorder makes page reuse better (actual on iommu enabled systems).
AQ_CFG_RX_REFILL_THRES
----------------------
Default value: 32
RX refill threshold. RX path will not refill freed descriptors until the
specified number of free descriptors is observed. Larger values may help
better page reuse but may lead to packet drops as well.
AQ_CFG_VECS_DEF
---------------
Number of queues
Valid Range: 0 - 8 (up to AQ_CFG_VECS_MAX)
Default value: 8
Notice this value will be capped by the number of cores available on the system.
AQ_CFG_IS_RSS_DEF
-----------------
Enable/disable Receive Side Scaling
This feature allows the adapter to distribute receive processing
across multiple CPU-cores and to prevent from overloading a single CPU core.
Valid values
== ========
0 disabled
1 enabled
== ========
Default value: 1
AQ_CFG_NUM_RSS_QUEUES_DEF
-------------------------
Number of queues for Receive Side Scaling
Valid Range: 0 - 8 (up to AQ_CFG_VECS_DEF)
Default value: AQ_CFG_VECS_DEF
AQ_CFG_IS_LRO_DEF
-----------------
Enable/disable Large Receive Offload
This offload enables the adapter to coalesce multiple TCP segments and indicate
them as a single coalesced unit to the OS networking subsystem.
The system consumes less energy but it also introduces more latency in packets
processing.
Valid values
== ========
0 disabled
1 enabled
== ========
Default value: 1
AQ_CFG_TX_CLEAN_BUDGET
----------------------
Maximum descriptors to cleanup on TX at once.
Default value: 256
After the aq_cfg.h file changed the driver must be rebuilt to take effect.
Support
=======
If an issue is identified with the released source code on the supported
kernel with a supported adapter, email the specific information related
to the issue to aqn_support@marvell.com
License
=======
aQuantia Corporation Network Driver
Copyright |copy| 2014 - 2019 aQuantia Corporation.
This program is free software; you can redistribute it and/or modify it
under the terms and conditions of the GNU General Public License,
version 2, as published by the Free Software Foundation.
linux-7.2.3/Documentation/networking/device_drivers/ethernet/chelsio/cxgb.rst
+393
View File
@@ -0,0 +1,393 @@
.. SPDX-License-Identifier: GPL-2.0
.. include:: <isonum.txt>
=============================================
Chelsio N210 10Gb Ethernet Network Controller
=============================================
Driver Release Notes for Linux
Version 2.1.1
June 20, 2005
.. Contents
INTRODUCTION
FEATURES
PERFORMANCE
DRIVER MESSAGES
KNOWN ISSUES
SUPPORT
Introduction
============
This document describes the Linux driver for Chelsio 10Gb Ethernet Network
Controller. This driver supports the Chelsio N210 NIC and is backward
compatible with the Chelsio N110 model 10Gb NICs.
Features
========
Adaptive Interrupts (adaptive-rx)
---------------------------------
This feature provides an adaptive algorithm that adjusts the interrupt
coalescing parameters, allowing the driver to dynamically adapt the latency
settings to achieve the highest performance during various types of network
load.
The interface used to control this feature is ethtool. Please see the
ethtool manpage for additional usage information.
By default, adaptive-rx is disabled.
To enable adaptive-rx::
ethtool -C <interface> adaptive-rx on
To disable adaptive-rx, use ethtool::
ethtool -C <interface> adaptive-rx off
After disabling adaptive-rx, the timer latency value will be set to 50us.
You may set the timer latency after disabling adaptive-rx::
ethtool -C <interface> rx-usecs <microseconds>
An example to set the timer latency value to 100us on eth0::
ethtool -C eth0 rx-usecs 100
You may also provide a timer latency value while disabling adaptive-rx::
ethtool -C <interface> adaptive-rx off rx-usecs <microseconds>
If adaptive-rx is disabled and a timer latency value is specified, the timer
will be set to the specified value until changed by the user or until
adaptive-rx is enabled.
To view the status of the adaptive-rx and timer latency values::
ethtool -c <interface>
TCP Segmentation Offloading (TSO) Support
-----------------------------------------
This feature, also known as "large send", enables a system's protocol stack
to offload portions of outbound TCP processing to a network interface card
thereby reducing system CPU utilization and enhancing performance.
The interface used to control this feature is ethtool version 1.8 or higher.
Please see the ethtool manpage for additional usage information.
By default, TSO is enabled.
To disable TSO::
ethtool -K <interface> tso off
To enable TSO::
ethtool -K <interface> tso on
To view the status of TSO::
ethtool -k <interface>
Performance
===========
The following information is provided as an example of how to change system
parameters for "performance tuning" an what value to use. You may or may not
want to change these system parameters, depending on your server/workstation
application. Doing so is not warranted in any way by Chelsio Communications,
and is done at "YOUR OWN RISK". Chelsio will not be held responsible for loss
of data or damage to equipment.
Your distribution may have a different way of doing things, or you may prefer
a different method. These commands are shown only to provide an example of
what to do and are by no means definitive.
Making any of the following system changes will only last until you reboot
your system. You may want to write a script that runs at boot-up which
includes the optimal settings for your system.
Setting PCI Latency Timer::
setpci -d 1425::
* 0x0c.l=0x0000F800
Disabling TCP timestamp::
sysctl -w net.ipv4.tcp_timestamps=0
Disabling SACK::
sysctl -w net.ipv4.tcp_sack=0
Setting large number of incoming connection requests::
sysctl -w net.ipv4.tcp_max_syn_backlog=3000
Setting maximum receive socket buffer size::
sysctl -w net.core.rmem_max=1024000
Setting maximum send socket buffer size::
sysctl -w net.core.wmem_max=1024000
Set smp_affinity (on a multiprocessor system) to a single CPU::
echo 1 > /proc/irq/<interrupt_number>/smp_affinity
Setting default receive socket buffer size::
sysctl -w net.core.rmem_default=524287
Setting default send socket buffer size::
sysctl -w net.core.wmem_default=524287
Setting maximum option memory buffers::
sysctl -w net.core.optmem_max=524287
Setting maximum backlog (# of unprocessed packets before kernel drops)::
sysctl -w net.core.netdev_max_backlog=300000
Setting TCP read buffers (min/default/max)::
sysctl -w net.ipv4.tcp_rmem="10000000 10000000 10000000"
Setting TCP write buffers (min/pressure/max)::
sysctl -w net.ipv4.tcp_wmem="10000000 10000000 10000000"
Setting TCP buffer space (min/pressure/max)::
sysctl -w net.ipv4.tcp_mem="10000000 10000000 10000000"
TCP window size for single connections:
The receive buffer (RX_WINDOW) size must be at least as large as the
Bandwidth-Delay Product of the communication link between the sender and
receiver. Due to the variations of RTT, you may want to increase the buffer
size up to 2 times the Bandwidth-Delay Product. Reference page 289 of
"TCP/IP Illustrated, Volume 1, The Protocols" by W. Richard Stevens.
At 10Gb speeds, use the following formula::
RX_WINDOW >= 1.25MBytes * RTT(in milliseconds)
Example for RTT with 100us: RX_WINDOW = (1,250,000 * 0.1) = 125,000
RX_WINDOW sizes of 256KB - 512KB should be sufficient.
Setting the min, max, and default receive buffer (RX_WINDOW) size::
sysctl -w net.ipv4.tcp_rmem="<min> <default> <max>"
TCP window size for multiple connections:
The receive buffer (RX_WINDOW) size may be calculated the same as single
connections, but should be divided by the number of connections. The
smaller window prevents congestion and facilitates better pacing,
especially if/when MAC level flow control does not work well or when it is
not supported on the machine. Experimentation may be necessary to attain
the correct value. This method is provided as a starting point for the
correct receive buffer size.
Setting the min, max, and default receive buffer (RX_WINDOW) size is
performed in the same manner as single connection.
Driver Messages
===============
The following messages are the most common messages logged by syslog. These
may be found in /var/log/messages.
Driver up::
Chelsio Network Driver - version 2.1.1
NIC detected::
eth#: Chelsio N210 1x10GBaseX NIC (rev #), PCIX 133MHz/64-bit
Link up::
eth#: link is up at 10 Gbps, full duplex
Link down::
eth#: link is down
Known Issues
============
These issues have been identified during testing. The following information
is provided as a workaround to the problem. In some cases, this problem is
inherent to Linux or to a particular Linux Distribution and/or hardware
platform.
1. Large number of TCP retransmits on a multiprocessor (SMP) system.
On a system with multiple CPUs, the interrupt (IRQ) for the network
controller may be bound to more than one CPU. This will cause TCP
retransmits if the packet data were to be split across different CPUs
and re-assembled in a different order than expected.
To eliminate the TCP retransmits, set smp_affinity on the particular
interrupt to a single CPU. You can locate the interrupt (IRQ) used on
the N110/N210 by using ifconfig::
ifconfig <dev_name> | grep Interrupt
Set the smp_affinity to a single CPU::
echo 1 > /proc/irq/<interrupt_number>/smp_affinity
It is highly suggested that you do not run the irqbalance daemon on your
system, as this will change any smp_affinity setting you have applied.
The irqbalance daemon runs on a 10 second interval and binds interrupts
to the least loaded CPU determined by the daemon. To disable this daemon::
chkconfig --level 2345 irqbalance off
By default, some Linux distributions enable the kernel feature,
irqbalance, which performs the same function as the daemon. To disable
this feature, add the following line to your bootloader::
noirqbalance
Example using the Grub bootloader::
title Red Hat Enterprise Linux AS (2.4.21-27.ELsmp)
root (hd0,0)
kernel /vmlinuz-2.4.21-27.ELsmp ro root=/dev/hda3 noirqbalance
initrd /initrd-2.4.21-27.ELsmp.img
2. After running insmod, the driver is loaded and the incorrect network
interface is brought up without running ifup.
When using 2.4.x kernels, including RHEL kernels, the Linux kernel
invokes a script named "hotplug". This script is primarily used to
automatically bring up USB devices when they are plugged in, however,
the script also attempts to automatically bring up a network interface
after loading the kernel module. The hotplug script does this by scanning
the ifcfg-eth# config files in /etc/sysconfig/network-scripts, looking
for HWADDR=<mac_address>.
If the hotplug script does not find the HWADDRR within any of the
ifcfg-eth# files, it will bring up the device with the next available
interface name. If this interface is already configured for a different
network card, your new interface will have incorrect IP address and
network settings.
To solve this issue, you can add the HWADDR=<mac_address> key to the
interface config file of your network controller.
To disable this "hotplug" feature, you may add the driver (module name)
to the "blacklist" file located in /etc/hotplug. It has been noted that
this does not work for network devices because the net.agent script
does not use the blacklist file. Simply remove, or rename, the net.agent
script located in /etc/hotplug to disable this feature.
3. Transport Protocol (TP) hangs when running heavy multi-connection traffic
on an AMD Opteron system with HyperTransport PCI-X Tunnel chipset.
If your AMD Opteron system uses the AMD-8131 HyperTransport PCI-X Tunnel
chipset, you may experience the "133-Mhz Mode Split Completion Data
Corruption" bug identified by AMD while using a 133Mhz PCI-X card on the
bus PCI-X bus.
AMD states, "Under highly specific conditions, the AMD-8131 PCI-X Tunnel
can provide stale data via split completion cycles to a PCI-X card that
is operating at 133 Mhz", causing data corruption.
AMD's provides three workarounds for this problem, however, Chelsio
recommends the first option for best performance with this bug:
For 133Mhz secondary bus operation, limit the transaction length and
the number of outstanding transactions, via BIOS configuration
programming of the PCI-X card, to the following:
Data Length (bytes): 1k
Total allowed outstanding transactions: 2
Please refer to AMD 8131-HT/PCI-X Errata 26310 Rev 3.08 August 2004,
section 56, "133-MHz Mode Split Completion Data Corruption" for more
details with this bug and workarounds suggested by AMD.
It may be possible to work outside AMD's recommended PCI-X settings, try
increasing the Data Length to 2k bytes for increased performance. If you
have issues with these settings, please revert to the "safe" settings
and duplicate the problem before submitting a bug or asking for support.
.. note::
The default setting on most systems is 8 outstanding transactions
and 2k bytes data length.
4. On multiprocessor systems, it has been noted that an application which
is handling 10Gb networking can switch between CPUs causing degraded
and/or unstable performance.
If running on an SMP system and taking performance measurements, it
is suggested you either run the latest netperf-2.4.0+ or use a binding
tool such as Tim Hockin's procstate utilities (runon)
<http://www.hockin.org/~thockin/procstate/>.
Binding netserver and netperf (or other applications) to particular
CPUs will have a significant difference in performance measurements.
You may need to experiment which CPU to bind the application to in
order to achieve the best performance for your system.
If you are developing an application designed for 10Gb networking,
please keep in mind you may want to look at kernel functions
sched_setaffinity & sched_getaffinity to bind your application.
If you are just running user-space applications such as ftp, telnet,
etc., you may want to try the runon tool provided by Tim Hockin's
procstate utility. You could also try binding the interface to a
particular CPU: runon 0 ifup eth0
Support
=======
If you have problems with the software or hardware, please contact our
customer support team via email at support@chelsio.com or check our website
at http://www.chelsio.com
-------------------------------------------------------------------------------
::
Chelsio Communications
370 San Aleso Ave.
Suite 100
Sunnyvale, CA 94085
http://www.chelsio.com
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License, version 2, as
published by the Free Software Foundation.
You should have received a copy of the GNU General Public License along
with this program; if not, write to the Free Software Foundation, Inc.,
59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
THIS SOFTWARE IS PROVIDED ``AS IS`` AND WITHOUT ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
Copyright |copy| 2003-2005 Chelsio Communications. All rights reserved.
linux-7.2.3/Documentation/networking/device_drivers/ethernet/davicom/dm9000.rst
+171
View File
@@ -0,0 +1,171 @@
.. SPDX-License-Identifier: GPL-2.0
=====================
DM9000 Network driver
=====================
Copyright 2008 Simtec Electronics,
Ben Dooks <ben@simtec.co.uk> <ben-linux@fluff.org>
Introduction
------------
This file describes how to use the DM9000 platform-device based network driver
that is contained in the files drivers/net/dm9000.c and drivers/net/dm9000.h.
The driver supports three DM9000 variants, the DM9000E which is the first chip
supported as well as the newer DM9000A and DM9000B devices. It is currently
maintained and tested by Ben Dooks, who should be CC: to any patches for this
driver.
Defining the platform device
----------------------------
The minimum set of resources attached to the platform device are as follows:
1) The physical address of the address register
2) The physical address of the data register
3) The IRQ line the device's interrupt pin is connected to.
These resources should be specified in that order, as the ordering of the
two address regions is important (the driver expects these to be address
and then data).
An example from arch/arm/mach-s3c/mach-bast.c is::
static struct resource bast_dm9k_resource[] = {
[0] = {
.start = S3C2410_CS5 + BAST_PA_DM9000,
.end = S3C2410_CS5 + BAST_PA_DM9000 + 3,
.flags = IORESOURCE_MEM,
},
[1] = {
.start = S3C2410_CS5 + BAST_PA_DM9000 + 0x40,
.end = S3C2410_CS5 + BAST_PA_DM9000 + 0x40 + 0x3f,
.flags = IORESOURCE_MEM,
},
[2] = {
.start = IRQ_DM9000,
.end = IRQ_DM9000,
.flags = IORESOURCE_IRQ | IORESOURCE_IRQ_HIGHLEVEL,
}
};
static struct platform_device bast_device_dm9k = {
.name = "dm9000",
.id = 0,
.num_resources = ARRAY_SIZE(bast_dm9k_resource),
.resource = bast_dm9k_resource,
};
Note the setting of the IRQ trigger flag in bast_dm9k_resource[2].flags,
as this will generate a warning if it is not present. The trigger from
the flags field will be passed to request_irq() when registering the IRQ
handler to ensure that the IRQ is setup correctly.
This shows a typical platform device, without the optional configuration
platform data supplied. The next example uses the same resources, but adds
the optional platform data to pass extra configuration data::
static struct dm9000_plat_data bast_dm9k_platdata = {
.flags = DM9000_PLATF_16BITONLY,
};
static struct platform_device bast_device_dm9k = {
.name = "dm9000",
.id = 0,
.num_resources = ARRAY_SIZE(bast_dm9k_resource),
.resource = bast_dm9k_resource,
.dev = {
.platform_data = &bast_dm9k_platdata,
}
};
The platform data is defined in include/linux/dm9000.h and described below.
Platform data
-------------
Extra platform data for the DM9000 can describe the IO bus width to the
device, whether or not an external PHY is attached to the device and
the availability of an external configuration EEPROM.
The flags for the platform data .flags field are as follows:
DM9000_PLATF_8BITONLY
The IO should be done with 8bit operations.
DM9000_PLATF_16BITONLY
The IO should be done with 16bit operations.
DM9000_PLATF_32BITONLY
The IO should be done with 32bit operations.
DM9000_PLATF_EXT_PHY
The chip is connected to an external PHY.
DM9000_PLATF_NO_EEPROM
This can be used to signify that the board does not have an
EEPROM, or that the EEPROM should be hidden from the user.
DM9000_PLATF_SIMPLE_PHY
Switch to using the simpler PHY polling method which does not
try and read the MII PHY state regularly. This is only available
when using the internal PHY. See the section on link state polling
for more information.
The config symbol DM9000_FORCE_SIMPLE_PHY_POLL, Kconfig entry
"Force simple NSR based PHY polling" allows this flag to be
forced on at build time.
PHY Link state polling
----------------------
The driver keeps track of the link state and informs the network core
about link (carrier) availability. This is managed by several methods
depending on the version of the chip and on which PHY is being used.
For the internal PHY, the original (and currently default) method is
to read the MII state, either when the status changes if we have the
necessary interrupt support in the chip or every two seconds via a
periodic timer.
To reduce the overhead for the internal PHY, there is now the option
of using the DM9000_FORCE_SIMPLE_PHY_POLL config, or DM9000_PLATF_SIMPLE_PHY
platform data option to read the summary information without the
expensive MII accesses. This method is faster, but does not print
as much information.
When using an external PHY, the driver currently has to poll the MII
link status as there is no method for getting an interrupt on link change.
DM9000A / DM9000B
-----------------
These chips are functionally similar to the DM9000E and are supported easily
by the same driver. The features are:
1) Interrupt on internal PHY state change. This means that the periodic
polling of the PHY status may be disabled on these devices when using
the internal PHY.
2) TCP/UDP checksum offloading, which the driver does not currently support.
ethtool
-------
The driver supports the ethtool interface for access to the driver
state information, the PHY state and the EEPROM.
linux-7.2.3/Documentation/networking/device_drivers/ethernet/dec/dmfe.rst
+71
View File
@@ -0,0 +1,71 @@
.. SPDX-License-Identifier: GPL-2.0
==============================================================
Davicom DM9102(A)/DM9132/DM9801 fast ethernet driver for Linux
==============================================================
Note: This driver doesn't have a maintainer.
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
This driver provides kernel support for Davicom DM9102(A)/DM9132/DM9801 ethernet cards ( CNET
10/100 ethernet cards uses Davicom chipset too, so this driver supports CNET cards too ).If you
didn't compile this driver as a module, it will automatically load itself on boot and print a
line similar to::
dmfe: Davicom DM9xxx net driver, version 1.36.4 (2002-01-17)
If you compiled this driver as a module, you have to load it on boot.You can load it with command::
insmod dmfe
This way it will autodetect the device mode.This is the suggested way to load the module.Or you can pass
a mode= setting to module while loading, like::
insmod dmfe mode=0 # Force 10M Half Duplex
insmod dmfe mode=1 # Force 100M Half Duplex
insmod dmfe mode=4 # Force 10M Full Duplex
insmod dmfe mode=5 # Force 100M Full Duplex
Next you should configure your network interface with a command similar to::
ifconfig eth0 172.22.3.18
^^^^^^^^^^^
Your IP Address
Then you may have to modify the default routing table with command::
route add default eth0
Now your ethernet card should be up and running.
TODO:
- Implement pci_driver::suspend() and pci_driver::resume() power management methods.
- Check on 64 bit boxes.
- Check and fix on big endian boxes.
- Test and make sure PCI latency is now correct for all cases.
Authors:
Sten Wang <sten_wang@davicom.com.tw > : Original Author
Contributors:
- Marcelo Tosatti <marcelo@conectiva.com.br>
- Alan Cox <alan@lxorguk.ukuu.org.uk>
- Jeff Garzik <jgarzik@pobox.com>
- Vojtech Pavlik <vojtech@suse.cz>
linux-7.2.3/Documentation/networking/device_drivers/ethernet/dlink/dl2k.rst
+314
View File
@@ -0,0 +1,314 @@
.. SPDX-License-Identifier: GPL-2.0
=========================================================
D-Link DL2000-based Gigabit Ethernet Adapter Installation
=========================================================
May 23, 2002
.. Contents
- Compatibility List
- Quick Install
- Compiling the Driver
- Installing the Driver
- Option parameter
- Configuration Script Sample
- Troubleshooting
Compatibility List
==================
Adapter Support:
- D-Link DGE-550T Gigabit Ethernet Adapter.
- D-Link DGE-550SX Gigabit Ethernet Adapter.
- D-Link DL2000-based Gigabit Ethernet Adapter.
The driver support Linux kernel 2.4.7 later. We had tested it
on the environments below.
. Red Hat v6.2 (update kernel to 2.4.7)
. Red Hat v7.0 (update kernel to 2.4.7)
. Red Hat v7.1 (kernel 2.4.7)
. Red Hat v7.2 (kernel 2.4.7-10)
Quick Install
=============
Install linux driver as following command::
1. make all
2. insmod dl2k.ko
3. ifconfig eth0 up 10.xxx.xxx.xxx netmask 255.0.0.0
^^^^^^^^^^^^^^^\ ^^^^^^^^\
IP NETMASK
Now eth0 should active, you can test it by "ping" or get more information by
"ifconfig". If tested ok, continue the next step.
4. ``cp dl2k.ko /lib/modules/`uname -r`/kernel/drivers/net``
5. Add the following line to /etc/modprobe.d/dl2k.conf::
alias eth0 dl2k
6. Run ``depmod`` to updated module indexes.
7. Run ``netconfig`` or ``netconf`` to create configuration script ifcfg-eth0
located at /etc/sysconfig/network-scripts or create it manually.
[see - Configuration Script Sample]
8. Driver will automatically load and configure at next boot time.
Compiling the Driver
====================
In Linux, NIC drivers are most commonly configured as loadable modules.
The approach of building a monolithic kernel has become obsolete. The driver
can be compiled as part of a monolithic kernel, but is strongly discouraged.
The remainder of this section assumes the driver is built as a loadable module.
In the Linux environment, it is a good idea to rebuild the driver from the
source instead of relying on a precompiled version. This approach provides
better reliability since a precompiled driver might depend on libraries or
kernel features that are not present in a given Linux installation.
The 3 files necessary to build Linux device driver are dl2k.c, dl2k.h and
Makefile. To compile, the Linux installation must include the gcc compiler,
the kernel source, and the kernel headers. The Linux driver supports Linux
Kernels 2.4.7. Copy the files to a directory and enter the following command
to compile and link the driver:
CD-ROM drive
------------
::
[root@XXX /] mkdir cdrom
[root@XXX /] mount -r -t iso9660 -o conv=auto /dev/cdrom /cdrom
[root@XXX /] cd root
[root@XXX /root] mkdir dl2k
[root@XXX /root] cd dl2k
[root@XXX dl2k] cp /cdrom/linux/dl2k.tgz /root/dl2k
[root@XXX dl2k] tar xfvz dl2k.tgz
[root@XXX dl2k] make all
Floppy disc drive
-----------------
::
[root@XXX /] cd root
[root@XXX /root] mkdir dl2k
[root@XXX /root] cd dl2k
[root@XXX dl2k] mcopy a:/linux/dl2k.tgz /root/dl2k
[root@XXX dl2k] tar xfvz dl2k.tgz
[root@XXX dl2k] make all
Installing the Driver
=====================
Manual Installation
-------------------
Once the driver has been compiled, it must be loaded, enabled, and bound
to a protocol stack in order to establish network connectivity. To load a
module enter the command::
insmod dl2k.o
or::
insmod dl2k.o <optional parameter> ; add parameter
---------------------------------------------------------
example::
insmod dl2k.o media=100mbps_hd
or::
insmod dl2k.o media=3
or::
insmod dl2k.o media=3,2 ; for 2 cards
---------------------------------------------------------
Please reference the list of the command line parameters supported by
the Linux device driver below.
The insmod command only loads the driver and gives it a name of the form
eth0, eth1, etc. To bring the NIC into an operational state,
it is necessary to issue the following command::
ifconfig eth0 up
Finally, to bind the driver to the active protocol (e.g., TCP/IP with
Linux), enter the following command::
ifup eth0
Note that this is meaningful only if the system can find a configuration
script that contains the necessary network information. A sample will be
given in the next paragraph.
The commands to unload a driver are as follows::
ifdown eth0
ifconfig eth0 down
rmmod dl2k.o
The following are the commands to list the currently loaded modules and
to see the current network configuration::
lsmod
ifconfig
Automated Installation
----------------------
This section describes how to install the driver such that it is
automatically loaded and configured at boot time. The following description
is based on a Red Hat 6.0/7.0 distribution, but it can easily be ported to
other distributions as well.
Red Hat v6.x/v7.x
-----------------
1. Copy dl2k.o to the network modules directory, typically
/lib/modules/2.x.x-xx/net or /lib/modules/2.x.x/kernel/drivers/net.
2. Locate the boot module configuration file, most commonly in the
/etc/modprobe.d/ directory. Add the following lines::
alias ethx dl2k
options dl2k <optional parameters>
where ethx will be eth0 if the NIC is the only ethernet adapter, eth1 if
one other ethernet adapter is installed, etc. Refer to the table in the
previous section for the list of optional parameters.
3. Locate the network configuration scripts, normally the
/etc/sysconfig/network-scripts directory, and create a configuration
script named ifcfg-ethx that contains network information.
4. Note that for most Linux distributions, Red Hat included, a configuration
utility with a graphical user interface is provided to perform steps 2
and 3 above.
Parameter Description
=====================
You can install this driver without any additional parameter. However, if you
are going to have extensive functions then it is necessary to set extra
parameter. Below is a list of the command line parameters supported by the
Linux device
driver.
=============================== ==============================================
mtu=packet_size Specifies the maximum packet size. default
is 1500.
media=media_type Specifies the media type the NIC operates at.
autosense Autosensing active media.
=========== =========================
10mbps_hd 10Mbps half duplex.
10mbps_fd 10Mbps full duplex.
100mbps_hd 100Mbps half duplex.
100mbps_fd 100Mbps full duplex.
1000mbps_fd 1000Mbps full duplex.
1000mbps_hd 1000Mbps half duplex.
0 Autosensing active media.
1 10Mbps half duplex.
2 10Mbps full duplex.
3 100Mbps half duplex.
4 100Mbps full duplex.
5 1000Mbps half duplex.
6 1000Mbps full duplex.
=========== =========================
By default, the NIC operates at autosense.
1000mbps_fd and 1000mbps_hd types are only
available for fiber adapter.
vlan=n Specifies the VLAN ID. If vlan=0, the
Virtual Local Area Network (VLAN) function is
disable.
jumbo=[0|1] Specifies the jumbo frame support. If jumbo=1,
the NIC accept jumbo frames. By default, this
function is disabled.
Jumbo frame usually improve the performance
int gigabit.
This feature need jumbo frame compatible
remote.
rx_coalesce=m Number of rx frame handled each interrupt.
rx_timeout=n Rx DMA wait time for an interrupt.
If set rx_coalesce > 0, hardware only assert
an interrupt for m frames. Hardware won't
assert rx interrupt until m frames received or
reach timeout of n * 640 nano seconds.
Set proper rx_coalesce and rx_timeout can
reduce congestion collapse and overload which
has been a bottleneck for high speed network.
For example, rx_coalesce=10 rx_timeout=800.
that is, hardware assert only 1 interrupt
for 10 frames received or timeout of 512 us.
tx_coalesce=n Number of tx frame handled each interrupt.
Set n > 1 can reduce the interrupts
congestion usually lower performance of
high speed network card. Default is 16.
tx_flow=[1|0] Specifies the Tx flow control. If tx_flow=0,
the Tx flow control disable else driver
autodetect.
rx_flow=[1|0] Specifies the Rx flow control. If rx_flow=0,
the Rx flow control enable else driver
autodetect.
=============================== ==============================================
Configuration Script Sample
===========================
Here is a sample of a simple configuration script::
DEVICE=eth0
USERCTL=no
ONBOOT=yes
POOTPROTO=none
BROADCAST=207.200.5.255
NETWORK=207.200.5.0
NETMASK=255.255.255.0
IPADDR=207.200.5.2
Troubleshooting
===============
Q1. Source files contain ^ M behind every line.
Make sure all files are Unix file format (no LF). Try the following
shell command to convert files::
cat dl2k.c | col -b > dl2k.tmp
mv dl2k.tmp dl2k.c
OR::
cat dl2k.c | tr -d "\r" > dl2k.tmp
mv dl2k.tmp dl2k.c
Q2: Could not find header files (``*.h``)?
To compile the driver, you need kernel header files. After
installing the kernel source, the header files are usually located in
/usr/src/linux/include, which is the default include directory configured
in Makefile. For some distributions, there is a copy of header files in
/usr/src/include/linux and /usr/src/include/asm, that you can change the
INCLUDEDIR in Makefile to /usr/include without installing kernel source.
Note that RH 7.0 didn't provide correct header files in /usr/include,
including those files will make a wrong version driver.
linux-7.2.3/Documentation/networking/device_drivers/ethernet/freescale/dpaa.rst
+269
View File
@@ -0,0 +1,269 @@
.. SPDX-License-Identifier: GPL-2.0
==============================
The QorIQ DPAA Ethernet Driver
==============================
Authors:
- Madalin Bucur <madalin.bucur@nxp.com>
- Camelia Groza <camelia.groza@nxp.com>
.. Contents
- DPAA Ethernet Overview
- DPAA Ethernet Supported SoCs
- Configuring DPAA Ethernet in your kernel
- DPAA Ethernet Frame Processing
- DPAA Ethernet Features
- DPAA IRQ Affinity and Receive Side Scaling
- Debugging
DPAA Ethernet Overview
======================
DPAA stands for Data Path Acceleration Architecture and it is a
set of networking acceleration IPs that are available on several
generations of SoCs, both on PowerPC and ARM64.
The Freescale DPAA architecture consists of a series of hardware blocks
that support Ethernet connectivity. The Ethernet driver depends upon the
following drivers in the Linux kernel:
- Peripheral Access Memory Unit (PAMU) (* needed only for PPC platforms)
drivers/iommu/fsl_*
- Frame Manager (FMan)
drivers/net/ethernet/freescale/fman
- Queue Manager (QMan), Buffer Manager (BMan)
drivers/soc/fsl/qbman
A simplified view of the dpaa_eth interfaces mapped to FMan MACs::
dpaa_eth /eth0\ ... /ethN\
driver | | | |
------------- ---- ----------- ---- -------------
-Ports / Tx Rx \ ... / Tx Rx \
FMan | | | |
-MACs | MAC0 | | MACN |
/ dtsec0 \ ... / dtsecN \ (or tgec)
/ \ / \(or memac)
--------- -------------- --- -------------- ---------
FMan, FMan Port, FMan SP, FMan MURAM drivers
---------------------------------------------------------
FMan HW blocks: MURAM, MACs, Ports, SP
---------------------------------------------------------
The dpaa_eth relation to the QMan, BMan and FMan::
________________________________
dpaa_eth / eth0 \
driver / \
--------- -^- -^- -^- --- ---------
QMan driver / \ / \ / \ \ / | BMan |
|Rx | |Rx | |Tx | |Tx | | driver |
--------- |Dfl| |Err| |Cnf| |FQs| | |
QMan HW |FQ | |FQ | |FQs| | | | |
/ \ / \ / \ \ / | |
--------- --- --- --- -v- ---------
| FMan QMI | |
| FMan HW FMan BMI | BMan HW |
----------------------- --------
where the acronyms used above (and in the code) are:
=============== ===========================================================
DPAA Data Path Acceleration Architecture
FMan DPAA Frame Manager
QMan DPAA Queue Manager
BMan DPAA Buffers Manager
QMI QMan interface in FMan
BMI BMan interface in FMan
FMan SP FMan Storage Profiles
MURAM Multi-user RAM in FMan
FQ QMan Frame Queue
Rx Dfl FQ default reception FQ
Rx Err FQ Rx error frames FQ
Tx Cnf FQ Tx confirmation FQs
Tx FQs transmission frame queues
dtsec datapath three speed Ethernet controller (10/100/1000 Mbps)
tgec ten gigabit Ethernet controller (10 Gbps)
memac multirate Ethernet MAC (10/100/1000/10000)
=============== ===========================================================
DPAA Ethernet Supported SoCs
============================
The DPAA drivers enable the Ethernet controllers present on the following SoCs:
PPC
- P1023
- P2041
- P3041
- P4080
- P5020
- P5040
- T1023
- T1024
- T1040
- T1042
- T2080
- T4240
- B4860
ARM
- LS1043A
- LS1046A
Configuring DPAA Ethernet in your kernel
========================================
To enable the DPAA Ethernet driver, the following Kconfig options are required::
# common for arch/arm64 and arch/powerpc platforms
CONFIG_FSL_DPAA=y
CONFIG_FSL_FMAN=y
CONFIG_FSL_DPAA_ETH=y
CONFIG_FSL_XGMAC_MDIO=y
# for arch/powerpc only
CONFIG_FSL_PAMU=y
# common options needed for the PHYs used on the RDBs
CONFIG_VITESSE_PHY=y
CONFIG_REALTEK_PHY=y
CONFIG_AQUANTIA_PHY=y
DPAA Ethernet Frame Processing
==============================
On Rx, buffers for the incoming frames are retrieved from the buffers found
in the dedicated interface buffer pool. The driver initializes and seeds these
with one page buffers.
On Tx, all transmitted frames are returned to the driver through Tx
confirmation frame queues. The driver is then responsible for freeing the
buffers. In order to do this properly, a backpointer is added to the buffer
before transmission that points to the skb. When the buffer returns to the
driver on a confirmation FQ, the skb can be correctly consumed.
DPAA Ethernet Features
======================
Currently the DPAA Ethernet driver enables the basic features required for
a Linux Ethernet driver. The support for advanced features will be added
gradually.
The driver has Rx and Tx checksum offloading for UDP and TCP. Currently the Rx
checksum offload feature is enabled by default and cannot be controlled through
ethtool. Also, rx-flow-hash and rx-hashing was added. The addition of RSS
provides a big performance boost for the forwarding scenarios, allowing
different traffic flows received by one interface to be processed by different
CPUs in parallel.
The driver has support for multiple prioritized Tx traffic classes. Priorities
range from 0 (lowest) to 3 (highest). These are mapped to HW workqueues with
strict priority levels. Each traffic class contains NR_CPU TX queues. By
default, only one traffic class is enabled and the lowest priority Tx queues
are used. Higher priority traffic classes can be enabled with the mqprio
qdisc. For example, all four traffic classes are enabled on an interface with
the following command. Furthermore, skb priority levels are mapped to traffic
classes as follows:
* priorities 0 to 3 - traffic class 0 (low priority)
* priorities 4 to 7 - traffic class 1 (medium-low priority)
* priorities 8 to 11 - traffic class 2 (medium-high priority)
* priorities 12 to 15 - traffic class 3 (high priority)
::
tc qdisc add dev <int> root handle 1: \
mqprio num_tc 4 map 0 0 0 0 1 1 1 1 2 2 2 2 3 3 3 3 hw 1
DPAA IRQ Affinity and Receive Side Scaling
==========================================
Traffic coming on the DPAA Rx queues or on the DPAA Tx confirmation
queues is seen by the CPU as ingress traffic on a certain portal.
The DPAA QMan portal interrupts are affined each to a certain CPU.
The same portal interrupt services all the QMan portal consumers.
By default the DPAA Ethernet driver enables RSS, making use of the
DPAA FMan Parser and Keygen blocks to distribute traffic on 128
hardware frame queues using a hash on IP v4/v6 source and destination
and L4 source and destination ports, in present in the received frame.
When RSS is disabled, all traffic received by a certain interface is
received on the default Rx frame queue. The default DPAA Rx frame
queues are configured to put the received traffic into a pool channel
that allows any available CPU portal to dequeue the ingress traffic.
The default frame queues have the HOLDACTIVE option set, ensuring that
traffic bursts from a certain queue are serviced by the same CPU.
This ensures a very low rate of frame reordering. A drawback of this
is that only one CPU at a time can service the traffic received by a
certain interface when RSS is not enabled.
To implement RSS, the DPAA Ethernet driver allocates an extra set of
128 Rx frame queues that are configured to dedicated channels, in a
round-robin manner. The mapping of the frame queues to CPUs is now
hardcoded, there is no indirection table to move traffic for a certain
FQ (hash result) to another CPU. The ingress traffic arriving on one
of these frame queues will arrive at the same portal and will always
be processed by the same CPU. This ensures intra-flow order preservation
and workload distribution for multiple traffic flows.
RSS can be turned off for a certain interface using ethtool, i.e.::
# ethtool -N fm1-mac9 rx-flow-hash tcp4 ""
To turn it back on, one needs to set rx-flow-hash for tcp4/6 or udp4/6::
# ethtool -N fm1-mac9 rx-flow-hash udp4 sfdn
There is no independent control for individual protocols, any command
run for one of tcp4|udp4|ah4|esp4|sctp4|tcp6|udp6|ah6|esp6|sctp6 is
going to control the rx-flow-hashing for all protocols on that interface.
Besides using the FMan Keygen computed hash for spreading traffic on the
128 Rx FQs, the DPAA Ethernet driver also sets the skb hash value when
the NETIF_F_RXHASH feature is on (active by default). This can be turned
on or off through ethtool, i.e.::
# ethtool -K fm1-mac9 rx-hashing off
# ethtool -k fm1-mac9 | grep hash
receive-hashing: off
# ethtool -K fm1-mac9 rx-hashing on
Actual changes:
receive-hashing: on
# ethtool -k fm1-mac9 | grep hash
receive-hashing: on
Please note that Rx hashing depends upon the rx-flow-hashing being on
for that interface - turning off rx-flow-hashing will also disable the
rx-hashing (without ethtool reporting it as off as that depends on the
NETIF_F_RXHASH feature flag).
Debugging
=========
The following statistics are exported for each interface through ethtool:
- interrupt count per CPU
- Rx packets count per CPU
- Tx packets count per CPU
- Tx confirmed packets count per CPU
- Tx S/G frames count per CPU
- Tx error count per CPU
- Rx error count per CPU
- Rx error count per type
- congestion related statistics:
- congestion status
- time spent in congestion
- number of time the device entered congestion
- dropped packets count per cause
The driver also exports the following information in sysfs:
- the FQ IDs for each FQ type
/sys/devices/platform/soc/<addr>.fman/<addr>.ethernet/dpaa-ethernet.<id>/net/fm<nr>-mac<nr>/fqids
- the ID of the buffer pool in use
/sys/devices/platform/soc/<addr>.fman/<addr>.ethernet/dpaa-ethernet.<id>/net/fm<nr>-mac<nr>/bpids
linux-7.2.3/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/dpio-driver.rst
+161
View File
@@ -0,0 +1,161 @@
.. include:: <isonum.txt>
===================================
DPAA2 DPIO (Data Path I/O) Overview
===================================
:Copyright: |copy| 2016-2018 NXP
This document provides an overview of the Freescale DPAA2 DPIO
drivers
Introduction
============
A DPAA2 DPIO (Data Path I/O) is a hardware object that provides
interfaces to enqueue and dequeue frames to/from network interfaces
and other accelerators. A DPIO also provides hardware buffer
pool management for network interfaces.
This document provides an overview the Linux DPIO driver, its
subcomponents, and its APIs.
See
Documentation/networking/device_drivers/ethernet/freescale/dpaa2/overview.rst
for a general overview of DPAA2 and the general DPAA2 driver architecture
in Linux.
Driver Overview
---------------
The DPIO driver is bound to DPIO objects discovered on the fsl-mc bus and
provides services that:
A. allow other drivers, such as the Ethernet driver, to enqueue and dequeue
frames for their respective objects
B. allow drivers to register callbacks for data availability notifications
when data becomes available on a queue or channel
C. allow drivers to manage hardware buffer pools
The Linux DPIO driver consists of 3 primary components--
DPIO object driver-- fsl-mc driver that manages the DPIO object
DPIO service-- provides APIs to other Linux drivers for services
QBman portal interface-- sends portal commands, gets responses::
fsl-mc other
bus drivers
| |
+---+----+ +------+-----+
|DPIO obj| |DPIO service|
| driver |---| (DPIO) |
+--------+ +------+-----+
|
+------+-----+
| QBman |
| portal i/f |
+------------+
|
hardware
The diagram below shows how the DPIO driver components fit with the other
DPAA2 Linux driver components::
+------------+
| OS Network |
| Stack |
+------------+ +------------+
| Allocator |. . . . . . . | Ethernet |
|(DPMCP,DPBP)| | (DPNI) |
+-.----------+ +---+---+----+
. . ^ |
. . <data avail, | |<enqueue,
. . tx confirm> | | dequeue>
+-------------+ . | |
| DPRC driver | . +--------+ +------------+
| (DPRC) | . . |DPIO obj| |DPIO service|
+----------+--+ | driver |-| (DPIO) |
| +--------+ +------+-----+
|<dev add/remove> +------|-----+
| | QBman |
+----+--------------+ | portal i/f |
| MC-bus driver | +------------+
| | |
| /soc/fsl-mc | |
+-------------------+ |
|
=========================================|=========|========================
+-+--DPIO---|-----------+
| | |
| QBman Portal |
+-----------------------+
============================================================================
DPIO Object Driver (dpio-driver.c)
----------------------------------
The dpio-driver component registers with the fsl-mc bus to handle objects of
type "dpio". The implementation of probe() handles basic initialization
of the DPIO including mapping of the DPIO regions (the QBman SW portal)
and initializing interrupts and registering irq handlers. The dpio-driver
registers the probed DPIO with dpio-service.
DPIO service (dpio-service.c, dpaa2-io.h)
------------------------------------------
The dpio service component provides queuing, notification, and buffers
management services to DPAA2 drivers, such as the Ethernet driver. A system
will typically allocate 1 DPIO object per CPU to allow queuing operations
to happen simultaneously across all CPUs.
Notification handling
dpaa2_io_service_register()
dpaa2_io_service_deregister()
dpaa2_io_service_rearm()
Queuing
dpaa2_io_service_pull_fq()
dpaa2_io_service_pull_channel()
dpaa2_io_service_enqueue_fq()
dpaa2_io_service_enqueue_qd()
dpaa2_io_store_create()
dpaa2_io_store_destroy()
dpaa2_io_store_next()
Buffer pool management
dpaa2_io_service_release()
dpaa2_io_service_acquire()
QBman portal interface (qbman-portal.c)
---------------------------------------
The qbman-portal component provides APIs to do the low level hardware
bit twiddling for operations such as:
- initializing Qman software portals
- building and sending portal commands
- portal interrupt configuration and processing
The qbman-portal APIs are not public to other drivers, and are
only used by dpio-service.
Other (dpaa2-fd.h, dpaa2-global.h)
----------------------------------
Frame descriptor and scatter-gather definitions and the APIs used to
manipulate them are defined in dpaa2-fd.h.
Dequeue result struct and parsing APIs are defined in dpaa2-global.h.
linux-7.2.3/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/ethernet-driver.rst
+186
View File
@@ -0,0 +1,186 @@
.. SPDX-License-Identifier: GPL-2.0
.. include:: <isonum.txt>
===============================
DPAA2 Ethernet driver
===============================
:Copyright: |copy| 2017-2018 NXP
This file provides documentation for the Freescale DPAA2 Ethernet driver.
Supported Platforms
===================
This driver provides networking support for Freescale DPAA2 SoCs, e.g.
LS2080A, LS2088A, LS1088A.
Architecture Overview
=====================
Unlike regular NICs, in the DPAA2 architecture there is no single hardware block
representing network interfaces; instead, several separate hardware resources
concur to provide the networking functionality:
- network interfaces
- queues, channels
- buffer pools
- MAC/PHY
All hardware resources are allocated and configured through the Management
Complex (MC) portals. MC abstracts most of these resources as DPAA2 objects
and exposes ABIs through which they can be configured and controlled. A few
hardware resources, like queues, do not have a corresponding MC object and
are treated as internal resources of other objects.
For a more detailed description of the DPAA2 architecture and its object
abstractions see
*Documentation/networking/device_drivers/ethernet/freescale/dpaa2/overview.rst*.
Each Linux net device is built on top of a Datapath Network Interface (DPNI)
object and uses Buffer Pools (DPBPs), I/O Portals (DPIOs) and Concentrators
(DPCONs).
Configuration interface::
-----------------------
| DPAA2 Ethernet Driver |
-----------------------
. . .
. . .
. . . . . . . . . . . .
. . .
. . .
---------- ---------- -----------
| DPBP API | | DPNI API | | DPCON API |
---------- ---------- -----------
. . . software
======= . ========== . ============ . ===================
. . . hardware
------------------------------------------
| MC hardware portals |
------------------------------------------
. . .
. . .
------ ------ -------
| DPBP | | DPNI | | DPCON |
------ ------ -------
The DPNIs are network interfaces without a direct one-on-one mapping to PHYs.
DPBPs represent hardware buffer pools. Packet I/O is performed in the context
of DPCON objects, using DPIO portals for managing and communicating with the
hardware resources.
Datapath (I/O) interface::
-----------------------------------------------
| DPAA2 Ethernet Driver |
-----------------------------------------------
| ^ ^ | |
| | | | |
enqueue| dequeue| data | dequeue| seed |
(Tx) | (Rx, TxC)| avail.| request| buffers|
| | notify| | |
| | | | |
V | | V V
-----------------------------------------------
| DPIO Driver |
-----------------------------------------------
| | | | | software
| | | | | ================
| | | | | hardware
-----------------------------------------------
| I/O hardware portals |
-----------------------------------------------
| ^ ^ | |
| | | | |
| | | V |
V | ================ V
---------------------- | -------------
queues ---------------------- | | Buffer pool |
---------------------- | -------------
=======================
Channel
Datapath I/O (DPIO) portals provide enqueue and dequeue services, data
availability notifications and buffer pool management. DPIOs are shared between
all DPAA2 objects (and implicitly all DPAA2 kernel drivers) that work with data
frames, but must be affine to the CPUs for the purpose of traffic distribution.
Frames are transmitted and received through hardware frame queues, which can be
grouped in channels for the purpose of hardware scheduling. The Ethernet driver
enqueues TX frames on egress queues and after transmission is complete a TX
confirmation frame is sent back to the CPU.
When frames are available on ingress queues, a data availability notification
is sent to the CPU; notifications are raised per channel, so even if multiple
queues in the same channel have available frames, only one notification is sent.
After a channel fires a notification, is must be explicitly rearmed.
Each network interface can have multiple Rx, Tx and confirmation queues affined
to CPUs, and one channel (DPCON) for each CPU that services at least one queue.
DPCONs are used to distribute ingress traffic to different CPUs via the cores'
affine DPIOs.
The role of hardware buffer pools is storage of ingress frame data. Each network
interface has a privately owned buffer pool which it seeds with kernel allocated
buffers.
DPNIs are decoupled from PHYs; a DPNI can be connected to a PHY through a DPMAC
object or to another DPNI through an internal link, but the connection is
managed by MC and completely transparent to the Ethernet driver.
::
--------- --------- ---------
| eth if1 | | eth if2 | | eth ifn |
--------- --------- ---------
. . .
. . .
. . .
---------------------------
| DPAA2 Ethernet Driver |
---------------------------
. . .
. . .
. . .
------ ------ ------ -------
| DPNI | | DPNI | | DPNI | | DPMAC |----+
------ ------ ------ ------- |
| | | | |
| | | | -----
=========== ================== | PHY |
-----
Creating a Network Interface
============================
A net device is created for each DPNI object probed on the MC bus. Each DPNI has
a number of properties which determine the network interface configuration
options and associated hardware resources.
DPNI objects (and the other DPAA2 objects needed for a network interface) can be
added to a container on the MC bus in one of two ways: statically, through a
Datapath Layout Binary file (DPL) that is parsed by MC at boot time; or created
dynamically at runtime, via the DPAA2 objects APIs.
Features & Offloads
===================
Hardware checksum offloading is supported for TCP and UDP over IPv4/6 frames.
The checksum offloads can be independently configured on RX and TX through
ethtool.
Hardware offload of unicast and multicast MAC filtering is supported on the
ingress path and permanently enabled.
Scatter-gather frames are supported on both RX and TX paths. On TX, SG support
is configurable via ethtool; on RX it is always enabled.
The DPAA2 hardware can process jumbo Ethernet frames of up to 10K bytes.
The Ethernet driver defines a static flow hashing scheme that distributes
traffic based on a 5-tuple key: src IP, dst IP, IP proto, L4 src port,
L4 dst port. No user configuration is supported for now.
Hardware specific statistics for the network interface as well as some
non-standard driver stats can be consulted through ethtool -S option.
linux-7.2.3/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/index.rst
+12
View File
@@ -0,0 +1,12 @@
===================
DPAA2 Documentation
===================
.. toctree::
:maxdepth: 1
overview
dpio-driver
ethernet-driver
mac-phy-support
switch-driver
linux-7.2.3/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/mac-phy-support.rst
+194
View File
@@ -0,0 +1,194 @@
.. SPDX-License-Identifier: GPL-2.0
.. include:: <isonum.txt>
=======================
DPAA2 MAC / PHY support
=======================
:Copyright: |copy| 2019 NXP
Overview
--------
The DPAA2 MAC / PHY support consists of a set of APIs that help DPAA2 network
drivers (dpaa2-eth, dpaa2-ethsw) interact with the PHY library.
DPAA2 Software Architecture
---------------------------
Among other DPAA2 objects, the fsl-mc bus exports DPNI objects (abstracting a
network interface) and DPMAC objects (abstracting a MAC). The dpaa2-eth driver
probes on the DPNI object and connects to and configures a DPMAC object with
the help of phylink.
Data connections may be established between a DPNI and a DPMAC, or between two
DPNIs. Depending on the connection type, the netif_carrier_[on/off] is handled
directly by the dpaa2-eth driver or by phylink.
.. code-block:: none
Sources of abstracted link state information presented by the MC firmware
+--------------------------------------+
+------------+ +---------+ | xgmac_mdio |
| net_device | | phylink |--| +-----+ +-----+ +-----+ +-----+ |
+------------+ +---------+ | | PHY | | PHY | | PHY | | PHY | |
| | | +-----+ +-----+ +-----+ +-----+ |
+------------------------------------+ | External MDIO bus |
| dpaa2-eth | +--------------------------------------+
+------------------------------------+
| | Linux
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | MC firmware
| /| V
+----------+ / | +----------+
| | / | | |
| | | | | |
| DPNI |<------| |<------| DPMAC |
| | | | | |
| | \ |<---+ | |
+----------+ \ | | +----------+
\| |
|
+--------------------------------------+
| MC firmware polling MAC PCS for link |
| +-----+ +-----+ +-----+ +-----+ |
| | PCS | | PCS | | PCS | | PCS | |
| +-----+ +-----+ +-----+ +-----+ |
| Internal MDIO bus |
+--------------------------------------+
Depending on an MC firmware configuration setting, each MAC may be in one of two modes:
- DPMAC_LINK_TYPE_FIXED: the link state management is handled exclusively by
the MC firmware by polling the MAC PCS. Without the need to register a
phylink instance, the dpaa2-eth driver will not bind to the connected dpmac
object at all.
- DPMAC_LINK_TYPE_PHY: The MC firmware is left waiting for link state update
events, but those are in fact passed strictly between the dpaa2-mac (based on
phylink) and its attached net_device driver (dpaa2-eth, dpaa2-ethsw),
effectively bypassing the firmware.
Implementation
--------------
At probe time or when a DPNI's endpoint is dynamically changed, the dpaa2-eth
is responsible to find out if the peer object is a DPMAC and if this is the
case, to integrate it with PHYLINK using the dpaa2_mac_connect() API, which
will do the following:
- look up the device tree for PHYLINK-compatible of binding (phy-handle)
- will create a PHYLINK instance associated with the received net_device
- connect to the PHY using phylink_of_phy_connect()
The following phylink_mac_ops callback are implemented:
- .validate() will populate the supported linkmodes with the MAC capabilities
only when the phy_interface_t is RGMII_* (at the moment, this is the only
link type supported by the driver).
- .mac_config() will configure the MAC in the new configuration using the
dpmac_set_link_state() MC firmware API.
- .mac_link_up() / .mac_link_down() will update the MAC link using the same
API described above.
At driver unbind() or when the DPNI object is disconnected from the DPMAC, the
dpaa2-eth driver calls dpaa2_mac_disconnect() which will, in turn, disconnect
from the PHY and destroy the PHYLINK instance.
In case of a DPNI-DPMAC connection, an 'ip link set dev eth0 up' would start
the following sequence of operations:
(1) phylink_start() called from .dev_open().
(2) The .mac_config() and .mac_link_up() callbacks are called by PHYLINK.
(3) In order to configure the HW MAC, the MC Firmware API
dpmac_set_link_state() is called.
(4) The firmware will eventually setup the HW MAC in the new configuration.
(5) A netif_carrier_on() call is made directly from PHYLINK on the associated
net_device.
(6) The dpaa2-eth driver handles the LINK_STATE_CHANGE irq in order to
enable/disable Rx taildrop based on the pause frame settings.
.. code-block:: none
+---------+ +---------+
| PHYLINK |-------------->| eth0 |
+---------+ (5) +---------+
(1) ^ |
| |
| v (2)
+-----------------------------------+
| dpaa2-eth |
+-----------------------------------+
| ^ (6)
| |
v (3) |
+---------+---------------+---------+
| DPMAC | | DPNI |
+---------+ +---------+
| MC Firmware |
+-----------------------------------+
|
|
v (4)
+-----------------------------------+
| HW MAC |
+-----------------------------------+
In case of a DPNI-DPNI connection, a usual sequence of operations looks like
the following:
(1) ip link set dev eth0 up
(2) The dpni_enable() MC API called on the associated fsl_mc_device.
(3) ip link set dev eth1 up
(4) The dpni_enable() MC API called on the associated fsl_mc_device.
(5) The LINK_STATE_CHANGED irq is received by both instances of the dpaa2-eth
driver because now the operational link state is up.
(6) The netif_carrier_on() is called on the exported net_device from
link_state_update().
.. code-block:: none
+---------+ +---------+
| eth0 | | eth1 |
+---------+ +---------+
| ^ ^ |
| | | |
(1) v | (6) (6) | v (3)
+---------+ +---------+
|dpaa2-eth| |dpaa2-eth|
+---------+ +---------+
| ^ ^ |
| | | |
(2) v | (5) (5) | v (4)
+---------+---------------+---------+
| DPNI | | DPNI |
+---------+ +---------+
| MC Firmware |
+-----------------------------------+
Exported API
------------
Any DPAA2 driver that drivers endpoints of DPMAC objects should service its
_EVENT_ENDPOINT_CHANGED irq and connect/disconnect from the associated DPMAC
when necessary using the below listed API::
- int dpaa2_mac_connect(struct dpaa2_mac *mac);
- void dpaa2_mac_disconnect(struct dpaa2_mac *mac);
A phylink integration is necessary only when the partner DPMAC is not of
``TYPE_FIXED``. This means it is either of ``TYPE_PHY``, or of
``TYPE_BACKPLANE`` (the difference being the two that in the ``TYPE_BACKPLANE``
mode, the MC firmware does not access the PCS registers). One can check for
this condition using the following helper::
- static inline bool dpaa2_mac_is_type_phy(struct dpaa2_mac *mac);
Before connection to a MAC, the caller must allocate and populate the
dpaa2_mac structure with the associated net_device, a pointer to the MC portal
to be used and the actual fsl_mc_device structure of the DPMAC.
linux-7.2.3/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/overview.rst
+406
View File
@@ -0,0 +1,406 @@
.. include:: <isonum.txt>
=========================================================
DPAA2 (Data Path Acceleration Architecture Gen2) Overview
=========================================================
:Copyright: |copy| 2015 Freescale Semiconductor Inc.
:Copyright: |copy| 2018 NXP
This document provides an overview of the Freescale DPAA2 architecture
and how it is integrated into the Linux kernel.
Introduction
============
DPAA2 is a hardware architecture designed for high-speeed network
packet processing. DPAA2 consists of sophisticated mechanisms for
processing Ethernet packets, queue management, buffer management,
autonomous L2 switching, virtual Ethernet bridging, and accelerator
(e.g. crypto) sharing.
A DPAA2 hardware component called the Management Complex (or MC) manages the
DPAA2 hardware resources. The MC provides an object-based abstraction for
software drivers to use the DPAA2 hardware.
The MC uses DPAA2 hardware resources such as queues, buffer pools, and
network ports to create functional objects/devices such as network
interfaces, an L2 switch, or accelerator instances.
The MC provides memory-mapped I/O command interfaces (MC portals)
which DPAA2 software drivers use to operate on DPAA2 objects.
The diagram below shows an overview of the DPAA2 resource management
architecture::
+--------------------------------------+
| OS |
| DPAA2 drivers |
| | |
+-----------------------------|--------+
|
| (create,discover,connect
| config,use,destroy)
|
DPAA2 |
+------------------------| mc portal |-+
| | |
| +- - - - - - - - - - - - -V- - -+ |
| | | |
| | Management Complex (MC) | |
| | | |
| +- - - - - - - - - - - - - - - -+ |
| |
| Hardware Hardware |
| Resources Objects |
| --------- ------- |
| -queues -DPRC |
| -buffer pools -DPMCP |
| -Eth MACs/ports -DPIO |
| -network interface -DPNI |
| profiles -DPMAC |
| -queue portals -DPBP |
| -MC portals ... |
| ... |
| |
+--------------------------------------+
The MC mediates operations such as create, discover,
connect, configuration, and destroy. Fast-path operations
on data, such as packet transmit/receive, are not mediated by
the MC and are done directly using memory mapped regions in
DPIO objects.
Overview of DPAA2 Objects
=========================
The section provides a brief overview of some key DPAA2 objects.
A simple scenario is described illustrating the objects involved
in creating a network interfaces.
DPRC (Datapath Resource Container)
----------------------------------
A DPRC is a container object that holds all the other
types of DPAA2 objects. In the example diagram below there
are 8 objects of 5 types (DPMCP, DPIO, DPBP, DPNI, and DPMAC)
in the container.
::
+---------------------------------------------------------+
| DPRC |
| |
| +-------+ +-------+ +-------+ +-------+ +-------+ |
| | DPMCP | | DPIO | | DPBP | | DPNI | | DPMAC | |
| +-------+ +-------+ +-------+ +---+---+ +---+---+ |
| | DPMCP | | DPIO | |
| +-------+ +-------+ |
| | DPMCP | |
| +-------+ |
| |
+---------------------------------------------------------+
From the point of view of an OS, a DPRC behaves similar to a plug and
play bus, like PCI. DPRC commands can be used to enumerate the contents
of the DPRC, discover the hardware objects present (including mappable
regions and interrupts).
::
DPRC.1 (bus)
|
+--+--------+-------+-------+-------+
| | | | |
DPMCP.1 DPIO.1 DPBP.1 DPNI.1 DPMAC.1
DPMCP.2 DPIO.2
DPMCP.3
Hardware objects can be created and destroyed dynamically, providing
the ability to hot plug/unplug objects in and out of the DPRC.
A DPRC has a mappable MMIO region (an MC portal) that can be used
to send MC commands. It has an interrupt for status events (like
hotplug).
All objects in a container share the same hardware "isolation context".
This means that with respect to an IOMMU the isolation granularity
is at the DPRC (container) level, not at the individual object
level.
DPRCs can be defined statically and populated with objects
via a config file passed to the MC when firmware starts it.
DPAA2 Objects for an Ethernet Network Interface
-----------------------------------------------
A typical Ethernet NIC is monolithic-- the NIC device contains TX/RX
queuing mechanisms, configuration mechanisms, buffer management,
physical ports, and interrupts. DPAA2 uses a more granular approach
utilizing multiple hardware objects. Each object provides specialized
functions. Groups of these objects are used by software to provide
Ethernet network interface functionality. This approach provides
efficient use of finite hardware resources, flexibility, and
performance advantages.
The diagram below shows the objects needed for a simple
network interface configuration on a system with 2 CPUs.
::
+---+---+ +---+---+
CPU0 CPU1
+---+---+ +---+---+
| |
+---+---+ +---+---+
DPIO DPIO
+---+---+ +---+---+
\ /
\ /
\ /
+---+---+
DPNI --- DPBP,DPMCP
+---+---+
|
|
+---+---+
DPMAC
+---+---+
|
port/PHY
Below the objects are described. For each object a brief description
is provided along with a summary of the kinds of operations the object
supports and a summary of key resources of the object (MMIO regions
and IRQs).
DPMAC (Datapath Ethernet MAC)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Represents an Ethernet MAC, a hardware device that connects to an Ethernet
PHY and allows physical transmission and reception of Ethernet frames.
- MMIO regions: none
- IRQs: DPNI link change
- commands: set link up/down, link config, get stats,
IRQ config, enable, reset
DPNI (Datapath Network Interface)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Contains TX/RX queues, network interface configuration, and RX buffer pool
configuration mechanisms. The TX/RX queues are in memory and are identified
by queue number.
- MMIO regions: none
- IRQs: link state
- commands: port config, offload config, queue config,
parse/classify config, IRQ config, enable, reset
DPIO (Datapath I/O)
~~~~~~~~~~~~~~~~~~~
Provides interfaces to enqueue and dequeue
packets and do hardware buffer pool management operations. The DPAA2
architecture separates the mechanism to access queues (the DPIO object)
from the queues themselves. The DPIO provides an MMIO interface to
enqueue/dequeue packets. To enqueue something a descriptor is written
to the DPIO MMIO region, which includes the target queue number.
There will typically be one DPIO assigned to each CPU. This allows all
CPUs to simultaneously perform enqueue/dequeued operations. DPIOs are
expected to be shared by different DPAA2 drivers.
- MMIO regions: queue operations, buffer management
- IRQs: data availability, congestion notification, buffer
pool depletion
- commands: IRQ config, enable, reset
DPBP (Datapath Buffer Pool)
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Represents a hardware buffer pool.
- MMIO regions: none
- IRQs: none
- commands: enable, reset
DPMCP (Datapath MC Portal)
~~~~~~~~~~~~~~~~~~~~~~~~~~
Provides an MC command portal.
Used by drivers to send commands to the MC to manage
objects.
- MMIO regions: MC command portal
- IRQs: command completion
- commands: IRQ config, enable, reset
Object Connections
==================
Some objects have explicit relationships that must
be configured:
- DPNI <--> DPMAC
- DPNI <--> DPNI
- DPNI <--> L2-switch-port
A DPNI must be connected to something such as a DPMAC,
another DPNI, or L2 switch port. The DPNI connection
is made via a DPRC command.
::
+-------+ +-------+
| DPNI | | DPMAC |
+---+---+ +---+---+
| |
+==========+
- DPNI <--> DPBP
A network interface requires a 'buffer pool' (DPBP
object) which provides a list of pointers to memory
where received Ethernet data is to be copied. The
Ethernet driver configures the DPBPs associated with
the network interface.
Interrupts
==========
All interrupts generated by DPAA2 objects are message
interrupts. At the hardware level message interrupts
generated by devices will normally have 3 components--
1) a non-spoofable 'device-id' expressed on the hardware
bus, 2) an address, 3) a data value.
In the case of DPAA2 devices/objects, all objects in the
same container/DPRC share the same 'device-id'.
For ARM-based SoC this is the same as the stream ID.
DPAA2 Linux Drivers Overview
============================
This section provides an overview of the Linux kernel drivers for
DPAA2-- 1) the bus driver and associated "DPAA2 infrastructure"
drivers and 2) functional object drivers (such as Ethernet).
As described previously, a DPRC is a container that holds the other
types of DPAA2 objects. It is functionally similar to a plug-and-play
bus controller.
Each object in the DPRC is a Linux "device" and is bound to a driver.
The diagram below shows the Linux drivers involved in a networking
scenario and the objects bound to each driver. A brief description
of each driver follows.
::
+------------+
| OS Network |
| Stack |
+------------+ +------------+
| Allocator |. . . . . . . | Ethernet |
|(DPMCP,DPBP)| | (DPNI) |
+-.----------+ +---+---+----+
. . ^ |
. . <data avail, | | <enqueue,
. . tx confirm> | | dequeue>
+-------------+ . | |
| DPRC driver | . +---+---V----+ +---------+
| (DPRC) | . . . . . .| DPIO driver| | MAC |
+----------+--+ | (DPIO) | | (DPMAC) |
| +------+-----+ +-----+---+
|<dev add/remove> | |
| | |
+--------+----------+ | +--+---+
| MC-bus driver | | | PHY |
| | | |driver|
| /bus/fsl-mc | | +--+---+
+-------------------+ | |
| |
========================= HARDWARE =========|=================|======
DPIO |
| |
DPNI---DPBP |
| |
DPMAC |
| |
PHY ---------------+
============================================|========================
A brief description of each driver is provided below.
MC-bus driver
-------------
The MC-bus driver is a platform driver and is probed from a
node in the device tree (compatible "fsl,qoriq-mc") passed in by boot
firmware. It is responsible for bootstrapping the DPAA2 kernel
infrastructure.
Key functions include:
- registering a new bus type named "fsl-mc" with the kernel,
and implementing bus call-backs (e.g. match/uevent/dev_groups)
- implementing APIs for DPAA2 driver registration and for device
add/remove
- creates an MSI IRQ domain
- doing a 'device add' to expose the 'root' DPRC, in turn triggering
a bind of the root DPRC to the DPRC driver
The binding for the MC-bus device-tree node can be consulted at
*Documentation/devicetree/bindings/misc/fsl,qoriq-mc.yaml*.
The sysfs bind/unbind interfaces for the MC-bus can be consulted at
*Documentation/ABI/testing/sysfs-bus-fsl-mc*.
DPRC driver
-----------
The DPRC driver is bound to DPRC objects and does runtime management
of a bus instance. It performs the initial bus scan of the DPRC
and handles interrupts for container events such as hot plug by
re-scanning the DPRC.
Allocator
---------
Certain objects such as DPMCP and DPBP are generic and fungible,
and are intended to be used by other drivers. For example,
the DPAA2 Ethernet driver needs:
- DPMCPs to send MC commands, to configure network interfaces
- DPBPs for network buffer pools
The allocator driver registers for these allocatable object types
and those objects are bound to the allocator when the bus is probed.
The allocator maintains a pool of objects that are available for
allocation by other DPAA2 drivers.
DPIO driver
-----------
The DPIO driver is bound to DPIO objects and provides services that allow
other drivers such as the Ethernet driver to enqueue and dequeue data for
their respective objects.
Key services include:
- data availability notifications
- hardware queuing operations (enqueue and dequeue of data)
- hardware buffer pool management
To transmit a packet the Ethernet driver puts data on a queue and
invokes a DPIO API. For receive, the Ethernet driver registers
a data availability notification callback. To dequeue a packet
a DPIO API is used.
There is typically one DPIO object per physical CPU for optimum
performance, allowing different CPUs to simultaneously enqueue
and dequeue data.
The DPIO driver operates on behalf of all DPAA2 drivers
active in the kernel-- Ethernet, crypto, compression,
etc.
Ethernet driver
---------------
The Ethernet driver is bound to a DPNI and implements the kernel
interfaces needed to connect the DPAA2 network interface to
the network stack.
Each DPNI corresponds to a Linux network interface.
MAC driver
----------
An Ethernet PHY is an off-chip, board specific component and is managed
by the appropriate PHY driver via an mdio bus. The MAC driver
plays a role of being a proxy between the PHY driver and the
MC. It does this proxy via the MC commands to a DPMAC object.
If the PHY driver signals a link change, the MAC driver notifies
the MC via a DPMAC command. If a network interface is brought
up or down, the MC notifies the DPMAC driver via an interrupt and
the driver can take appropriate action.
linux-7.2.3/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/switch-driver.rst
+217
View File
@@ -0,0 +1,217 @@
.. SPDX-License-Identifier: GPL-2.0
.. include:: <isonum.txt>
===================
DPAA2 Switch driver
===================
:Copyright: |copy| 2021 NXP
The DPAA2 Switch driver probes on the Datapath Switch (DPSW) object which can
be instantiated on the following DPAA2 SoCs and their variants: LS2088A and
LX2160A.
The driver uses the switch device driver model and exposes each switch port as
a network interface, which can be included in a bridge or used as a standalone
interface. Traffic switched between ports is offloaded into the hardware.
The DPSW can have ports connected to DPNIs or to DPMACs for external access.
::
[ethA] [ethB] [ethC] [ethD] [ethE] [ethF]
: : : : : :
: : : : : :
[dpaa2-eth] [dpaa2-eth] [ dpaa2-switch ]
: : : : : : kernel
=============================================================================
: : : : : : hardware
[DPNI] [DPNI] [============= DPSW =================]
| | | | | |
| ---------- | [DPMAC] [DPMAC]
------------------------------- | |
| |
[PHY] [PHY]
Creating an Ethernet Switch
===========================
The dpaa2-switch driver probes on DPSW devices found on the fsl-mc bus. These
devices can be either created statically through the boot time configuration
file - DataPath Layout (DPL) - or at runtime using the DPAA2 object APIs
(incorporated already into the restool userspace tool).
At the moment, the dpaa2-switch driver imposes the following restrictions on
the DPSW object that it will probe:
* The minimum number of FDBs should be at least equal to the number of switch
interfaces. This is necessary so that separation of switch ports can be
done, ie when not under a bridge, each switch port will have its own FDB.
::
fsl_dpaa2_switch dpsw.0: The number of FDBs is lower than the number of ports, cannot probe
* Both the broadcast and flooding configuration should be per FDB. This
enables the driver to restrict the broadcast and flooding domains of each
FDB depending on the switch ports that are sharing it (aka are under the
same bridge).
::
fsl_dpaa2_switch dpsw.0: Flooding domain is not per FDB, cannot probe
fsl_dpaa2_switch dpsw.0: Broadcast domain is not per FDB, cannot probe
* The control interface of the switch should not be disabled
(DPSW_OPT_CTRL_IF_DIS not passed as a create time option). Without the
control interface, the driver is not capable to provide proper Rx/Tx traffic
support on the switch port netdevices.
::
fsl_dpaa2_switch dpsw.0: Control Interface is disabled, cannot probe
Besides the configuration of the actual DPSW object, the dpaa2-switch driver
will need the following DPAA2 objects:
* 1 DPMCP - A Management Command Portal object is needed for any interaction
with the MC firmware.
* 1 DPBP - A Buffer Pool is used for seeding buffers intended for the Rx path
on the control interface.
* Access to at least one DPIO object (Software Portal) is needed for any
enqueue/dequeue operation to be performed on the control interface queues.
The DPIO object will be shared, no need for a private one.
Switching features
==================
The driver supports the configuration of L2 forwarding rules in hardware for
port bridging as well as standalone usage of the independent switch interfaces.
The hardware is not configurable with respect to VLAN awareness, thus any DPAA2
switch port should be used only in usecases with a VLAN aware bridge::
$ ip link add dev br0 type bridge vlan_filtering 1
$ ip link add dev br1 type bridge
$ ip link set dev ethX master br1
Error: fsl_dpaa2_switch: Cannot join a VLAN-unaware bridge
Topology and loop detection through STP is supported when ``stp_state 1`` is
used at bridge create ::
$ ip link add dev br0 type bridge vlan_filtering 1 stp_state 1
L2 FDB manipulation (add/delete/dump) is supported.
HW FDB learning can be configured on each switch port independently through
bridge commands. When the HW learning is disabled, a fast age procedure will be
run and any previously learnt addresses will be removed.
::
$ bridge link set dev ethX learning off
$ bridge link set dev ethX learning on
Restricting the unknown unicast and multicast flooding domain is supported, but
not independently of each other::
$ ip link set dev ethX type bridge_slave flood off mcast_flood off
$ ip link set dev ethX type bridge_slave flood off mcast_flood on
Error: fsl_dpaa2_switch: Cannot configure multicast flooding independently of unicast.
Broadcast flooding on a switch port can be disabled/enabled through the brport sysfs::
$ echo 0 > /sys/bus/fsl-mc/devices/dpsw.Y/net/ethX/brport/broadcast_flood
Offloads
========
Routing actions (redirect, trap, drop)
--------------------------------------
The DPAA2 switch is able to offload flow-based redirection of packets making
use of ACL tables. Shared filter blocks are supported by sharing a single ACL
table between multiple ports.
The following flow keys are supported:
* Ethernet: dst_mac/src_mac
* IPv4: dst_ip/src_ip/ip_proto/tos
* VLAN: vlan_id/vlan_prio/vlan_tpid/vlan_dei
* L4: dst_port/src_port
Also, the matchall filter can be used to redirect the entire traffic received
on a port.
As per flow actions, the following are supported:
* drop
* mirred egress redirect
* trap
Each ACL entry (filter) can be setup with only one of the listed
actions.
Example 1: send frames received on eth4 with a SA of 00:01:02:03:04:05 to the
CPU::
$ tc qdisc add dev eth4 clsact
$ tc filter add dev eth4 ingress flower src_mac 00:01:02:03:04:05 skip_sw action trap
Example 2: drop frames received on eth4 with VID 100 and PCP of 3::
$ tc filter add dev eth4 ingress protocol 802.1q flower skip_sw vlan_id 100 vlan_prio 3 action drop
Example 3: redirect all frames received on eth4 to eth1::
$ tc filter add dev eth4 ingress matchall action mirred egress redirect dev eth1
Example 4: Use a single shared filter block on both eth5 and eth6::
$ tc qdisc add dev eth5 ingress_block 1 clsact
$ tc qdisc add dev eth6 ingress_block 1 clsact
$ tc filter add block 1 ingress flower dst_mac 00:01:02:03:04:04 skip_sw \
action trap
$ tc filter add block 1 ingress protocol ipv4 flower src_ip 192.168.1.1 skip_sw \
action mirred egress redirect dev eth3
Mirroring
~~~~~~~~~
The DPAA2 switch supports only per port mirroring and per VLAN mirroring.
Adding mirroring filters in shared blocks is also supported.
When using the tc-flower classifier with the 802.1q protocol, only the
''vlan_id'' key will be accepted. Mirroring based on any other fields from the
802.1q protocol will be rejected::
$ tc qdisc add dev eth8 ingress_block 1 clsact
$ tc filter add block 1 ingress protocol 802.1q flower skip_sw vlan_prio 3 action mirred egress mirror dev eth6
Error: fsl_dpaa2_switch: Only matching on VLAN ID supported.
We have an error talking to the kernel
If a mirroring VLAN filter is requested on a port, the VLAN must to be
installed on the switch port in question either using ''bridge'' or by creating
a VLAN upper device if the switch port is used as a standalone interface::
$ tc qdisc add dev eth8 ingress_block 1 clsact
$ tc filter add block 1 ingress protocol 802.1q flower skip_sw vlan_id 200 action mirred egress mirror dev eth6
Error: VLAN must be installed on the switch port.
We have an error talking to the kernel
$ bridge vlan add vid 200 dev eth8
$ tc filter add block 1 ingress protocol 802.1q flower skip_sw vlan_id 200 action mirred egress mirror dev eth6
$ ip link add link eth8 name eth8.200 type vlan id 200
$ tc filter add block 1 ingress protocol 802.1q flower skip_sw vlan_id 200 action mirred egress mirror dev eth6
Also, it should be noted that the mirrored traffic will be subject to the same
egress restrictions as any other traffic. This means that when a mirrored
packet will reach the mirror port, if the VLAN found in the packet is not
installed on the port it will get dropped.
The DPAA2 switch supports only a single mirroring destination, thus multiple
mirror rules can be installed but their ''to'' port has to be the same::
$ tc filter add block 1 ingress protocol 802.1q flower skip_sw vlan_id 200 action mirred egress mirror dev eth6
$ tc filter add block 1 ingress protocol 802.1q flower skip_sw vlan_id 100 action mirred egress mirror dev eth7
Error: fsl_dpaa2_switch: Multiple mirror ports not supported.
We have an error talking to the kernel
linux-7.2.3/Documentation/networking/device_drivers/ethernet/freescale/gianfar.rst
+51
View File
@@ -0,0 +1,51 @@
.. SPDX-License-Identifier: GPL-2.0
===========================
The Gianfar Ethernet Driver
===========================
:Author: Andy Fleming <afleming@freescale.com>
:Updated: 2005-07-28
Checksum Offloading
===================
The eTSEC controller (first included in parts from late 2005 like
the 8548) has the ability to perform TCP, UDP, and IP checksums
in hardware. The Linux kernel only offloads the TCP and UDP
checksums (and always performs the pseudo header checksums), so
the driver only supports checksumming for TCP/IP and UDP/IP
packets. Use ethtool to enable or disable this feature for RX
and TX.
VLAN
====
In order to use VLAN, please consult Linux documentation on
configuring VLANs. The gianfar driver supports hardware insertion and
extraction of VLAN headers, but not filtering. Filtering will be
done by the kernel.
Multicasting
============
The gianfar driver supports using the group hash table on the
TSEC (and the extended hash table on the eTSEC) for multicast
filtering. On the eTSEC, the exact-match MAC registers are used
before the hash tables. See Linux documentation on how to join
multicast groups.
Padding
=======
The gianfar driver supports padding received frames with 2 bytes
to align the IP header to a 16-byte boundary, when supported by
hardware.
Ethtool
=======
The gianfar driver supports the use of ethtool for many
configuration options. You must run ethtool only on currently
open interfaces. See ethtool documentation for details.
linux-7.2.3/Documentation/networking/device_drivers/ethernet/google/gve.rst
+175
View File
@@ -0,0 +1,175 @@
.. SPDX-License-Identifier: GPL-2.0+
==============================================================
Linux kernel driver for Compute Engine Virtual Ethernet (gve):
==============================================================
Supported Hardware
===================
The GVE driver binds to a single PCI device id used by the virtual
Ethernet device found in some Compute Engine VMs.
+--------------+----------+---------+
|Field | Value | Comments|
+==============+==========+=========+
|Vendor ID | `0x1AE0` | Google |
+--------------+----------+---------+
|Device ID | `0x0042` | |
+--------------+----------+---------+
|Sub-vendor ID | `0x1AE0` | Google |
+--------------+----------+---------+
|Sub-device ID | `0x0058` | |
+--------------+----------+---------+
|Revision ID | `0x0` | |
+--------------+----------+---------+
|Device Class | `0x200` | Ethernet|
+--------------+----------+---------+
PCI Bars
========
The gVNIC PCI device exposes three 32-bit memory BARS:
- Bar0 - Device configuration and status registers.
- Bar1 - MSI-X vector table
- Bar2 - IRQ, RX and TX doorbells
Device Interactions
===================
The driver interacts with the device in the following ways:
- Registers
- A block of MMIO registers
- See gve_register.h for more detail
- Admin Queue
- See description below
- Reset
- At any time the device can be reset
- Interrupts
- See supported interrupts below
- Transmit and Receive Queues
- See description below
Descriptor Formats
------------------
GVE supports two descriptor formats: GQI and DQO. These two formats have
entirely different descriptors, which will be described below.
Addressing Mode
------------------
GVE supports two addressing modes: QPL and RDA.
QPL ("queue-page-list") mode communicates data through a set of
pre-registered pages.
For RDA ("raw DMA addressing") mode, the set of pages is dynamic.
Therefore, the packet buffers can be anywhere in guest memory.
Registers
---------
All registers are MMIO.
The registers are used for initializing and configuring the device as well as
querying device status in response to management interrupts.
Endianness
----------
- Admin Queue messages and registers are all Big Endian.
- GQI descriptors and datapath registers are Big Endian.
- DQO descriptors and datapath registers are Little Endian.
Admin Queue (AQ)
----------------
The Admin Queue is a PAGE_SIZE memory block, treated as an array of AQ
commands, used by the driver to issue commands to the device and set up
resources.The driver and the device maintain a count of how many commands
have been submitted and executed. To issue AQ commands, the driver must do
the following (with proper locking):
1) Copy new commands into next available slots in the AQ array
2) Increment its counter by he number of new commands
3) Write the counter into the GVE_ADMIN_QUEUE_DOORBELL register
4) Poll the ADMIN_QUEUE_EVENT_COUNTER register until it equals
the value written to the doorbell, or until a timeout.
The device will update the status field in each AQ command reported as
executed through the ADMIN_QUEUE_EVENT_COUNTER register.
Device Resets
-------------
A device reset is triggered by writing 0x0 to the AQ PFN register.
This causes the device to release all resources allocated by the
driver, including the AQ itself.
Interrupts
----------
The following interrupts are supported by the driver:
Management Interrupt
~~~~~~~~~~~~~~~~~~~~
The management interrupt is used by the device to tell the driver to
look at the GVE_DEVICE_STATUS register.
The handler for the management irq simply queues the service task in
the workqueue to check the register and acks the irq.
Notification Block Interrupts
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The notification block interrupts are used to tell the driver to poll
the queues associated with that interrupt.
The handler for these irqs schedule the napi for that block to run
and poll the queues.
GQI Traffic Queues
------------------
GQI queues are composed of a descriptor ring and a buffer and are assigned to a
notification block.
The descriptor rings are power-of-two-sized ring buffers consisting of
fixed-size descriptors. They advance their head pointer using a __be32
doorbell located in Bar2. The tail pointers are advanced by consuming
descriptors in-order and updating a __be32 counter. Both the doorbell
and the counter overflow to zero.
Each queue's buffers must be registered in advance with the device as a
queue page list, and packet data can only be put in those pages.
Transmit
~~~~~~~~
gve maps the buffers for transmit rings into a FIFO and copies the packets
into the FIFO before sending them to the NIC.
Receive
~~~~~~~
The buffers for receive rings are put into a data ring that is the same
length as the descriptor ring and the head and tail pointers advance over
the rings together.
DQO Traffic Queues
------------------
- Every TX and RX queue is assigned a notification block.
- TX and RX buffers queues, which send descriptors to the device, use MMIO
doorbells to notify the device of new descriptors.
- RX and TX completion queues, which receive descriptors from the device, use a
"generation bit" to know when a descriptor was populated by the device. The
driver initializes all bits with the "current generation". The device will
populate received descriptors with the "next generation" which is inverted
from the current generation. When the ring wraps, the current/next generation
are swapped.
- It's the driver's responsibility to ensure that the RX and TX completion
queues are not overrun. This can be accomplished by limiting the number of
descriptors posted to HW.
- TX packets have a 16 bit completion_tag and RX buffers have a 16 bit
buffer_id. These will be returned on the TX completion and RX queues
respectively to let the driver know which packet/buffer was completed.
Transmit
~~~~~~~~
A packet's buffers are DMA mapped for the device to access before transmission.
After the packet was successfully transmitted, the buffers are unmapped.
Receive
~~~~~~~
The driver posts fixed sized buffers to HW on the RX buffer queue. The packet
received on the associated RX queue may span multiple descriptors.
linux-7.2.3/Documentation/networking/device_drivers/ethernet/huawei/hinic.rst
+128
View File
@@ -0,0 +1,128 @@
.. SPDX-License-Identifier: GPL-2.0
============================================================
Linux Kernel Driver for Huawei Intelligent NIC(HiNIC) family
============================================================
Overview:
=========
HiNIC is a network interface card for the Data Center Area.
The driver supports a range of link-speed devices (10GbE, 25GbE, 40GbE, etc.).
The driver supports also a negotiated and extendable feature set.
Some HiNIC devices support SR-IOV. This driver is used for Physical Function
(PF).
HiNIC devices support MSI-X interrupt vector for each Tx/Rx queue and
adaptive interrupt moderation.
HiNIC devices support also various offload features such as checksum offload,
TCP Transmit Segmentation Offload(TSO), Receive-Side Scaling(RSS) and
LRO(Large Receive Offload).
Supported PCI vendor ID/device IDs:
===================================
19e5:1822 - HiNIC PF
Driver Architecture and Source Code:
====================================
hinic_dev - Implement a Logical Network device that is independent from
specific HW details about HW data structure formats.
hinic_hwdev - Implement the HW details of the device and include the components
for accessing the PCI NIC.
hinic_hwdev contains the following components:
===============================================
HW Interface:
=============
The interface for accessing the pci device (DMA memory and PCI BARs).
(hinic_hw_if.c, hinic_hw_if.h)
Configuration Status Registers Area that describes the HW Registers on the
configuration and status BAR0. (hinic_hw_csr.h)
MGMT components:
================
Asynchronous Event Queues(AEQs) - The event queues for receiving messages from
the MGMT modules on the cards. (hinic_hw_eqs.c, hinic_hw_eqs.h)
Application Programmable Interface commands(API CMD) - Interface for sending
MGMT commands to the card. (hinic_hw_api_cmd.c, hinic_hw_api_cmd.h)
Management (MGMT) - the PF to MGMT channel that uses API CMD for sending MGMT
commands to the card and receives notifications from the MGMT modules on the
card by AEQs. Also set the addresses of the IO CMDQs in HW.
(hinic_hw_mgmt.c, hinic_hw_mgmt.h)
IO components:
==============
Completion Event Queues(CEQs) - The completion Event Queues that describe IO
tasks that are finished. (hinic_hw_eqs.c, hinic_hw_eqs.h)
Work Queues(WQ) - Contain the memory and operations for use by CMD queues and
the Queue Pairs. The WQ is a Memory Block in a Page. The Block contains
pointers to Memory Areas that are the Memory for the Work Queue Elements(WQEs).
(hinic_hw_wq.c, hinic_hw_wq.h)
Command Queues(CMDQ) - The queues for sending commands for IO management and is
used to set the QPs addresses in HW. The commands completion events are
accumulated on the CEQ that is configured to receive the CMDQ completion events.
(hinic_hw_cmdq.c, hinic_hw_cmdq.h)
Queue Pairs(QPs) - The HW Receive and Send queues for Receiving and Transmitting
Data. (hinic_hw_qp.c, hinic_hw_qp.h, hinic_hw_qp_ctxt.h)
IO - de/constructs all the IO components. (hinic_hw_io.c, hinic_hw_io.h)
HW device:
==========
HW device - de/constructs the HW Interface, the MGMT components on the
initialization of the driver and the IO components on the case of Interface
UP/DOWN Events. (hinic_hw_dev.c, hinic_hw_dev.h)
hinic_dev contains the following components:
===============================================
PCI ID table - Contains the supported PCI Vendor/Device IDs.
(hinic_pci_tbl.h)
Port Commands - Send commands to the HW device for port management
(MAC, Vlan, MTU, ...). (hinic_port.c, hinic_port.h)
Tx Queues - Logical Tx Queues that use the HW Send Queues for transmit.
The Logical Tx queue is not dependent on the format of the HW Send Queue.
(hinic_tx.c, hinic_tx.h)
Rx Queues - Logical Rx Queues that use the HW Receive Queues for receive.
The Logical Rx queue is not dependent on the format of the HW Receive Queue.
(hinic_rx.c, hinic_rx.h)
hinic_dev - de/constructs the Logical Tx and Rx Queues.
(hinic_main.c, hinic_dev.h)
Miscellaneous
=============
Common functions that are used by HW and Logical Device.
(hinic_common.c, hinic_common.h)
Support
=======
If an issue is identified with the released source code on the supported kernel
with a supported adapter, email the specific information related to the issue to
aviad.krawczyk@huawei.com.
linux-7.2.3/Documentation/networking/device_drivers/ethernet/huawei/hinic3.rst
+137
View File
@@ -0,0 +1,137 @@
.. SPDX-License-Identifier: GPL-2.0
=====================================================================
Linux kernel driver for Huawei Ethernet Device Driver (hinic3) family
=====================================================================
Overview
========
The hinic3 is a network interface card (NIC) for Data Center. It supports
a range of link-speed devices (10GE, 25GE, 100GE, etc.). The hinic3
devices can have multiple physical forms: LOM (Lan on Motherboard) NIC,
PCIe standard NIC, OCP (Open Compute Project) NIC, etc.
The hinic3 driver supports the following features:
- IPv4/IPv6 TCP/UDP checksum offload
- TSO (TCP Segmentation Offload), LRO (Large Receive Offload)
- RSS (Receive Side Scaling)
- MSI-X interrupt aggregation configuration and interrupt adaptation.
- SR-IOV (Single Root I/O Virtualization).
Content
=======
- Supported PCI vendor ID/device IDs
- Source Code Structure of Hinic3 Driver
- Management Interface
Supported PCI vendor ID/device IDs
==================================
19e5:0222 - hinic3 PF/PPF
19e5:375F - hinic3 VF
Prime Physical Function (PPF) is responsible for the management of the
whole NIC card. For example, clock synchronization between the NIC and
the host. Any PF may serve as a PPF. The PPF is selected dynamically.
Source Code Structure of Hinic3 Driver
======================================
======================== ================================================
hinic3_pci_id_tbl.h Supported device IDs
hinic3_hw_intf.h Interface between HW and driver
hinic3_queue_common.[ch] Common structures and methods for NIC queues
hinic3_common.[ch] Encapsulation of memory operations in Linux
hinic3_csr.h Register definitions in the BAR
hinic3_hwif.[ch] Interface for BAR
hinic3_eqs.[ch] Interface for AEQs and CEQs
hinic3_mbox.[ch] Interface for mailbox
hinic3_mgmt.[ch] Management interface based on mailbox and AEQ
hinic3_wq.[ch] Work queue data structures and interface
hinic3_cmdq.[ch] Command queue is used to post command to HW
hinic3_hwdev.[ch] HW structures and methods abstractions
hinic3_lld.[ch] Auxiliary driver adaptation layer
hinic3_hw_comm.[ch] Interface for common HW operations
hinic3_mgmt_interface.h Interface between firmware and driver
hinic3_hw_cfg.[ch] Interface for HW configuration
hinic3_irq.c Interrupt request
hinic3_netdev_ops.c Operations registered to Linux kernel stack
hinic3_nic_dev.h NIC structures and methods abstractions
hinic3_main.c Main Linux kernel driver
hinic3_nic_cfg.[ch] NIC service configuration
hinic3_nic_io.[ch] Management plane interface for TX and RX
hinic3_rss.[ch] Interface for Receive Side Scaling (RSS)
hinic3_rx.[ch] Interface for transmit
hinic3_tx.[ch] Interface for receive
hinic3_ethtool.c Interface for ethtool operations (ops)
hinic3_filter.c Interface for MAC address
======================== ================================================
Management Interface
====================
Asynchronous Event Queue (AEQ)
------------------------------
AEQ receives high priority events from the HW over a descriptor queue.
Every descriptor is a fixed size of 64 bytes. AEQ can receive solicited or
unsolicited events. Every device, VF or PF, can have up to 4 AEQs.
Every AEQ is associated to a dedicated IRQ. AEQ can receive multiple types
of events, but in practice the hinic3 driver ignores all events except for
2 mailbox related events.
Mailbox
-------
Mailbox is a communication mechanism between the hinic3 driver and the HW.
Each device has an independent mailbox. Driver can use the mailbox to send
requests to management. Driver receives mailbox messages, such as responses
to requests, over the AEQ (using event HINIC3_AEQ_FOR_MBOX). Due to the
limited size of mailbox data register, mailbox messages are sent
segment-by-segment.
Every device can use its mailbox to post request to firmware. The mailbox
can also be used to post requests and responses between the PF and its VFs.
Completion Event Queue (CEQ)
----------------------------
The implementation of CEQ is the same as AEQ. It receives completion events
from HW over a fixed size descriptor of 32 bits. Every device can have up
to 32 CEQs. Every CEQ has a dedicated IRQ. CEQ only receives solicited
events that are responses to requests from the driver. CEQ can receive
multiple types of events, but in practice the hinic3 driver ignores all
events except for HINIC3_CMDQ that represents completion of previously
posted commands on a cmdq.
Command Queue (cmdq)
--------------------
Every cmdq has a dedicated work queue on which commands are posted.
Commands on the work queue are fixed size descriptor of size 64 bytes.
Completion of a command will be indicated using ctrl bits in the
descriptor that carried the command. Notification of command completions
will also be provided via event on CEQ. Every device has 4 command queues
that are initialized as a set (called cmdqs), each with its own type.
Hinic3 driver only uses type HINIC3_CMDQ_SYNC.
Work Queues(WQ)
---------------
Work queues are logical arrays of fixed size WQEs. The array may be spread
over multiple non-contiguous pages using indirection table. Work queues are
used by I/O queues and command queues.
Global function ID
------------------
Every function, PF or VF, has a unique ordinal identification within the device.
Many management commands (mbox or cmdq) contain this ID so HW can apply the
command effect to the right function.
PF is allowed to post management commands to a subordinate VF by specifying the
VFs ID. A VF must provide its own ID. Anti-spoofing in the HW will cause
command from a VF to fail if it contains the wrong ID.
linux-7.2.3/Documentation/networking/device_drivers/ethernet/index.rst
+63
View File
@@ -0,0 +1,63 @@
.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
Ethernet Device Drivers
=======================
Device drivers for Ethernet and Ethernet-based virtual function devices.
Contents:
.. toctree::
:maxdepth: 2
3com/3c509
3com/vortex
amazon/ena
altera/altera_tse
amd/pds_core
amd/pds_vdpa
amd/pds_vfio_pci
aquantia/atlantic
chelsio/cxgb
dlink/dl2k
davicom/dm9000
dec/dmfe
freescale/dpaa
freescale/dpaa2/index
freescale/gianfar
google/gve
huawei/hinic
huawei/hinic3
intel/e100
intel/e1000
intel/e1000e
intel/fm10k
intel/idpf
intel/igb
intel/igbvf
intel/ixgbe
intel/ixgbevf
intel/i40e
intel/iavf
intel/ice
marvell/octeontx2
marvell/octeon_ep
marvell/octeon_ep_vf
mellanox/mlx5/index
meta/fbnic
microsoft/netvsc
mucse/rnpgbe
netronome/nfp
pensando/ionic
pensando/ionic_rdma
qualcomm/ppe/ppe
stmicro/stmmac
ti/cpsw
ti/cpsw_switchdev
ti/am65_nuss_cpsw_switchdev
ti/tlan
ti/icssg_prueth
wangxun/txgbe
wangxun/txgbevf
wangxun/ngbe
wangxun/ngbevf
linux-7.2.3/Documentation/networking/device_drivers/ethernet/intel/e100.rst
+185
View File
@@ -0,0 +1,185 @@
.. SPDX-License-Identifier: GPL-2.0+
=============================================================
Linux Base Driver for the Intel(R) PRO/100 Family of Adapters
=============================================================
June 1, 2018
Contents
========
- In This Release
- Identifying Your Adapter
- Building and Installation
- Driver Configuration Parameters
- Additional Configurations
- Known Issues
- Support
In This Release
===============
This file describes the Linux Base Driver for the Intel(R) PRO/100 Family of
Adapters. This driver includes support for Itanium(R)2-based systems.
For questions related to hardware requirements, refer to the documentation
supplied with your Intel PRO/100 adapter.
The following features are now available in supported kernels:
- Native VLANs
- Channel Bonding (teaming)
- SNMP
Channel Bonding documentation can be found in the Linux kernel source:
/Documentation/networking/bonding.rst
Identifying Your Adapter
========================
For information on how to identify your adapter, and for the latest Intel
network drivers, refer to the Intel Support website:
https://www.intel.com/support
Driver Configuration Parameters
===============================
The default value for each parameter is generally the recommended setting,
unless otherwise noted.
Rx Descriptors:
Number of receive descriptors. A receive descriptor is a data
structure that describes a receive buffer and its attributes to the network
controller. The data in the descriptor is used by the controller to write
data from the controller to host memory. In the 3.x.x driver the valid range
for this parameter is 64-256. The default value is 256. This parameter can be
changed using the command::
ethtool -G eth? rx n
Where n is the number of desired Rx descriptors.
Tx Descriptors:
Number of transmit descriptors. A transmit descriptor is a data
structure that describes a transmit buffer and its attributes to the network
controller. The data in the descriptor is used by the controller to read
data from the host memory to the controller. In the 3.x.x driver the valid
range for this parameter is 64-256. The default value is 128. This parameter
can be changed using the command::
ethtool -G eth? tx n
Where n is the number of desired Tx descriptors.
Speed/Duplex:
The driver auto-negotiates the link speed and duplex settings by
default. The ethtool utility can be used as follows to force speed/duplex.::
ethtool -s eth? autoneg off speed {10|100} duplex {full|half}
NOTE: setting the speed/duplex to incorrect values will cause the link to
fail.
Event Log Message Level:
The driver uses the message level flag to log events
to syslog. The message level can be set at driver load time. It can also be
set using the command::
ethtool -s eth? msglvl n
Additional Configurations
=========================
Configuring the Driver on Different Distributions
-------------------------------------------------
Configuring a network driver to load properly when the system is started
is distribution dependent. Typically, the configuration process involves
adding an alias line to `/etc/modprobe.d/*.conf` as well as editing other
system startup scripts and/or configuration files. Many popular Linux
distributions ship with tools to make these changes for you. To learn
the proper way to configure a network device for your system, refer to
your distribution documentation. If during this process you are asked
for the driver or module name, the name for the Linux Base Driver for
the Intel PRO/100 Family of Adapters is e100.
As an example, if you install the e100 driver for two PRO/100 adapters
(eth0 and eth1), add the following to a configuration file in
/etc/modprobe.d/::
alias eth0 e100
alias eth1 e100
Viewing Link Messages
---------------------
In order to see link messages and other Intel driver information on your
console, you must set the dmesg level up to six. This can be done by
entering the following on the command line before loading the e100
driver::
dmesg -n 6
If you wish to see all messages issued by the driver, including debug
messages, set the dmesg level to eight.
NOTE: This setting is not saved across reboots.
ethtool
-------
The driver utilizes the ethtool interface for driver configuration and
diagnostics, as well as displaying statistical information. The ethtool
version 1.6 or later is required for this functionality.
The latest release of ethtool can be found from
https://www.kernel.org/pub/software/network/ethtool/
Enabling Wake on LAN (WoL)
--------------------------
WoL is provided through the ethtool utility. For instructions on
enabling WoL with ethtool, refer to the ethtool man page. WoL will be
enabled on the system during the next shut down or reboot. For this
driver version, in order to enable WoL, the e100 driver must be loaded
when shutting down or rebooting the system.
NAPI
----
NAPI (Rx polling mode) is supported in the e100 driver.
See :ref:`Documentation/networking/napi.rst <napi>` for more information.
Multiple Interfaces on Same Ethernet Broadcast Network
------------------------------------------------------
Due to the default ARP behavior on Linux, it is not possible to have one
system on two IP networks in the same Ethernet broadcast domain
(non-partitioned switch) behave as expected. All Ethernet interfaces
will respond to IP traffic for any IP address assigned to the system.
This results in unbalanced receive traffic.
If you have multiple interfaces in a server, either turn on ARP
filtering by
(1) entering::
echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter
(this only works if your kernel's version is higher than 2.4.5), or
(2) installing the interfaces in separate broadcast domains (either
in different switches or in a switch partitioned to VLANs).
Support
=======
For general information, go to the Intel support website at:
https://www.intel.com/support/
If an issue is identified with the released source code on a supported kernel
with a supported adapter, email the specific information related to the issue
to intel-wired-lan@lists.osuosl.org.
linux-7.2.3/Documentation/networking/device_drivers/ethernet/intel/e1000.rst
+458
View File
@@ -0,0 +1,458 @@
.. SPDX-License-Identifier: GPL-2.0+
==========================================================
Linux Base Driver for Intel(R) Ethernet Network Connection
==========================================================
Intel Gigabit Linux driver.
Copyright(c) 1999 - 2013 Intel Corporation.
Contents
========
- Identifying Your Adapter
- Command Line Parameters
- Speed and Duplex Configuration
- Additional Configurations
- Support
Identifying Your Adapter
========================
For more information on how to identify your adapter, go to the Adapter &
Driver ID Guide at:
http://support.intel.com/support/go/network/adapter/idguide.htm
For the latest Intel network drivers for Linux, refer to the following
website. In the search field, enter your adapter name or type, or use the
networking link on the left to search for your adapter:
http://support.intel.com/support/go/network/adapter/home.htm
Command Line Parameters
=======================
The default value for each parameter is generally the recommended setting,
unless otherwise noted.
NOTES:
For more information about the AutoNeg, Duplex, and Speed
parameters, see the "Speed and Duplex Configuration" section in
this document.
For more information about the InterruptThrottleRate,
RxIntDelay, TxIntDelay, RxAbsIntDelay, and TxAbsIntDelay
parameters, see the application note at:
http://www.intel.com/design/network/applnots/ap450.htm
AutoNeg
-------
(Supported only on adapters with copper connections)
:Valid Range: 0x01-0x0F, 0x20-0x2F
:Default Value: 0x2F
This parameter is a bit-mask that specifies the speed and duplex settings
advertised by the adapter. When this parameter is used, the Speed and
Duplex parameters must not be specified.
NOTE:
Refer to the Speed and Duplex section of this readme for more
information on the AutoNeg parameter.
Duplex
------
(Supported only on adapters with copper connections)
:Valid Range: 0-2 (0=auto-negotiate, 1=half, 2=full)
:Default Value: 0
This defines the direction in which data is allowed to flow. Can be
either one or two-directional. If both Duplex and the link partner are
set to auto-negotiate, the board auto-detects the correct duplex. If the
link partner is forced (either full or half), Duplex defaults to half-
duplex.
FlowControl
-----------
:Valid Range: 0-3 (0=none, 1=Rx only, 2=Tx only, 3=Rx&Tx)
:Default Value: Reads flow control settings from the EEPROM
This parameter controls the automatic generation(Tx) and response(Rx)
to Ethernet PAUSE frames.
InterruptThrottleRate
---------------------
(not supported on Intel(R) 82542, 82543 or 82544-based adapters)
:Valid Range:
0,1,3,4,100-100000 (0=off, 1=dynamic, 3=dynamic conservative,
4=simplified balancing)
:Default Value: 3
The driver can limit the amount of interrupts per second that the adapter
will generate for incoming packets. It does this by writing a value to the
adapter that is based on the maximum amount of interrupts that the adapter
will generate per second.
Setting InterruptThrottleRate to a value greater or equal to 100
will program the adapter to send out a maximum of that many interrupts
per second, even if more packets have come in. This reduces interrupt
load on the system and can lower CPU utilization under heavy load,
but will increase latency as packets are not processed as quickly.
The default behaviour of the driver previously assumed a static
InterruptThrottleRate value of 8000, providing a good fallback value for
all traffic types,but lacking in small packet performance and latency.
The hardware can handle many more small packets per second however, and
for this reason an adaptive interrupt moderation algorithm was implemented.
Since 7.3.x, the driver has two adaptive modes (setting 1 or 3) in which
it dynamically adjusts the InterruptThrottleRate value based on the traffic
that it receives. After determining the type of incoming traffic in the last
timeframe, it will adjust the InterruptThrottleRate to an appropriate value
for that traffic.
The algorithm classifies the incoming traffic every interval into
classes. Once the class is determined, the InterruptThrottleRate value is
adjusted to suit that traffic type the best. There are three classes defined:
"Bulk traffic", for large amounts of packets of normal size; "Low latency",
for small amounts of traffic and/or a significant percentage of small
packets; and "Lowest latency", for almost completely small packets or
minimal traffic.
In dynamic conservative mode, the InterruptThrottleRate value is set to 4000
for traffic that falls in class "Bulk traffic". If traffic falls in the "Low
latency" or "Lowest latency" class, the InterruptThrottleRate is increased
stepwise to 20000. This default mode is suitable for most applications.
For situations where low latency is vital such as cluster or
grid computing, the algorithm can reduce latency even more when
InterruptThrottleRate is set to mode 1. In this mode, which operates
the same as mode 3, the InterruptThrottleRate will be increased stepwise to
70000 for traffic in class "Lowest latency".
In simplified mode the interrupt rate is based on the ratio of TX and
RX traffic. If the bytes per second rate is approximately equal, the
interrupt rate will drop as low as 2000 interrupts per second. If the
traffic is mostly transmit or mostly receive, the interrupt rate could
be as high as 8000.
Setting InterruptThrottleRate to 0 turns off any interrupt moderation
and may improve small packet latency, but is generally not suitable
for bulk throughput traffic.
NOTE:
InterruptThrottleRate takes precedence over the TxAbsIntDelay and
RxAbsIntDelay parameters. In other words, minimizing the receive
and/or transmit absolute delays does not force the controller to
generate more interrupts than what the Interrupt Throttle Rate
allows.
CAUTION:
If you are using the Intel(R) PRO/1000 CT Network Connection
(controller 82547), setting InterruptThrottleRate to a value
greater than 75,000, may hang (stop transmitting) adapters
under certain network conditions. If this occurs a NETDEV
WATCHDOG message is logged in the system event log. In
addition, the controller is automatically reset, restoring
the network connection. To eliminate the potential for the
hang, ensure that InterruptThrottleRate is set no greater
than 75,000 and is not set to 0.
NOTE:
When e1000 is loaded with default settings and multiple adapters
are in use simultaneously, the CPU utilization may increase non-
linearly. In order to limit the CPU utilization without impacting
the overall throughput, we recommend that you load the driver as
follows::
modprobe e1000 InterruptThrottleRate=3000,3000,3000
This sets the InterruptThrottleRate to 3000 interrupts/sec for
the first, second, and third instances of the driver. The range
of 2000 to 3000 interrupts per second works on a majority of
systems and is a good starting point, but the optimal value will
be platform-specific. If CPU utilization is not a concern, use
RX_POLLING (NAPI) and default driver settings.
RxDescriptors
-------------
:Valid Range:
- 48-256 for 82542 and 82543-based adapters
- 48-4096 for all other supported adapters
:Default Value: 256
This value specifies the number of receive buffer descriptors allocated
by the driver. Increasing this value allows the driver to buffer more
incoming packets, at the expense of increased system memory utilization.
Each descriptor is 16 bytes. A receive buffer is also allocated for each
descriptor and can be either 2048, 4096, 8192, or 16384 bytes, depending
on the MTU setting. The maximum MTU size is 16110.
NOTE:
MTU designates the frame size. It only needs to be set for Jumbo
Frames. Depending on the available system resources, the request
for a higher number of receive descriptors may be denied. In this
case, use a lower number.
RxIntDelay
----------
:Valid Range: 0-65535 (0=off)
:Default Value: 0
This value delays the generation of receive interrupts in units of 1.024
microseconds. Receive interrupt reduction can improve CPU efficiency if
properly tuned for specific network traffic. Increasing this value adds
extra latency to frame reception and can end up decreasing the throughput
of TCP traffic. If the system is reporting dropped receives, this value
may be set too high, causing the driver to run out of available receive
descriptors.
CAUTION:
When setting RxIntDelay to a value other than 0, adapters may
hang (stop transmitting) under certain network conditions. If
this occurs a NETDEV WATCHDOG message is logged in the system
event log. In addition, the controller is automatically reset,
restoring the network connection. To eliminate the potential
for the hang ensure that RxIntDelay is set to 0.
RxAbsIntDelay
-------------
(This parameter is supported only on 82540, 82545 and later adapters.)
:Valid Range: 0-65535 (0=off)
:Default Value: 128
This value, in units of 1.024 microseconds, limits the delay in which a
receive interrupt is generated. Useful only if RxIntDelay is non-zero,
this value ensures that an interrupt is generated after the initial
packet is received within the set amount of time. Proper tuning,
along with RxIntDelay, may improve traffic throughput in specific network
conditions.
Speed
-----
(This parameter is supported only on adapters with copper connections.)
:Valid Settings: 0, 10, 100, 1000
:Default Value: 0 (auto-negotiate at all supported speeds)
Speed forces the line speed to the specified value in megabits per second
(Mbps). If this parameter is not specified or is set to 0 and the link
partner is set to auto-negotiate, the board will auto-detect the correct
speed. Duplex should also be set when Speed is set to either 10 or 100.
TxDescriptors
-------------
:Valid Range:
- 48-256 for 82542 and 82543-based adapters
- 48-4096 for all other supported adapters
:Default Value: 256
This value is the number of transmit descriptors allocated by the driver.
Increasing this value allows the driver to queue more transmits. Each
descriptor is 16 bytes.
NOTE:
Depending on the available system resources, the request for a
higher number of transmit descriptors may be denied. In this case,
use a lower number.
TxIntDelay
----------
:Valid Range: 0-65535 (0=off)
:Default Value: 8
This value delays the generation of transmit interrupts in units of
1.024 microseconds. Transmit interrupt reduction can improve CPU
efficiency if properly tuned for specific network traffic. If the
system is reporting dropped transmits, this value may be set too high
causing the driver to run out of available transmit descriptors.
TxAbsIntDelay
-------------
(This parameter is supported only on 82540, 82545 and later adapters.)
:Valid Range: 0-65535 (0=off)
:Default Value: 32
This value, in units of 1.024 microseconds, limits the delay in which a
transmit interrupt is generated. Useful only if TxIntDelay is non-zero,
this value ensures that an interrupt is generated after the initial
packet is sent on the wire within the set amount of time. Proper tuning,
along with TxIntDelay, may improve traffic throughput in specific
network conditions.
XsumRX
------
(This parameter is NOT supported on the 82542-based adapter.)
:Valid Range: 0-1
:Default Value: 1
A value of '1' indicates that the driver should enable IP checksum
offload for received packets (both UDP and TCP) to the adapter hardware.
Copybreak
---------
:Valid Range: 0-xxxxxxx (0=off)
:Default Value: 256
:Usage: modprobe e1000.ko copybreak=128
Driver copies all packets below or equaling this size to a fresh RX
buffer before handing it up the stack.
This parameter is different than other parameters, in that it is a
single (not 1,1,1 etc.) parameter applied to all driver instances and
it is also available during runtime at
/sys/module/e1000/parameters/copybreak
SmartPowerDownEnable
--------------------
:Valid Range: 0-1
:Default Value: 0 (disabled)
Allows PHY to turn off in lower power states. The user can turn off
this parameter in supported chipsets.
Speed and Duplex Configuration
==============================
Three keywords are used to control the speed and duplex configuration.
These keywords are Speed, Duplex, and AutoNeg.
If the board uses a fiber interface, these keywords are ignored, and the
fiber interface board only links at 1000 Mbps full-duplex.
For copper-based boards, the keywords interact as follows:
- The default operation is auto-negotiate. The board advertises all
supported speed and duplex combinations, and it links at the highest
common speed and duplex mode IF the link partner is set to auto-negotiate.
- If Speed = 1000, limited auto-negotiation is enabled and only 1000 Mbps
is advertised (The 1000BaseT spec requires auto-negotiation.)
- If Speed = 10 or 100, then both Speed and Duplex should be set. Auto-
negotiation is disabled, and the AutoNeg parameter is ignored. Partner
SHOULD also be forced.
The AutoNeg parameter is used when more control is required over the
auto-negotiation process. It should be used when you wish to control which
speed and duplex combinations are advertised during the auto-negotiation
process.
The parameter may be specified as either a decimal or hexadecimal value as
determined by the bitmap below.
============== ====== ====== ======= ======= ====== ====== ======= ======
Bit position 7 6 5 4 3 2 1 0
Decimal Value 128 64 32 16 8 4 2 1
Hex value 80 40 20 10 8 4 2 1
Speed (Mbps) N/A N/A 1000 N/A 100 100 10 10
Duplex Full Full Half Full Half
============== ====== ====== ======= ======= ====== ====== ======= ======
Some examples of using AutoNeg::
modprobe e1000 AutoNeg=0x01 (Restricts autonegotiation to 10 Half)
modprobe e1000 AutoNeg=1 (Same as above)
modprobe e1000 AutoNeg=0x02 (Restricts autonegotiation to 10 Full)
modprobe e1000 AutoNeg=0x03 (Restricts autonegotiation to 10 Half or 10 Full)
modprobe e1000 AutoNeg=0x04 (Restricts autonegotiation to 100 Half)
modprobe e1000 AutoNeg=0x05 (Restricts autonegotiation to 10 Half or 100
Half)
modprobe e1000 AutoNeg=0x020 (Restricts autonegotiation to 1000 Full)
modprobe e1000 AutoNeg=32 (Same as above)
Note that when this parameter is used, Speed and Duplex must not be specified.
If the link partner is forced to a specific speed and duplex, then this
parameter should not be used. Instead, use the Speed and Duplex parameters
previously mentioned to force the adapter to the same speed and duplex.
Additional Configurations
=========================
Jumbo Frames
------------
Jumbo Frames support is enabled by changing the MTU to a value larger than
the default of 1500. Use the ifconfig command to increase the MTU size.
For example::
ifconfig eth<x> mtu 9000 up
This setting is not saved across reboots. It can be made permanent if
you add::
MTU=9000
to the file /etc/sysconfig/network-scripts/ifcfg-eth<x>. This example
applies to the Red Hat distributions; other distributions may store this
setting in a different location.
Notes:
Degradation in throughput performance may be observed in some Jumbo frames
environments. If this is observed, increasing the application's socket buffer
size and/or increasing the /proc/sys/net/ipv4/tcp_*mem entry values may help.
See the specific application manual and /usr/src/linux*/Documentation/
networking/ip-sysctl.txt for more details.
- The maximum MTU setting for Jumbo Frames is 16110. This value coincides
with the maximum Jumbo Frames size of 16128.
- Using Jumbo frames at 10 or 100 Mbps is not supported and may result in
poor performance or loss of link.
- Adapters based on the Intel(R) 82542 and 82573V/E controller do not
support Jumbo Frames. These correspond to the following product names::
Intel(R) PRO/1000 Gigabit Server Adapter
Intel(R) PRO/1000 PM Network Connection
ethtool
-------
The driver utilizes the ethtool interface for driver configuration and
diagnostics, as well as displaying statistical information. The ethtool
version 1.6 or later is required for this functionality.
The latest release of ethtool can be found from
https://www.kernel.org/pub/software/network/ethtool/
Enabling Wake on LAN (WoL)
--------------------------
WoL is configured through the ethtool utility.
WoL will be enabled on the system during the next shut down or reboot.
For this driver version, in order to enable WoL, the e1000 driver must be
loaded when shutting down or rebooting the system.
Support
=======
For general information, go to the Intel support website at:
http://support.intel.com
If an issue is identified with the released source code on the supported
kernel with a supported adapter, email the specific information related
to the issue to intel-wired-lan@lists.osuosl.org.
linux-7.2.3/Documentation/networking/device_drivers/ethernet/intel/e1000e.rst
+378
View File
@@ -0,0 +1,378 @@
.. SPDX-License-Identifier: GPL-2.0+
=====================================================
Linux Driver for Intel(R) Ethernet Network Connection
=====================================================
Intel Gigabit Linux driver.
Copyright(c) 2008-2018 Intel Corporation.
Contents
========
- Identifying Your Adapter
- Command Line Parameters
- Additional Configurations
- Support
Identifying Your Adapter
========================
For information on how to identify your adapter, and for the latest Intel
network drivers, refer to the Intel Support website:
https://www.intel.com/support
Command Line Parameters
=======================
If the driver is built as a module, the following optional parameters are used
by entering them on the command line with the modprobe command using this
syntax::
modprobe e1000e [<option>=<VAL1>,<VAL2>,...]
There needs to be a <VAL#> for each network port in the system supported by
this driver. The values will be applied to each instance, in function order.
For example::
modprobe e1000e InterruptThrottleRate=16000,16000
In this case, there are two network ports supported by e1000e in the system.
The default value for each parameter is generally the recommended setting,
unless otherwise noted.
NOTE: A descriptor describes a data buffer and attributes related to the data
buffer. This information is accessed by the hardware.
InterruptThrottleRate
---------------------
:Valid Range: 0,1,3,4,100-100000
:Default Value: 3
Interrupt Throttle Rate controls the number of interrupts each interrupt
vector can generate per second. Increasing ITR lowers latency at the cost of
increased CPU utilization, though it may help throughput in some circumstances.
Setting InterruptThrottleRate to a value greater or equal to 100
will program the adapter to send out a maximum of that many interrupts
per second, even if more packets have come in. This reduces interrupt
load on the system and can lower CPU utilization under heavy load,
but will increase latency as packets are not processed as quickly.
The default behaviour of the driver previously assumed a static
InterruptThrottleRate value of 8000, providing a good fallback value for
all traffic types, but lacking in small packet performance and latency.
The hardware can handle many more small packets per second however, and
for this reason an adaptive interrupt moderation algorithm was implemented.
The driver has two adaptive modes (setting 1 or 3) in which
it dynamically adjusts the InterruptThrottleRate value based on the traffic
that it receives. After determining the type of incoming traffic in the last
timeframe, it will adjust the InterruptThrottleRate to an appropriate value
for that traffic.
The algorithm classifies the incoming traffic every interval into
classes. Once the class is determined, the InterruptThrottleRate value is
adjusted to suit that traffic type the best. There are three classes defined:
"Bulk traffic", for large amounts of packets of normal size; "Low latency",
for small amounts of traffic and/or a significant percentage of small
packets; and "Lowest latency", for almost completely small packets or
minimal traffic.
- 0: Off
Turns off any interrupt moderation and may improve small packet latency.
However, this is generally not suitable for bulk throughput traffic due
to the increased CPU utilization of the higher interrupt rate.
- 1: Dynamic mode
This mode attempts to moderate interrupts per vector while maintaining
very low latency. This can sometimes cause extra CPU utilization. If
planning on deploying e1000e in a latency sensitive environment, this
parameter should be considered.
- 3: Dynamic Conservative mode (default)
In dynamic conservative mode, the InterruptThrottleRate value is set to
4000 for traffic that falls in class "Bulk traffic". If traffic falls in
the "Low latency" or "Lowest latency" class, the InterruptThrottleRate is
increased stepwise to 20000. This default mode is suitable for most
applications.
- 4: Simplified Balancing mode
In simplified mode the interrupt rate is based on the ratio of TX and
RX traffic. If the bytes per second rate is approximately equal, the
interrupt rate will drop as low as 2000 interrupts per second. If the
traffic is mostly transmit or mostly receive, the interrupt rate could
be as high as 8000.
- 100-100000:
Setting InterruptThrottleRate to a value greater or equal to 100
will program the adapter to send at most that many interrupts per second,
even if more packets have come in. This reduces interrupt load on the
system and can lower CPU utilization under heavy load, but will increase
latency as packets are not processed as quickly.
NOTE: InterruptThrottleRate takes precedence over the TxAbsIntDelay and
RxAbsIntDelay parameters. In other words, minimizing the receive and/or
transmit absolute delays does not force the controller to generate more
interrupts than what the Interrupt Throttle Rate allows.
RxIntDelay
----------
:Valid Range: 0-65535 (0=off)
:Default Value: 0
This value delays the generation of receive interrupts in units of 1.024
microseconds. Receive interrupt reduction can improve CPU efficiency if
properly tuned for specific network traffic. Increasing this value adds extra
latency to frame reception and can end up decreasing the throughput of TCP
traffic. If the system is reporting dropped receives, this value may be set
too high, causing the driver to run out of available receive descriptors.
CAUTION: When setting RxIntDelay to a value other than 0, adapters may hang
(stop transmitting) under certain network conditions. If this occurs a NETDEV
WATCHDOG message is logged in the system event log. In addition, the
controller is automatically reset, restoring the network connection. To
eliminate the potential for the hang ensure that RxIntDelay is set to 0.
RxAbsIntDelay
-------------
:Valid Range: 0-65535 (0=off)
:Default Value: 8
This value, in units of 1.024 microseconds, limits the delay in which a
receive interrupt is generated. This value ensures that an interrupt is
generated after the initial packet is received within the set amount of time,
which is useful only if RxIntDelay is non-zero. Proper tuning, along with
RxIntDelay, may improve traffic throughput in specific network conditions.
TxIntDelay
----------
:Valid Range: 0-65535 (0=off)
:Default Value: 8
This value delays the generation of transmit interrupts in units of 1.024
microseconds. Transmit interrupt reduction can improve CPU efficiency if
properly tuned for specific network traffic. If the system is reporting
dropped transmits, this value may be set too high causing the driver to run
out of available transmit descriptors.
TxAbsIntDelay
-------------
:Valid Range: 0-65535 (0=off)
:Default Value: 32
This value, in units of 1.024 microseconds, limits the delay in which a
transmit interrupt is generated. It is useful only if TxIntDelay is non-zero.
It ensures that an interrupt is generated after the initial Packet is sent on
the wire within the set amount of time. Proper tuning, along with TxIntDelay,
may improve traffic throughput in specific network conditions.
copybreak
---------
:Valid Range: 0-xxxxxxx (0=off)
:Default Value: 256
The driver copies all packets below or equaling this size to a fresh receive
buffer before handing it up the stack.
This parameter differs from other parameters because it is a single (not 1,1,1
etc.) parameter applied to all driver instances and it is also available
during runtime at /sys/module/e1000e/parameters/copybreak.
To use copybreak, type::
modprobe e1000e.ko copybreak=128
SmartPowerDownEnable
--------------------
:Valid Range: 0,1
:Default Value: 0 (disabled)
Allows the PHY to turn off in lower power states. The user can turn off this
parameter in supported chipsets.
KumeranLockLoss
---------------
:Valid Range: 0,1
:Default Value: 1 (enabled)
This workaround skips resetting the PHY at shutdown for the initial silicon
releases of ICH8 systems.
IntMode
-------
:Valid Range: 0-2
:Default Value: 0
+-------+----------------+
| Value | Interrupt Mode |
+=======+================+
| 0 | Legacy |
+-------+----------------+
| 1 | MSI |
+-------+----------------+
| 2 | MSI-X |
+-------+----------------+
IntMode allows load time control over the type of interrupt registered for by
the driver. MSI-X is required for multiple queue support, and some kernels and
combinations of kernel .config options will force a lower level of interrupt
support.
This command will show different values for each type of interrupt::
cat /proc/interrupts
CrcStripping
------------
:Valid Range: 0,1
:Default Value: 1 (enabled)
Strip the CRC from received packets before sending up the network stack. If
you have a machine with a BMC enabled but cannot receive IPMI traffic after
loading or enabling the driver, try disabling this feature.
WriteProtectNVM
---------------
:Valid Range: 0,1
:Default Value: 1 (enabled)
If set to 1, configure the hardware to ignore all write/erase cycles to the
GbE region in the ICHx NVM (in order to prevent accidental corruption of the
NVM). This feature can be disabled by setting the parameter to 0 during initial
driver load.
NOTE: The machine must be power cycled (full off/on) when enabling NVM writes
via setting the parameter to zero. Once the NVM has been locked (via the
parameter at 1 when the driver loads) it cannot be unlocked except via power
cycle.
Debug
-----
:Valid Range: 0-16 (0=none,...,16=all)
:Default Value: 0
This parameter adjusts the level of debug messages displayed in the system logs.
Additional Features and Configurations
======================================
Jumbo Frames
------------
Jumbo Frames support is enabled by changing the Maximum Transmission Unit (MTU)
to a value larger than the default value of 1500.
Use the ifconfig command to increase the MTU size. For example, enter the
following where <x> is the interface number::
ifconfig eth<x> mtu 9000 up
Alternatively, you can use the ip command as follows::
ip link set mtu 9000 dev eth<x>
ip link set up dev eth<x>
This setting is not saved across reboots. The setting change can be made
permanent by adding 'MTU=9000' to the file:
- For RHEL: /etc/sysconfig/network-scripts/ifcfg-eth<x>
- For SLES: /etc/sysconfig/network/<config_file>
NOTE: The maximum MTU setting for Jumbo Frames is 8996. This value coincides
with the maximum Jumbo Frames size of 9018 bytes.
NOTE: Using Jumbo frames at 10 or 100 Mbps is not supported and may result in
poor performance or loss of link.
NOTE: The following adapters limit Jumbo Frames sized packets to a maximum of
4088 bytes:
- Intel(R) 82578DM Gigabit Network Connection
- Intel(R) 82577LM Gigabit Network Connection
The following adapters do not support Jumbo Frames:
- Intel(R) PRO/1000 Gigabit Server Adapter
- Intel(R) PRO/1000 PM Network Connection
- Intel(R) 82562G 10/100 Network Connection
- Intel(R) 82562G-2 10/100 Network Connection
- Intel(R) 82562GT 10/100 Network Connection
- Intel(R) 82562GT-2 10/100 Network Connection
- Intel(R) 82562V 10/100 Network Connection
- Intel(R) 82562V-2 10/100 Network Connection
- Intel(R) 82566DC Gigabit Network Connection
- Intel(R) 82566DC-2 Gigabit Network Connection
- Intel(R) 82566DM Gigabit Network Connection
- Intel(R) 82566MC Gigabit Network Connection
- Intel(R) 82566MM Gigabit Network Connection
- Intel(R) 82567V-3 Gigabit Network Connection
- Intel(R) 82577LC Gigabit Network Connection
- Intel(R) 82578DC Gigabit Network Connection
NOTE: Jumbo Frames cannot be configured on an 82579-based Network device if
MACSec is enabled on the system.
ethtool
-------
The driver utilizes the ethtool interface for driver configuration and
diagnostics, as well as displaying statistical information. The latest ethtool
version is required for this functionality. Download it at:
https://www.kernel.org/pub/software/network/ethtool/
NOTE: When validating enable/disable tests on some parts (for example, 82578),
it is necessary to add a few seconds between tests when working with ethtool.
Speed and Duplex Configuration
------------------------------
In addressing speed and duplex configuration issues, you need to distinguish
between copper-based adapters and fiber-based adapters.
In the default mode, an Intel(R) Ethernet Network Adapter using copper
connections will attempt to auto-negotiate with its link partner to determine
the best setting. If the adapter cannot establish link with the link partner
using auto-negotiation, you may need to manually configure the adapter and link
partner to identical settings to establish link and pass packets. This should
only be needed when attempting to link with an older switch that does not
support auto-negotiation or one that has been forced to a specific speed or
duplex mode. Your link partner must match the setting you choose. 1 Gbps speeds
and higher cannot be forced. Use the autonegotiation advertising setting to
manually set devices for 1 Gbps and higher.
Speed, duplex, and autonegotiation advertising are configured through the
ethtool utility.
Caution: Only experienced network administrators should force speed and duplex
or change autonegotiation advertising manually. The settings at the switch must
always match the adapter settings. Adapter performance may suffer or your
adapter may not operate if you configure the adapter differently from your
switch.
An Intel(R) Ethernet Network Adapter using fiber-based connections, however,
will not attempt to auto-negotiate with its link partner since those adapters
operate only in full duplex and only at their native speed.
Enabling Wake on LAN (WoL)
--------------------------
WoL is configured through the ethtool utility.
WoL will be enabled on the system during the next shut down or reboot. For
this driver version, in order to enable WoL, the e1000e driver must be loaded
prior to shutting down or suspending the system.
NOTE: Wake on LAN is only supported on port A for the following devices:
- Intel(R) PRO/1000 PT Dual Port Network Connection
- Intel(R) PRO/1000 PT Dual Port Server Connection
- Intel(R) PRO/1000 PT Dual Port Server Adapter
- Intel(R) PRO/1000 PF Dual Port Server Adapter
- Intel(R) PRO/1000 PT Quad Port Server Adapter
- Intel(R) Gigabit PT Quad Port Server ExpressModule
Support
=======
For general information, go to the Intel support website at:
https://www.intel.com/support/
If an issue is identified with the released source code on a supported kernel
with a supported adapter, email the specific information related to the issue
to intel-wired-lan@lists.osuosl.org.
linux-7.2.3/Documentation/networking/device_drivers/ethernet/intel/fm10k.rst
+137
View File
@@ -0,0 +1,137 @@
.. SPDX-License-Identifier: GPL-2.0+
=============================================================
Linux Base Driver for Intel(R) Ethernet Multi-host Controller
=============================================================
August 20, 2018
Copyright(c) 2015-2018 Intel Corporation.
Contents
========
- Identifying Your Adapter
- Additional Configurations
- Performance Tuning
- Known Issues
- Support
Identifying Your Adapter
========================
The driver in this release is compatible with devices based on the Intel(R)
Ethernet Multi-host Controller.
For information on how to identify your adapter, and for the latest Intel
network drivers, refer to the Intel Support website:
https://www.intel.com/support
Flow Control
------------
The Intel(R) Ethernet Switch Host Interface Driver does not support Flow
Control. It will not send pause frames. This may result in dropped frames.
Virtual Functions (VFs)
-----------------------
Use sysfs to enable VFs.
Valid Range: 0-64
For example::
echo $num_vf_enabled > /sys/class/net/$dev/device/sriov_numvfs //enable VFs
echo 0 > /sys/class/net/$dev/device/sriov_numvfs //disable VFs
NOTE: Neither the device nor the driver control how VFs are mapped into config
space. Bus layout will vary by operating system. On operating systems that
support it, you can check sysfs to find the mapping.
NOTE: When SR-IOV mode is enabled, hardware VLAN filtering and VLAN tag
stripping/insertion will remain enabled. Please remove the old VLAN filter
before the new VLAN filter is added. For example::
ip link set eth0 vf 0 vlan 100 // set vlan 100 for VF 0
ip link set eth0 vf 0 vlan 0 // Delete vlan 100
ip link set eth0 vf 0 vlan 200 // set a new vlan 200 for VF 0
Additional Features and Configurations
======================================
Jumbo Frames
------------
Jumbo Frames support is enabled by changing the Maximum Transmission Unit (MTU)
to a value larger than the default value of 1500.
Use the ifconfig command to increase the MTU size. For example, enter the
following where <x> is the interface number::
ifconfig eth<x> mtu 9000 up
Alternatively, you can use the ip command as follows::
ip link set mtu 9000 dev eth<x>
ip link set up dev eth<x>
This setting is not saved across reboots. The setting change can be made
permanent by adding 'MTU=9000' to the file:
- For RHEL: /etc/sysconfig/network-scripts/ifcfg-eth<x>
- For SLES: /etc/sysconfig/network/<config_file>
NOTE: The maximum MTU setting for Jumbo Frames is 15342. This value coincides
with the maximum Jumbo Frames size of 15364 bytes.
NOTE: This driver will attempt to use multiple page sized buffers to receive
each jumbo packet. This should help to avoid buffer starvation issues when
allocating receive packets.
Generic Receive Offload, aka GRO
--------------------------------
The driver supports the in-kernel software implementation of GRO. GRO has
shown that by coalescing Rx traffic into larger chunks of data, CPU
utilization can be significantly reduced when under large Rx load. GRO is an
evolution of the previously-used LRO interface. GRO is able to coalesce
other protocols besides TCP. It's also safe to use with configurations that
are problematic for LRO, namely bridging and iSCSI.
Supported ethtool Commands and Options for Filtering
----------------------------------------------------
-n --show-nfc
Retrieves the receive network flow classification configurations.
rx-flow-hash tcp4|udp4|ah4|esp4|sctp4|tcp6|udp6|ah6|esp6|sctp6
Retrieves the hash options for the specified network traffic type.
-N --config-nfc
Configures the receive network flow classification.
rx-flow-hash tcp4|udp4|ah4|esp4|sctp4|tcp6|udp6|ah6|esp6|sctp6 m|v|t|s|d|f|n|r
Configures the hash options for the specified network traffic type.
- udp4: UDP over IPv4
- udp6: UDP over IPv6
- f Hash on bytes 0 and 1 of the Layer 4 header of the rx packet.
- n Hash on bytes 2 and 3 of the Layer 4 header of the rx packet.
Known Issues/Troubleshooting
============================
Enabling SR-IOV in a 64-bit Microsoft Windows Server 2012/R2 guest OS under Linux KVM
-------------------------------------------------------------------------------------
KVM Hypervisor/VMM supports direct assignment of a PCIe device to a VM. This
includes traditional PCIe devices, as well as SR-IOV-capable devices based on
the Intel Ethernet Controller XL710.
Support
=======
For general information, go to the Intel support website at:
https://www.intel.com/support/
If an issue is identified with the released source code on a supported kernel
with a supported adapter, email the specific information related to the issue
to intel-wired-lan@lists.osuosl.org.
linux-7.2.3/Documentation/networking/device_drivers/ethernet/intel/i40e.rst
+778
View File
@@ -0,0 +1,778 @@
.. SPDX-License-Identifier: GPL-2.0+
=================================================================
Linux Base Driver for the Intel(R) Ethernet Controller 700 Series
=================================================================
Intel 40 Gigabit Linux driver.
Copyright(c) 1999-2018 Intel Corporation.
Contents
========
- Overview
- Identifying Your Adapter
- Intel(R) Ethernet Flow Director
- Additional Configurations
- Known Issues
- Support
Driver information can be obtained using ethtool, lspci, and ifconfig.
Instructions on updating ethtool can be found in the section Additional
Configurations later in this document.
For questions related to hardware requirements, refer to the documentation
supplied with your Intel adapter. All hardware requirements listed apply to use
with Linux.
Identifying Your Adapter
========================
The driver is compatible with devices based on the following:
* Intel(R) Ethernet Controller X710
* Intel(R) Ethernet Controller XL710
* Intel(R) Ethernet Network Connection X722
* Intel(R) Ethernet Controller XXV710
For the best performance, make sure the latest NVM/FW is installed on your
device.
For information on how to identify your adapter, and for the latest NVM/FW
images and Intel network drivers, refer to the Intel Support website:
https://www.intel.com/support
SFP+ and QSFP+ Devices
----------------------
For information about supported media, refer to this document:
https://www.intel.com/content/dam/www/public/us/en/documents/release-notes/xl710-ethernet-controller-feature-matrix.pdf
NOTE: Some adapters based on the Intel(R) Ethernet Controller 700 Series only
support Intel Ethernet Optics modules. On these adapters, other modules are not
supported and will not function. In all cases Intel recommends using Intel
Ethernet Optics; other modules may function but are not validated by Intel.
Contact Intel for supported media types.
NOTE: For connections based on Intel(R) Ethernet Controller 700 Series, support
is dependent on your system board. Please see your vendor for details.
NOTE: In systems that do not have adequate airflow to cool the adapter and
optical modules, you must use high temperature optical modules.
Virtual Functions (VFs)
-----------------------
Use sysfs to enable VFs. For example::
#echo $num_vf_enabled > /sys/class/net/$dev/device/sriov_numvfs #enable VFs
#echo 0 > /sys/class/net/$dev/device/sriov_numvfs #disable VFs
For example, the following instructions will configure PF eth0 and the first VF
on VLAN 10::
$ ip link set dev eth0 vf 0 vlan 10
VLAN Tag Packet Steering
------------------------
Allows you to send all packets with a specific VLAN tag to a particular SR-IOV
virtual function (VF). Further, this feature allows you to designate a
particular VF as trusted, and allows that trusted VF to request selective
promiscuous mode on the Physical Function (PF).
To set a VF as trusted or untrusted, enter the following command in the
Hypervisor::
# ip link set dev eth0 vf 1 trust [on|off]
Once the VF is designated as trusted, use the following commands in the VM to
set the VF to promiscuous mode.
::
For promiscuous all:
#ip link set eth2 promisc on
Where eth2 is a VF interface in the VM
For promiscuous Multicast:
#ip link set eth2 allmulticast on
Where eth2 is a VF interface in the VM
NOTE: By default, the ethtool priv-flag vf-true-promisc-support is set to
"off",meaning that promiscuous mode for the VF will be limited. To set the
promiscuous mode for the VF to true promiscuous and allow the VF to see all
ingress traffic, use the following command::
#ethtool -set-priv-flags p261p1 vf-true-promisc-support on
The vf-true-promisc-support priv-flag does not enable promiscuous mode; rather,
it designates which type of promiscuous mode (limited or true) you will get
when you enable promiscuous mode using the ip link commands above. Note that
this is a global setting that affects the entire device. However,the
vf-true-promisc-support priv-flag is only exposed to the first PF of the
device. The PF remains in limited promiscuous mode (unless it is in MFP mode)
regardless of the vf-true-promisc-support setting.
Now add a VLAN interface on the VF interface::
#ip link add link eth2 name eth2.100 type vlan id 100
Note that the order in which you set the VF to promiscuous mode and add the
VLAN interface does not matter (you can do either first). The end result in
this example is that the VF will get all traffic that is tagged with VLAN 100.
Intel(R) Ethernet Flow Director
-------------------------------
The Intel Ethernet Flow Director performs the following tasks:
- Directs receive packets according to their flows to different queues.
- Enables tight control on routing a flow in the platform.
- Matches flows and CPU cores for flow affinity.
- Supports multiple parameters for flexible flow classification and load
balancing (in SFP mode only).
NOTE: The Linux i40e driver supports the following flow types: IPv4, TCPv4, and
UDPv4. For a given flow type, it supports valid combinations of IP addresses
(source or destination) and UDP/TCP ports (source and destination). For
example, you can supply only a source IP address, a source IP address and a
destination port, or any combination of one or more of these four parameters.
NOTE: The Linux i40e driver allows you to filter traffic based on a
user-defined flexible two-byte pattern and offset by using the ethtool user-def
and mask fields. Only L3 and L4 flow types are supported for user-defined
flexible filters. For a given flow type, you must clear all Intel Ethernet Flow
Director filters before changing the input set (for that flow type).
To enable or disable the Intel Ethernet Flow Director::
# ethtool -K ethX ntuple <on|off>
When disabling ntuple filters, all the user programmed filters are flushed from
the driver cache and hardware. All needed filters must be re-added when ntuple
is re-enabled.
To add a filter that directs packet to queue 2, use -U or -N switch::
# ethtool -N ethX flow-type tcp4 src-ip 192.168.10.1 dst-ip \
192.168.10.2 src-port 2000 dst-port 2001 action 2 [loc 1]
To set a filter using only the source and destination IP address::
# ethtool -N ethX flow-type tcp4 src-ip 192.168.10.1 dst-ip \
192.168.10.2 action 2 [loc 1]
To see the list of filters currently present::
# ethtool <-u|-n> ethX
Application Targeted Routing (ATR) Perfect Filters
--------------------------------------------------
ATR is enabled by default when the kernel is in multiple transmit queue mode.
An ATR Intel Ethernet Flow Director filter rule is added when a TCP-IP flow
starts and is deleted when the flow ends. When a TCP-IP Intel Ethernet Flow
Director rule is added from ethtool (Sideband filter), ATR is turned off by the
driver. To re-enable ATR, the sideband can be disabled with the ethtool -K
option. For example::
ethtool -K [adapter] ntuple [off|on]
If sideband is re-enabled after ATR is re-enabled, ATR remains enabled until a
TCP-IP flow is added. When all TCP-IP sideband rules are deleted, ATR is
automatically re-enabled.
Packets that match the ATR rules are counted in fdir_atr_match stats in
ethtool, which also can be used to verify whether ATR rules still exist.
Sideband Perfect Filters
------------------------
Sideband Perfect Filters are used to direct traffic that matches specified
characteristics. They are enabled through ethtool's ntuple interface. To add a
new filter use the following command::
ethtool -U <device> flow-type <type> src-ip <ip> dst-ip <ip> src-port <port> \
dst-port <port> action <queue>
Where:
<device> - the ethernet device to program
<type> - can be ip4, tcp4, udp4, or sctp4
<ip> - the ip address to match on
<port> - the port number to match on
<queue> - the queue to direct traffic towards (-1 discards matching traffic)
Use the following command to display all of the active filters::
ethtool -u <device>
Use the following command to delete a filter::
ethtool -U <device> delete <N>
Where <N> is the filter id displayed when printing all the active filters, and
may also have been specified using "loc <N>" when adding the filter.
The following example matches TCP traffic sent from 192.168.0.1, port 5300,
directed to 192.168.0.5, port 80, and sends it to queue 7::
ethtool -U enp130s0 flow-type tcp4 src-ip 192.168.0.1 dst-ip 192.168.0.5 \
src-port 5300 dst-port 80 action 7
For each flow-type, the programmed filters must all have the same matching
input set. For example, issuing the following two commands is acceptable::
ethtool -U enp130s0 flow-type ip4 src-ip 192.168.0.1 src-port 5300 action 7
ethtool -U enp130s0 flow-type ip4 src-ip 192.168.0.5 src-port 55 action 10
Issuing the next two commands, however, is not acceptable, since the first
specifies src-ip and the second specifies dst-ip::
ethtool -U enp130s0 flow-type ip4 src-ip 192.168.0.1 src-port 5300 action 7
ethtool -U enp130s0 flow-type ip4 dst-ip 192.168.0.5 src-port 55 action 10
The second command will fail with an error. You may program multiple filters
with the same fields, using different values, but, on one device, you may not
program two tcp4 filters with different matching fields.
Matching on a sub-portion of a field is not supported by the i40e driver, thus
partial mask fields are not supported.
The driver also supports matching user-defined data within the packet payload.
This flexible data is specified using the "user-def" field of the ethtool
command in the following way:
+----------------------------+--------------------------+
| 31 28 24 20 16 | 15 12 8 4 0 |
+----------------------------+--------------------------+
| offset into packet payload | 2 bytes of flexible data |
+----------------------------+--------------------------+
For example,
::
... user-def 0x4FFFF ...
tells the filter to look 4 bytes into the payload and match that value against
0xFFFF. The offset is based on the beginning of the payload, and not the
beginning of the packet. Thus
::
flow-type tcp4 ... user-def 0x8BEAF ...
would match TCP/IPv4 packets which have the value 0xBEAF 8 bytes into the
TCP/IPv4 payload.
Note that ICMP headers are parsed as 4 bytes of header and 4 bytes of payload.
Thus to match the first byte of the payload, you must actually add 4 bytes to
the offset. Also note that ip4 filters match both ICMP frames as well as raw
(unknown) ip4 frames, where the payload will be the L3 payload of the IP4 frame.
The maximum offset is 64. The hardware will only read up to 64 bytes of data
from the payload. The offset must be even because the flexible data is 2 bytes
long and must be aligned to byte 0 of the packet payload.
The user-defined flexible offset is also considered part of the input set and
cannot be programmed separately for multiple filters of the same type. However,
the flexible data is not part of the input set and multiple filters may use the
same offset but match against different data.
To create filters that direct traffic to a specific Virtual Function, use the
"action" parameter. Specify the action as a 64 bit value, where the lower 32
bits represents the queue number, while the next 8 bits represent which VF.
Note that 0 is the PF, so the VF identifier is offset by 1. For example::
... action 0x800000002 ...
specifies to direct traffic to Virtual Function 7 (8 minus 1) into queue 2 of
that VF.
Note that these filters will not break internal routing rules, and will not
route traffic that otherwise would not have been sent to the specified Virtual
Function.
Setting the link-down-on-close Private Flag
-------------------------------------------
When the link-down-on-close private flag is set to "on", the port's link will
go down when the interface is brought down using the ifconfig ethX down command.
Use ethtool to view and set link-down-on-close, as follows::
ethtool --show-priv-flags ethX
ethtool --set-priv-flags ethX link-down-on-close [on|off]
Setting the mdd-auto-reset-vf Private Flag
------------------------------------------
When the mdd-auto-reset-vf private flag is set to "on", the problematic VF will
be automatically reset if a malformed descriptor is detected. If the flag is
set to "off", the problematic VF will be disabled.
Use ethtool to view and set mdd-auto-reset-vf, as follows::
ethtool --show-priv-flags ethX
ethtool --set-priv-flags ethX mdd-auto-reset-vf [on|off]
Viewing Link Messages
---------------------
Link messages will not be displayed to the console if the distribution is
restricting system messages. In order to see network driver link messages on
your console, set dmesg to eight by entering the following::
dmesg -n 8
NOTE: This setting is not saved across reboots.
Jumbo Frames
------------
Jumbo Frames support is enabled by changing the Maximum Transmission Unit (MTU)
to a value larger than the default value of 1500.
Use the ifconfig command to increase the MTU size. For example, enter the
following where <x> is the interface number::
ifconfig eth<x> mtu 9000 up
Alternatively, you can use the ip command as follows::
ip link set mtu 9000 dev eth<x>
ip link set up dev eth<x>
This setting is not saved across reboots. The setting change can be made
permanent by adding 'MTU=9000' to the file::
/etc/sysconfig/network-scripts/ifcfg-eth<x> // for RHEL
/etc/sysconfig/network/<config_file> // for SLES
NOTE: The maximum MTU setting for Jumbo Frames is 9702. This value coincides
with the maximum Jumbo Frames size of 9728 bytes.
NOTE: This driver will attempt to use multiple page sized buffers to receive
each jumbo packet. This should help to avoid buffer starvation issues when
allocating receive packets.
ethtool
-------
The driver utilizes the ethtool interface for driver configuration and
diagnostics, as well as displaying statistical information. The latest ethtool
version is required for this functionality. Download it at:
https://www.kernel.org/pub/software/network/ethtool/
Supported ethtool Commands and Options for Filtering
----------------------------------------------------
-n --show-nfc
Retrieves the receive network flow classification configurations.
rx-flow-hash tcp4|udp4|ah4|esp4|sctp4|tcp6|udp6|ah6|esp6|sctp6
Retrieves the hash options for the specified network traffic type.
-N --config-nfc
Configures the receive network flow classification.
rx-flow-hash tcp4|udp4|ah4|esp4|sctp4|tcp6|udp6|ah6|esp6|sctp6 m|v|t|s|d|f|n|r...
Configures the hash options for the specified network traffic type.
udp4 UDP over IPv4
udp6 UDP over IPv6
f Hash on bytes 0 and 1 of the Layer 4 header of the Rx packet.
n Hash on bytes 2 and 3 of the Layer 4 header of the Rx packet.
Speed and Duplex Configuration
------------------------------
In addressing speed and duplex configuration issues, you need to distinguish
between copper-based adapters and fiber-based adapters.
In the default mode, an Intel(R) Ethernet Network Adapter using copper
connections will attempt to auto-negotiate with its link partner to determine
the best setting. If the adapter cannot establish link with the link partner
using auto-negotiation, you may need to manually configure the adapter and link
partner to identical settings to establish link and pass packets. This should
only be needed when attempting to link with an older switch that does not
support auto-negotiation or one that has been forced to a specific speed or
duplex mode. Your link partner must match the setting you choose. 1 Gbps speeds
and higher cannot be forced. Use the autonegotiation advertising setting to
manually set devices for 1 Gbps and higher.
NOTE: You cannot set the speed for devices based on the Intel(R) Ethernet
Network Adapter XXV710 based devices.
Speed, duplex, and autonegotiation advertising are configured through the
ethtool utility.
Caution: Only experienced network administrators should force speed and duplex
or change autonegotiation advertising manually. The settings at the switch must
always match the adapter settings. Adapter performance may suffer or your
adapter may not operate if you configure the adapter differently from your
switch.
An Intel(R) Ethernet Network Adapter using fiber-based connections, however,
will not attempt to auto-negotiate with its link partner since those adapters
operate only in full duplex and only at their native speed.
NAPI
----
NAPI (Rx polling mode) is supported in the i40e driver.
See :ref:`Documentation/networking/napi.rst <napi>` for more information.
Flow Control
------------
Ethernet Flow Control (IEEE 802.3x) can be configured with ethtool to enable
receiving and transmitting pause frames for i40e. When transmit is enabled,
pause frames are generated when the receive packet buffer crosses a predefined
threshold. When receive is enabled, the transmit unit will halt for the time
delay specified when a pause frame is received.
NOTE: You must have a flow control capable link partner.
Flow Control is on by default.
Use ethtool to change the flow control settings.
To enable or disable Rx or Tx Flow Control::
ethtool -A eth? rx <on|off> tx <on|off>
Note: This command only enables or disables Flow Control if auto-negotiation is
disabled. If auto-negotiation is enabled, this command changes the parameters
used for auto-negotiation with the link partner.
To enable or disable auto-negotiation::
ethtool -s eth? autoneg <on|off>
Note: Flow Control auto-negotiation is part of link auto-negotiation. Depending
on your device, you may not be able to change the auto-negotiation setting.
RSS Hash Flow
-------------
Allows you to set the hash bytes per flow type and any combination of one or
more options for Receive Side Scaling (RSS) hash byte configuration.
::
# ethtool -N <dev> rx-flow-hash <type> <option>
Where <type> is:
tcp4 signifying TCP over IPv4
udp4 signifying UDP over IPv4
tcp6 signifying TCP over IPv6
udp6 signifying UDP over IPv6
And <option> is one or more of:
s Hash on the IP source address of the Rx packet.
d Hash on the IP destination address of the Rx packet.
f Hash on bytes 0 and 1 of the Layer 4 header of the Rx packet.
n Hash on bytes 2 and 3 of the Layer 4 header of the Rx packet.
MAC and VLAN anti-spoofing feature
----------------------------------
When a malicious driver attempts to send a spoofed packet, it is dropped by the
hardware and not transmitted.
NOTE: This feature can be disabled for a specific Virtual Function (VF)::
ip link set <pf dev> vf <vf id> spoofchk {off|on}
IEEE 1588 Precision Time Protocol (PTP) Hardware Clock (PHC)
------------------------------------------------------------
Precision Time Protocol (PTP) is used to synchronize clocks in a computer
network. PTP support varies among Intel devices that support this driver. Use
"ethtool -T <netdev name>" to get a definitive list of PTP capabilities
supported by the device.
IEEE 802.1ad (QinQ) Support
---------------------------
The IEEE 802.1ad standard, informally known as QinQ, allows for multiple VLAN
IDs within a single Ethernet frame. VLAN IDs are sometimes referred to as
"tags," and multiple VLAN IDs are thus referred to as a "tag stack." Tag stacks
allow L2 tunneling and the ability to segregate traffic within a particular
VLAN ID, among other uses.
The following are examples of how to configure 802.1ad (QinQ)::
ip link add link eth0 eth0.24 type vlan proto 802.1ad id 24
ip link add link eth0.24 eth0.24.371 type vlan proto 802.1Q id 371
Where "24" and "371" are example VLAN IDs.
NOTES:
Receive checksum offloads, cloud filters, and VLAN acceleration are not
supported for 802.1ad (QinQ) packets.
VXLAN and GENEVE Overlay HW Offloading
--------------------------------------
Virtual Extensible LAN (VXLAN) allows you to extend an L2 network over an L3
network, which may be useful in a virtualized or cloud environment. Some
Intel(R) Ethernet Network devices perform VXLAN processing, offloading it from
the operating system. This reduces CPU utilization.
VXLAN offloading is controlled by the Tx and Rx checksum offload options
provided by ethtool. That is, if Tx checksum offload is enabled, and the
adapter has the capability, VXLAN offloading is also enabled.
Support for VXLAN and GENEVE HW offloading is dependent on kernel support of
the HW offloading features.
Multiple Functions per Port
---------------------------
Some adapters based on the Intel Ethernet Controller X710/XL710 support
multiple functions on a single physical port. Configure these functions through
the System Setup/BIOS.
Minimum TX Bandwidth is the guaranteed minimum data transmission bandwidth, as
a percentage of the full physical port link speed, that the partition will
receive. The bandwidth the partition is awarded will never fall below the level
you specify.
The range for the minimum bandwidth values is:
1 to ((100 minus # of partitions on the physical port) plus 1)
For example, if a physical port has 4 partitions, the range would be:
1 to ((100 - 4) + 1 = 97)
The Maximum Bandwidth percentage represents the maximum transmit bandwidth
allocated to the partition as a percentage of the full physical port link
speed. The accepted range of values is 1-100. The value is used as a limiter,
should you chose that any one particular function not be able to consume 100%
of a port's bandwidth (should it be available). The sum of all the values for
Maximum Bandwidth is not restricted, because no more than 100% of a port's
bandwidth can ever be used.
NOTE: X710/XXV710 devices fail to enable Max VFs (64) when Multiple Functions
per Port (MFP) and SR-IOV are enabled. An error from i40e is logged that says
"add vsi failed for VF N, aq_err 16". To workaround the issue, enable less than
64 virtual functions (VFs).
Data Center Bridging (DCB)
--------------------------
DCB is a configuration Quality of Service implementation in hardware. It uses
the VLAN priority tag (802.1p) to filter traffic. That means that there are 8
different priorities that traffic can be filtered into. It also enables
priority flow control (802.1Qbb) which can limit or eliminate the number of
dropped packets during network stress. Bandwidth can be allocated to each of
these priorities, which is enforced at the hardware level (802.1Qaz).
Adapter firmware implements LLDP and DCBX protocol agents as per 802.1AB and
802.1Qaz respectively. The firmware based DCBX agent runs in willing mode only
and can accept settings from a DCBX capable peer. Software configuration of
DCBX parameters via dcbtool/lldptool are not supported.
NOTE: Firmware LLDP can be disabled by setting the private flag disable-fw-lldp.
The i40e driver implements the DCB netlink interface layer to allow user-space
to communicate with the driver and query DCB configuration for the port.
NOTE:
The kernel assumes that TC0 is available, and will disable Priority Flow
Control (PFC) on the device if TC0 is not available. To fix this, ensure TC0 is
enabled when setting up DCB on your switch.
Interrupt Rate Limiting
-----------------------
:Valid Range: 0-235 (0=no limit)
The Intel(R) Ethernet Controller XL710 family supports an interrupt rate
limiting mechanism. The user can control, via ethtool, the number of
microseconds between interrupts.
Syntax::
# ethtool -C ethX rx-usecs-high N
The range of 0-235 microseconds provides an effective range of 4,310 to 250,000
interrupts per second. The value of rx-usecs-high can be set independently of
rx-usecs and tx-usecs in the same ethtool command, and is also independent of
the adaptive interrupt moderation algorithm. The underlying hardware supports
granularity in 4-microsecond intervals, so adjacent values may result in the
same interrupt rate.
One possible use case is the following::
# ethtool -C ethX adaptive-rx off adaptive-tx off rx-usecs-high 20 rx-usecs \
5 tx-usecs 5
The above command would disable adaptive interrupt moderation, and allow a
maximum of 5 microseconds before indicating a receive or transmit was complete.
However, instead of resulting in as many as 200,000 interrupts per second, it
limits total interrupts per second to 50,000 via the rx-usecs-high parameter.
Performance Optimization
========================
Driver defaults are meant to fit a wide variety of workloads, but if further
optimization is required we recommend experimenting with the following settings.
NOTE: For better performance when processing small (64B) frame sizes, try
enabling Hyper threading in the BIOS in order to increase the number of logical
cores in the system and subsequently increase the number of queues available to
the adapter.
Virtualized Environments
------------------------
1. Disable XPS on both ends by using the included virt_perf_default script
or by running the following command as root::
for file in `ls /sys/class/net/<ethX>/queues/tx-*/xps_cpus`;
do echo 0 > $file; done
2. Using the appropriate mechanism (vcpupin) in the vm, pin the cpu's to
individual lcpu's, making sure to use a set of cpu's included in the
device's local_cpulist: /sys/class/net/<ethX>/device/local_cpulist.
3. Configure as many Rx/Tx queues in the VM as available. Do not rely on
the default setting of 1.
Non-virtualized Environments
----------------------------
Pin the adapter's IRQs to specific cores by disabling the irqbalance service
and using the included set_irq_affinity script. Please see the script's help
text for further options.
- The following settings will distribute the IRQs across all the cores evenly::
# scripts/set_irq_affinity -x all <interface1> , [ <interface2>, ... ]
- The following settings will distribute the IRQs across all the cores that are
local to the adapter (same NUMA node)::
# scripts/set_irq_affinity -x local <interface1> ,[ <interface2>, ... ]
For very CPU intensive workloads, we recommend pinning the IRQs to all cores.
For IP Forwarding: Disable Adaptive ITR and lower Rx and Tx interrupts per
queue using ethtool.
- Setting rx-usecs and tx-usecs to 125 will limit interrupts to about 8000
interrupts per second per queue.
::
# ethtool -C <interface> adaptive-rx off adaptive-tx off rx-usecs 125 \
tx-usecs 125
For lower CPU utilization: Disable Adaptive ITR and lower Rx and Tx interrupts
per queue using ethtool.
- Setting rx-usecs and tx-usecs to 250 will limit interrupts to about 4000
interrupts per second per queue.
::
# ethtool -C <interface> adaptive-rx off adaptive-tx off rx-usecs 250 \
tx-usecs 250
For lower latency: Disable Adaptive ITR and ITR by setting Rx and Tx to 0 using
ethtool.
::
# ethtool -C <interface> adaptive-rx off adaptive-tx off rx-usecs 0 \
tx-usecs 0
Application Device Queues (ADq)
-------------------------------
Application Device Queues (ADq) allows you to dedicate one or more queues to a
specific application. This can reduce latency for the specified application,
and allow Tx traffic to be rate limited per application. Follow the steps below
to set ADq.
1. Create traffic classes (TCs). Maximum of 8 TCs can be created per interface.
The shaper bw_rlimit parameter is optional.
Example: Sets up two tcs, tc0 and tc1, with 16 queues each and max tx rate set
to 1Gbit for tc0 and 3Gbit for tc1.
::
# tc qdisc add dev <interface> root mqprio num_tc 2 map 0 0 0 0 1 1 1 1
queues 16@0 16@16 hw 1 mode channel shaper bw_rlimit min_rate 1Gbit 2Gbit
max_rate 1Gbit 3Gbit
map: priority mapping for up to 16 priorities to tcs (e.g. map 0 0 0 0 1 1 1 1
sets priorities 0-3 to use tc0 and 4-7 to use tc1)
queues: for each tc, <num queues>@<offset> (e.g. queues 16@0 16@16 assigns
16 queues to tc0 at offset 0 and 16 queues to tc1 at offset 16. Max total
number of queues for all tcs is 64 or number of cores, whichever is lower.)
hw 1 mode channel: ‘channel’ with ‘hw’ set to 1 is a new new hardware
offload mode in mqprio that makes full use of the mqprio options, the
TCs, the queue configurations, and the QoS parameters.
shaper bw_rlimit: for each tc, sets minimum and maximum bandwidth rates.
Totals must be equal or less than port speed.
For example: min_rate 1Gbit 3Gbit: Verify bandwidth limit using network
monitoring tools such as `ifstat` or `sar -n DEV [interval] [number of samples]`
2. Enable HW TC offload on interface::
# ethtool -K <interface> hw-tc-offload on
3. Apply TCs to ingress (RX) flow of interface::
# tc qdisc add dev <interface> ingress
NOTES:
- Run all tc commands from the iproute2 <pathtoiproute2>/tc/ directory.
- ADq is not compatible with cloud filters.
- Setting up channels via ethtool (ethtool -L) is not supported when the
TCs are configured using mqprio.
- You must have iproute2 latest version
- NVM version 6.01 or later is required.
- ADq cannot be enabled when any the following features are enabled: Data
Center Bridging (DCB), Multiple Functions per Port (MFP), or Sideband
Filters.
- If another driver (for example, DPDK) has set cloud filters, you cannot
enable ADq.
- Tunnel filters are not supported in ADq. If encapsulated packets do
arrive in non-tunnel mode, filtering will be done on the inner headers.
For example, for VXLAN traffic in non-tunnel mode, PCTYPE is identified
as a VXLAN encapsulated packet, outer headers are ignored. Therefore,
inner headers are matched.
- If a TC filter on a PF matches traffic over a VF (on the PF), that
traffic will be routed to the appropriate queue of the PF, and will
not be passed on the VF. Such traffic will end up getting dropped higher
up in the TCP/IP stack as it does not match PF address data.
- If traffic matches multiple TC filters that point to different TCs,
that traffic will be duplicated and sent to all matching TC queues.
The hardware switch mirrors the packet to a VSI list when multiple
filters are matched.
Known Issues/Troubleshooting
============================
NOTE: 1 Gb devices based on the Intel(R) Ethernet Network Connection X722 do
not support the following features:
* Data Center Bridging (DCB)
* QOS
* VMQ
* SR-IOV
* Task Encapsulation offload (VXLAN, NVGRE)
* Energy Efficient Ethernet (EEE)
* Auto-media detect
Unexpected Issues when the device driver and DPDK share a device
----------------------------------------------------------------
Unexpected issues may result when an i40e device is in multi driver mode and
the kernel driver and DPDK driver are sharing the device. This is because
access to the global NIC resources is not synchronized between multiple
drivers. Any change to the global NIC configuration (writing to a global
register, setting global configuration by AQ, or changing switch modes) will
affect all ports and drivers on the device. Loading DPDK with the
"multi-driver" module parameter may mitigate some of the issues.
TC0 must be enabled when setting up DCB on a switch
---------------------------------------------------
The kernel assumes that TC0 is available, and will disable Priority Flow
Control (PFC) on the device if TC0 is not available. To fix this, ensure TC0 is
enabled when setting up DCB on your switch.
Support
=======
For general information, go to the Intel support website at:
https://www.intel.com/support/
If an issue is identified with the released source code on a supported kernel
with a supported adapter, email the specific information related to the issue
to intel-wired-lan@lists.osuosl.org.
linux-7.2.3/Documentation/networking/device_drivers/ethernet/intel/iavf.rst
+326
View File
@@ -0,0 +1,326 @@
.. SPDX-License-Identifier: GPL-2.0+
=================================================================
Linux Base Driver for Intel(R) Ethernet Adaptive Virtual Function
=================================================================
Intel Ethernet Adaptive Virtual Function Linux driver.
Copyright(c) 2013-2018 Intel Corporation.
Contents
========
- Overview
- Identifying Your Adapter
- Additional Configurations
- Known Issues/Troubleshooting
- Support
Overview
========
This file describes the iavf Linux Base Driver. This driver was formerly
called i40evf.
The iavf driver supports the below mentioned virtual function devices and
can only be activated on kernels running the i40e or newer Physical Function
(PF) driver compiled with CONFIG_PCI_IOV. The iavf driver requires
CONFIG_PCI_MSI to be enabled.
The guest OS loading the iavf driver must support MSI-X interrupts.
Identifying Your Adapter
========================
The driver in this kernel is compatible with devices based on the following:
* Intel(R) XL710 X710 Virtual Function
* Intel(R) X722 Virtual Function
* Intel(R) XXV710 Virtual Function
* Intel(R) Ethernet Adaptive Virtual Function
For the best performance, make sure the latest NVM/FW is installed on your
device.
For information on how to identify your adapter, and for the latest NVM/FW
images and Intel network drivers, refer to the Intel Support website:
https://www.intel.com/support
Additional Features and Configurations
======================================
Viewing Link Messages
---------------------
Link messages will not be displayed to the console if the distribution is
restricting system messages. In order to see network driver link messages on
your console, set dmesg to eight by entering the following::
# dmesg -n 8
NOTE:
This setting is not saved across reboots.
ethtool
-------
The driver utilizes the ethtool interface for driver configuration and
diagnostics, as well as displaying statistical information. The latest ethtool
version is required for this functionality. Download it at:
https://www.kernel.org/pub/software/network/ethtool/
Setting VLAN Tag Stripping
--------------------------
If you have applications that require Virtual Functions (VFs) to receive
packets with VLAN tags, you can disable VLAN tag stripping for the VF. The
Physical Function (PF) processes requests issued from the VF to enable or
disable VLAN tag stripping. Note that if the PF has assigned a VLAN to a VF,
then requests from that VF to set VLAN tag stripping will be ignored.
To enable/disable VLAN tag stripping for a VF, issue the following command
from inside the VM in which you are running the VF::
# ethtool -K <if_name> rxvlan on/off
or alternatively::
# ethtool --offload <if_name> rxvlan on/off
Adaptive Virtual Function
-------------------------
Adaptive Virtual Function (AVF) allows the virtual function driver, or VF, to
adapt to changing feature sets of the physical function driver (PF) with which
it is associated. This allows system administrators to update a PF without
having to update all the VFs associated with it. All AVFs have a single common
device ID and branding string.
AVFs have a minimum set of features known as "base mode," but may provide
additional features depending on what features are available in the PF with
which the AVF is associated. The following are base mode features:
- 4 Queue Pairs (QP) and associated Configuration Status Registers (CSRs)
for Tx/Rx
- i40e descriptors and ring format
- Descriptor write-back completion
- 1 control queue, with i40e descriptors, CSRs and ring format
- 5 MSI-X interrupt vectors and corresponding i40e CSRs
- 1 Interrupt Throttle Rate (ITR) index
- 1 Virtual Station Interface (VSI) per VF
- 1 Traffic Class (TC), TC0
- Receive Side Scaling (RSS) with 64 entry indirection table and key,
configured through the PF
- 1 unicast MAC address reserved per VF
- 16 MAC address filters for each VF
- Stateless offloads - non-tunneled checksums
- AVF device ID
- HW mailbox is used for VF to PF communications (including on Windows)
IEEE 802.1ad (QinQ) Support
---------------------------
The IEEE 802.1ad standard, informally known as QinQ, allows for multiple VLAN
IDs within a single Ethernet frame. VLAN IDs are sometimes referred to as
"tags," and multiple VLAN IDs are thus referred to as a "tag stack." Tag stacks
allow L2 tunneling and the ability to segregate traffic within a particular
VLAN ID, among other uses.
The following are examples of how to configure 802.1ad (QinQ)::
# ip link add link eth0 eth0.24 type vlan proto 802.1ad id 24
# ip link add link eth0.24 eth0.24.371 type vlan proto 802.1Q id 371
Where "24" and "371" are example VLAN IDs.
NOTES:
Receive checksum offloads, cloud filters, and VLAN acceleration are not
supported for 802.1ad (QinQ) packets.
Application Device Queues (ADq)
-------------------------------
Application Device Queues (ADq) allows you to dedicate one or more queues to a
specific application. This can reduce latency for the specified application,
and allow Tx traffic to be rate limited per application. Follow the steps below
to set ADq.
Requirements:
- The sch_mqprio, act_mirred and cls_flower modules must be loaded
- The latest version of iproute2
- If another driver (for example, DPDK) has set cloud filters, you cannot
enable ADQ
- Depending on the underlying PF device, ADQ cannot be enabled when the
following features are enabled:
+ Data Center Bridging (DCB)
+ Multiple Functions per Port (MFP)
+ Sideband Filters
1. Create traffic classes (TCs). Maximum of 8 TCs can be created per interface.
The shaper bw_rlimit parameter is optional.
Example: Sets up two tcs, tc0 and tc1, with 16 queues each and max tx rate set
to 1Gbit for tc0 and 3Gbit for tc1.
::
tc qdisc add dev <interface> root mqprio num_tc 2 map 0 0 0 0 1 1 1 1
queues 16@0 16@16 hw 1 mode channel shaper bw_rlimit min_rate 1Gbit 2Gbit
max_rate 1Gbit 3Gbit
map: priority mapping for up to 16 priorities to tcs (e.g. map 0 0 0 0 1 1 1 1
sets priorities 0-3 to use tc0 and 4-7 to use tc1)
queues: for each tc, <num queues>@<offset> (e.g. queues 16@0 16@16 assigns
16 queues to tc0 at offset 0 and 16 queues to tc1 at offset 16. Max total
number of queues for all tcs is 64 or number of cores, whichever is lower.)
hw 1 mode channel: ‘channel’ with ‘hw’ set to 1 is a new new hardware
offload mode in mqprio that makes full use of the mqprio options, the
TCs, the queue configurations, and the QoS parameters.
shaper bw_rlimit: for each tc, sets minimum and maximum bandwidth rates.
Totals must be equal or less than port speed.
For example: min_rate 1Gbit 3Gbit: Verify bandwidth limit using network
monitoring tools such as ``ifstat`` or ``sar -n DEV [interval] [number of samples]``
NOTE:
Setting up channels via ethtool (ethtool -L) is not supported when the
TCs are configured using mqprio.
2. Enable HW TC offload on interface::
# ethtool -K <interface> hw-tc-offload on
3. Apply TCs to ingress (RX) flow of interface::
# tc qdisc add dev <interface> ingress
NOTES:
- Run all tc commands from the iproute2 <pathtoiproute2>/tc/ directory
- ADq is not compatible with cloud filters
- Setting up channels via ethtool (ethtool -L) is not supported when the TCs
are configured using mqprio
- You must have iproute2 latest version
- NVM version 6.01 or later is required
- ADq cannot be enabled when any the following features are enabled: Data
Center Bridging (DCB), Multiple Functions per Port (MFP), or Sideband Filters
- If another driver (for example, DPDK) has set cloud filters, you cannot
enable ADq
- Tunnel filters are not supported in ADq. If encapsulated packets do arrive
in non-tunnel mode, filtering will be done on the inner headers. For example,
for VXLAN traffic in non-tunnel mode, PCTYPE is identified as a VXLAN
encapsulated packet, outer headers are ignored. Therefore, inner headers are
matched.
- If a TC filter on a PF matches traffic over a VF (on the PF), that traffic
will be routed to the appropriate queue of the PF, and will not be passed on
the VF. Such traffic will end up getting dropped higher up in the TCP/IP
stack as it does not match PF address data.
- If traffic matches multiple TC filters that point to different TCs, that
traffic will be duplicated and sent to all matching TC queues. The hardware
switch mirrors the packet to a VSI list when multiple filters are matched.
Known Issues/Troubleshooting
============================
Bonding fails with VFs bound to an Intel(R) Ethernet Controller 700 series device
---------------------------------------------------------------------------------
If you bind Virtual Functions (VFs) to an Intel(R) Ethernet Controller 700
series based device, the VF slaves may fail when they become the active slave.
If the MAC address of the VF is set by the PF (Physical Function) of the
device, when you add a slave, or change the active-backup slave, Linux bonding
tries to sync the backup slave's MAC address to the same MAC address as the
active slave. Linux bonding will fail at this point. This issue will not occur
if the VF's MAC address is not set by the PF.
Traffic Is Not Being Passed Between VM and Client
-------------------------------------------------
You may not be able to pass traffic between a client system and a
Virtual Machine (VM) running on a separate host if the Virtual Function
(VF, or Virtual NIC) is not in trusted mode and spoof checking is enabled
on the VF. Note that this situation can occur in any combination of client,
host, and guest operating system. For information on how to set the VF to
trusted mode, refer to the section "VLAN Tag Packet Steering" in this
readme document. For information on setting spoof checking, refer to the
section "MAC and VLAN anti-spoofing feature" in this readme document.
Do not unload port driver if VF with active VM is bound to it
-------------------------------------------------------------
Do not unload a port's driver if a Virtual Function (VF) with an active Virtual
Machine (VM) is bound to it. Doing so will cause the port to appear to hang.
Once the VM shuts down, or otherwise releases the VF, the command will complete.
Using four traffic classes fails
--------------------------------
Do not try to reserve more than three traffic classes in the iavf driver. Doing
so will fail to set any traffic classes and will cause the driver to write
errors to stdout. Use a maximum of three queues to avoid this issue.
Multiple log error messages on iavf driver removal
--------------------------------------------------
If you have several VFs and you remove the iavf driver, several instances of
the following log errors are written to the log::
Unable to send opcode 2 to PF, err I40E_ERR_QUEUE_EMPTY, aq_err ok
Unable to send the message to VF 2 aq_err 12
ARQ Overflow Error detected
Virtual machine does not get link
---------------------------------
If the virtual machine has more than one virtual port assigned to it, and those
virtual ports are bound to different physical ports, you may not get link on
all of the virtual ports. The following command may work around the issue::
# ethtool -r <PF>
Where <PF> is the PF interface in the host, for example: p5p1. You may need to
run the command more than once to get link on all virtual ports.
MAC address of Virtual Function changes unexpectedly
----------------------------------------------------
If a Virtual Function's MAC address is not assigned in the host, then the VF
(virtual function) driver will use a random MAC address. This random MAC
address may change each time the VF driver is reloaded. You can assign a static
MAC address in the host machine. This static MAC address will survive
a VF driver reload.
Driver Buffer Overflow Fix
--------------------------
The fix to resolve CVE-2016-8105, referenced in Intel SA-00069
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00069.html
is included in this and future versions of the driver.
Multiple Interfaces on Same Ethernet Broadcast Network
------------------------------------------------------
Due to the default ARP behavior on Linux, it is not possible to have one system
on two IP networks in the same Ethernet broadcast domain (non-partitioned
switch) behave as expected. All Ethernet interfaces will respond to IP traffic
for any IP address assigned to the system. This results in unbalanced receive
traffic.
If you have multiple interfaces in a server, either turn on ARP filtering by
entering::
# echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter
NOTE:
This setting is not saved across reboots. The configuration change can be
made permanent by adding the following line to the file /etc/sysctl.conf::
net.ipv4.conf.all.arp_filter = 1
Another alternative is to install the interfaces in separate broadcast domains
(either in different switches or in a switch partitioned to VLANs).
Rx Page Allocation Errors
-------------------------
'Page allocation failure. order:0' errors may occur under stress.
This is caused by the way the Linux kernel reports this stressed condition.
Support
=======
For general information, go to the Intel support website at:
https://support.intel.com
If an issue is identified with the released source code on the supported kernel
with a supported adapter, email the specific information related to the issue
to intel-wired-lan@lists.osuosl.org.
linux-7.2.3/Documentation/networking/device_drivers/ethernet/intel/ice.rst
+1219
View File
File diff suppressed because it is too large Load Diff
linux-7.2.3/Documentation/networking/device_drivers/ethernet/intel/idpf.rst
+160
View File
@@ -0,0 +1,160 @@
.. SPDX-License-Identifier: GPL-2.0+
==========================================================================
idpf Linux* Base Driver for the Intel(R) Infrastructure Data Path Function
==========================================================================
Intel idpf Linux driver.
Copyright(C) 2023 Intel Corporation.
.. contents::
The idpf driver serves as both the Physical Function (PF) and Virtual Function
(VF) driver for the Intel(R) Infrastructure Data Path Function.
Driver information can be obtained using ethtool, lspci, and ip.
For questions related to hardware requirements, refer to the documentation
supplied with your Intel adapter. All hardware requirements listed apply to use
with Linux.
Identifying Your Adapter
========================
For information on how to identify your adapter, and for the latest Intel
network drivers, refer to the Intel Support website:
http://www.intel.com/support
Additional Features and Configurations
======================================
ethtool
-------
The driver utilizes the ethtool interface for driver configuration and
diagnostics, as well as displaying statistical information. The latest ethtool
version is required for this functionality. If you don't have one yet, you can
obtain it at:
https://kernel.org/pub/software/network/ethtool/
Viewing Link Messages
---------------------
Link messages will not be displayed to the console if the distribution is
restricting system messages. In order to see network driver link messages on
your console, set dmesg to eight by entering the following::
# dmesg -n 8
.. note::
This setting is not saved across reboots.
Jumbo Frames
------------
Jumbo Frames support is enabled by changing the Maximum Transmission Unit (MTU)
to a value larger than the default value of 1500.
Use the ip command to increase the MTU size. For example, enter the following
where <ethX> is the interface number::
# ip link set mtu 9000 dev <ethX>
# ip link set up dev <ethX>
.. note::
The maximum MTU setting for jumbo frames is 9706. This corresponds to the
maximum jumbo frame size of 9728 bytes.
.. note::
This driver will attempt to use multiple page sized buffers to receive
each jumbo packet. This should help to avoid buffer starvation issues when
allocating receive packets.
.. note::
Packet loss may have a greater impact on throughput when you use jumbo
frames. If you observe a drop in performance after enabling jumbo frames,
enabling flow control may mitigate the issue.
Performance Optimization
========================
Driver defaults are meant to fit a wide variety of workloads, but if further
optimization is required, we recommend experimenting with the following
settings.
Interrupt Rate Limiting
-----------------------
This driver supports an adaptive interrupt throttle rate (ITR) mechanism that
is tuned for general workloads. The user can customize the interrupt rate
control for specific workloads, via ethtool, adjusting the number of
microseconds between interrupts.
To set the interrupt rate manually, you must disable adaptive mode::
# ethtool -C <ethX> adaptive-rx off adaptive-tx off
For lower CPU utilization:
- Disable adaptive ITR and lower Rx and Tx interrupts. The examples below
affect every queue of the specified interface.
- Setting rx-usecs and tx-usecs to 80 will limit interrupts to about
12,500 interrupts per second per queue::
# ethtool -C <ethX> adaptive-rx off adaptive-tx off rx-usecs 80
tx-usecs 80
For reduced latency:
- Disable adaptive ITR and ITR by setting rx-usecs and tx-usecs to 0
using ethtool::
# ethtool -C <ethX> adaptive-rx off adaptive-tx off rx-usecs 0
tx-usecs 0
Per-queue interrupt rate settings:
- The following examples are for queues 1 and 3, but you can adjust other
queues.
- To disable Rx adaptive ITR and set static Rx ITR to 10 microseconds or
about 100,000 interrupts/second, for queues 1 and 3::
# ethtool --per-queue <ethX> queue_mask 0xa --coalesce adaptive-rx off
rx-usecs 10
- To show the current coalesce settings for queues 1 and 3::
# ethtool --per-queue <ethX> queue_mask 0xa --show-coalesce
Virtualized Environments
------------------------
In addition to the other suggestions in this section, the following may be
helpful to optimize performance in VMs.
- Using the appropriate mechanism (vcpupin) in the VM, pin the CPUs to
individual LCPUs, making sure to use a set of CPUs included in the
device's local_cpulist: /sys/class/net/<ethX>/device/local_cpulist.
- Configure as many Rx/Tx queues in the VM as available. (See the idpf driver
documentation for the number of queues supported.) For example::
# ethtool -L <virt_interface> rx <max> tx <max>
Support
=======
For general information, go to the Intel support website at:
http://www.intel.com/support/
If an issue is identified with the released source code on a supported kernel
with a supported adapter, email the specific information related to the issue
to intel-wired-lan@lists.osuosl.org.
Trademarks
==========
Intel is a trademark or registered trademark of Intel Corporation or its
subsidiaries in the United States and/or other countries.
* Other names and brands may be claimed as the property of others.
linux-7.2.3/Documentation/networking/device_drivers/ethernet/intel/igb.rst
+208
View File
@@ -0,0 +1,208 @@
.. SPDX-License-Identifier: GPL-2.0+
==========================================================
Linux Base Driver for Intel(R) Ethernet Network Connection
==========================================================
Intel Gigabit Linux driver.
Copyright(c) 1999-2018 Intel Corporation.
Contents
========
- Identifying Your Adapter
- Command Line Parameters
- Additional Configurations
- Support
Identifying Your Adapter
========================
For information on how to identify your adapter, and for the latest Intel
network drivers, refer to the Intel Support website:
https://www.intel.com/support
Command Line Parameters
========================
If the driver is built as a module, the following optional parameters are used
by entering them on the command line with the modprobe command using this
syntax::
modprobe igb [<option>=<VAL1>,<VAL2>,...]
There needs to be a <VAL#> for each network port in the system supported by
this driver. The values will be applied to each instance, in function order.
For example::
modprobe igb max_vfs=2,4
In this case, there are two network ports supported by igb in the system.
NOTE: A descriptor describes a data buffer and attributes related to the data
buffer. This information is accessed by the hardware.
max_vfs
-------
:Valid Range: 0-7
This parameter adds support for SR-IOV. It causes the driver to spawn up to
max_vfs worth of virtual functions. If the value is greater than 0 it will
also force the VMDq parameter to be 1 or more.
The parameters for the driver are referenced by position. Thus, if you have a
dual port adapter, or more than one adapter in your system, and want N virtual
functions per port, you must specify a number for each port with each parameter
separated by a comma. For example::
modprobe igb max_vfs=4
This will spawn 4 VFs on the first port.
::
modprobe igb max_vfs=2,4
This will spawn 2 VFs on the first port and 4 VFs on the second port.
NOTE: Caution must be used in loading the driver with these parameters.
Depending on your system configuration, number of slots, etc., it is impossible
to predict in all cases where the positions would be on the command line.
NOTE: Neither the device nor the driver control how VFs are mapped into config
space. Bus layout will vary by operating system. On operating systems that
support it, you can check sysfs to find the mapping.
NOTE: When either SR-IOV mode or VMDq mode is enabled, hardware VLAN filtering
and VLAN tag stripping/insertion will remain enabled. Please remove the old
VLAN filter before the new VLAN filter is added. For example::
ip link set eth0 vf 0 vlan 100 // set vlan 100 for VF 0
ip link set eth0 vf 0 vlan 0 // Delete vlan 100
ip link set eth0 vf 0 vlan 200 // set a new vlan 200 for VF 0
Debug
-----
:Valid Range: 0-16 (0=none,...,16=all)
:Default Value: 0
This parameter adjusts the level debug messages displayed in the system logs.
Additional Features and Configurations
======================================
Jumbo Frames
------------
Jumbo Frames support is enabled by changing the Maximum Transmission Unit (MTU)
to a value larger than the default value of 1500.
Use the ifconfig command to increase the MTU size. For example, enter the
following where <x> is the interface number::
ifconfig eth<x> mtu 9000 up
Alternatively, you can use the ip command as follows::
ip link set mtu 9000 dev eth<x>
ip link set up dev eth<x>
This setting is not saved across reboots. The setting change can be made
permanent by adding 'MTU=9000' to the file:
- For RHEL: /etc/sysconfig/network-scripts/ifcfg-eth<x>
- For SLES: /etc/sysconfig/network/<config_file>
NOTE: The maximum MTU setting for Jumbo Frames is 9216. This value coincides
with the maximum Jumbo Frames size of 9234 bytes.
NOTE: Using Jumbo frames at 10 or 100 Mbps is not supported and may result in
poor performance or loss of link.
ethtool
-------
The driver utilizes the ethtool interface for driver configuration and
diagnostics, as well as displaying statistical information. The latest ethtool
version is required for this functionality. Download it at:
https://www.kernel.org/pub/software/network/ethtool/
Enabling Wake on LAN (WoL)
--------------------------
WoL is configured through the ethtool utility.
WoL will be enabled on the system during the next shut down or reboot. For
this driver version, in order to enable WoL, the igb driver must be loaded
prior to shutting down or suspending the system.
NOTE: Wake on LAN is only supported on port A of multi-port devices. Also
Wake On LAN is not supported for the following device:
- Intel(R) Gigabit VT Quad Port Server Adapter
Multiqueue
----------
In this mode, a separate MSI-X vector is allocated for each queue and one for
"other" interrupts such as link status change and errors. All interrupts are
throttled via interrupt moderation. Interrupt moderation must be used to avoid
interrupt storms while the driver is processing one interrupt. The moderation
value should be at least as large as the expected time for the driver to
process an interrupt. Multiqueue is off by default.
REQUIREMENTS: MSI-X support is required for Multiqueue. If MSI-X is not found,
the system will fallback to MSI or to Legacy interrupts. This driver supports
receive multiqueue on all kernels that support MSI-X.
NOTE: On some kernels a reboot is required to switch between single queue mode
and multiqueue mode or vice-versa.
MAC and VLAN anti-spoofing feature
----------------------------------
When a malicious driver attempts to send a spoofed packet, it is dropped by the
hardware and not transmitted.
An interrupt is sent to the PF driver notifying it of the spoof attempt. When a
spoofed packet is detected, the PF driver will send the following message to
the system log (displayed by the "dmesg" command):
Spoof event(s) detected on VF(n), where n = the VF that attempted to do the
spoofing
Setting MAC Address, VLAN and Rate Limit Using IProute2 Tool
------------------------------------------------------------
You can set a MAC address of a Virtual Function (VF), a default VLAN and the
rate limit using the IProute2 tool. Download the latest version of the
IProute2 tool from Sourceforge if your version does not have all the features
you require.
Credit Based Shaper (Qav Mode)
------------------------------
When enabling the CBS qdisc in the hardware offload mode, traffic shaping using
the CBS (described in the IEEE 802.1Q-2018 Section 8.6.8.2 and discussed in the
Annex L) algorithm will run in the i210 controller, so it's more accurate and
uses less CPU.
When using offloaded CBS, and the traffic rate obeys the configured rate
(doesn't go above it), CBS should have little to no effect in the latency.
The offloaded version of the algorithm has some limits, caused by how the idle
slope is expressed in the adapter's registers. It can only represent idle slopes
in 16.38431 kbps units, which means that if a idle slope of 2576kbps is
requested, the controller will be configured to use a idle slope of ~2589 kbps,
because the driver rounds the value up. For more details, see the comments on
:c:func:`igb_config_tx_modes()`.
NOTE: This feature is exclusive to i210 models.
Support
=======
For general information, go to the Intel support website at:
https://www.intel.com/support/
If an issue is identified with the released source code on a supported kernel
with a supported adapter, email the specific information related to the issue
to intel-wired-lan@lists.osuosl.org.
linux-7.2.3/Documentation/networking/device_drivers/ethernet/intel/igbvf.rst
+60
View File
@@ -0,0 +1,60 @@
.. SPDX-License-Identifier: GPL-2.0+
===========================================================
Linux Base Virtual Function Driver for Intel(R) 1G Ethernet
===========================================================
Intel Gigabit Virtual Function Linux driver.
Copyright(c) 1999-2018 Intel Corporation.
Contents
========
- Identifying Your Adapter
- Additional Configurations
- Support
This driver supports Intel 82576-based virtual function devices-based virtual
function devices that can only be activated on kernels that support SR-IOV.
SR-IOV requires the correct platform and OS support.
The guest OS loading this driver must support MSI-X interrupts.
For questions related to hardware requirements, refer to the documentation
supplied with your Intel adapter. All hardware requirements listed apply to use
with Linux.
Driver information can be obtained using ethtool, lspci, and ifconfig.
Instructions on updating ethtool can be found in the section Additional
Configurations later in this document.
NOTE: There is a limit of a total of 32 shared VLANs to 1 or more VFs.
Identifying Your Adapter
========================
For information on how to identify your adapter, and for the latest Intel
network drivers, refer to the Intel Support website:
https://www.intel.com/support
Additional Features and Configurations
======================================
ethtool
-------
The driver utilizes the ethtool interface for driver configuration and
diagnostics, as well as displaying statistical information. The latest ethtool
version is required for this functionality. Download it at:
https://www.kernel.org/pub/software/network/ethtool/
Support
=======
For general information, go to the Intel support website at:
https://www.intel.com/support/
If an issue is identified with the released source code on a supported kernel
with a supported adapter, email the specific information related to the issue
to intel-wired-lan@lists.osuosl.org.
linux-7.2.3/Documentation/networking/device_drivers/ethernet/intel/ixgbe.rst
+552
View File
@@ -0,0 +1,552 @@
.. SPDX-License-Identifier: GPL-2.0+
===========================================================================
Linux Base Driver for the Intel(R) Ethernet 10 Gigabit PCI Express Adapters
===========================================================================
Intel 10 Gigabit Linux driver.
Copyright(c) 1999-2018 Intel Corporation.
Contents
========
- Identifying Your Adapter
- Command Line Parameters
- Additional Configurations
- Known Issues
- Support
Identifying Your Adapter
========================
The driver is compatible with devices based on the following:
* Intel(R) Ethernet Controller 82598
* Intel(R) Ethernet Controller 82599
* Intel(R) Ethernet Controller X520
* Intel(R) Ethernet Controller X540
* Intel(R) Ethernet Controller x550
* Intel(R) Ethernet Controller X552
* Intel(R) Ethernet Controller X553
For information on how to identify your adapter, and for the latest Intel
network drivers, refer to the Intel Support website:
https://www.intel.com/support
SFP+ Devices with Pluggable Optics
----------------------------------
82599-BASED ADAPTERS
~~~~~~~~~~~~~~~~~~~~
NOTES:
- If your 82599-based Intel(R) Network Adapter came with Intel optics or is an
Intel(R) Ethernet Server Adapter X520-2, then it only supports Intel optics
and/or the direct attach cables listed below.
- When 82599-based SFP+ devices are connected back to back, they should be set
to the same Speed setting via ethtool. Results may vary if you mix speed
settings.
+---------------+---------------------------------------+------------------+
| Supplier | Type | Part Numbers |
+===============+=======================================+==================+
| SR Modules |
+---------------+---------------------------------------+------------------+
| Intel | DUAL RATE 1G/10G SFP+ SR (bailed) | FTLX8571D3BCV-IT |
+---------------+---------------------------------------+------------------+
| Intel | DUAL RATE 1G/10G SFP+ SR (bailed) | AFBR-703SDZ-IN2 |
+---------------+---------------------------------------+------------------+
| Intel | DUAL RATE 1G/10G SFP+ SR (bailed) | AFBR-703SDDZ-IN1 |
+---------------+---------------------------------------+------------------+
| LR Modules |
+---------------+---------------------------------------+------------------+
| Intel | DUAL RATE 1G/10G SFP+ LR (bailed) | FTLX1471D3BCV-IT |
+---------------+---------------------------------------+------------------+
| Intel | DUAL RATE 1G/10G SFP+ LR (bailed) | AFCT-701SDZ-IN2 |
+---------------+---------------------------------------+------------------+
| Intel | DUAL RATE 1G/10G SFP+ LR (bailed) | AFCT-701SDDZ-IN1 |
+---------------+---------------------------------------+------------------+
The following is a list of 3rd party SFP+ modules that have received some
testing. Not all modules are applicable to all devices.
+---------------+---------------------------------------+------------------+
| Supplier | Type | Part Numbers |
+===============+=======================================+==================+
| Finisar | SFP+ SR bailed, 10g single rate | FTLX8571D3BCL |
+---------------+---------------------------------------+------------------+
| Avago | SFP+ SR bailed, 10g single rate | AFBR-700SDZ |
+---------------+---------------------------------------+------------------+
| Finisar | SFP+ LR bailed, 10g single rate | FTLX1471D3BCL |
+---------------+---------------------------------------+------------------+
| Finisar | DUAL RATE 1G/10G SFP+ SR (No Bail) | FTLX8571D3QCV-IT |
+---------------+---------------------------------------+------------------+
| Avago | DUAL RATE 1G/10G SFP+ SR (No Bail) | AFBR-703SDZ-IN1 |
+---------------+---------------------------------------+------------------+
| Finisar | DUAL RATE 1G/10G SFP+ LR (No Bail) | FTLX1471D3QCV-IT |
+---------------+---------------------------------------+------------------+
| Avago | DUAL RATE 1G/10G SFP+ LR (No Bail) | AFCT-701SDZ-IN1 |
+---------------+---------------------------------------+------------------+
| Finisar | 1000BASE-T SFP | FCLF8522P2BTL |
+---------------+---------------------------------------+------------------+
| Avago | 1000BASE-T | ABCU-5710RZ |
+---------------+---------------------------------------+------------------+
| HP | 1000BASE-SX SFP | 453153-001 |
+---------------+---------------------------------------+------------------+
82599-based adapters support all passive and active limiting direct attach
cables that comply with SFF-8431 v4.1 and SFF-8472 v10.4 specifications.
Laser turns off for SFP+ when ifconfig ethX down
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"ifconfig ethX down" turns off the laser for 82599-based SFP+ fiber adapters.
"ifconfig ethX up" turns on the laser.
Alternatively, you can use "ip link set [down/up] dev ethX" to turn the
laser off and on.
82599-based QSFP+ Adapters
~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTES:
- If your 82599-based Intel(R) Network Adapter came with Intel optics, it only
supports Intel optics.
- 82599-based QSFP+ adapters only support 4x10 Gbps connections. 1x40 Gbps
connections are not supported. QSFP+ link partners must be configured for
4x10 Gbps.
- 82599-based QSFP+ adapters do not support automatic link speed detection.
The link speed must be configured to either 10 Gbps or 1 Gbps to match the link
partners speed capabilities. Incorrect speed configurations will result in
failure to link.
- Intel(R) Ethernet Converged Network Adapter X520-Q1 only supports the optics
and direct attach cables listed below.
+---------------+---------------------------------------+------------------+
| Supplier | Type | Part Numbers |
+===============+=======================================+==================+
| Intel | DUAL RATE 1G/10G QSFP+ SRL (bailed) | E10GQSFPSR |
+---------------+---------------------------------------+------------------+
82599-based QSFP+ adapters support all passive and active limiting QSFP+
direct attach cables that comply with SFF-8436 v4.1 specifications.
82598-BASED ADAPTERS
~~~~~~~~~~~~~~~~~~~~
NOTES:
- Intel(r) Ethernet Network Adapters that support removable optical modules
only support their original module type (for example, the Intel(R) 10 Gigabit
SR Dual Port Express Module only supports SR optical modules). If you plug in
a different type of module, the driver will not load.
- Hot Swapping/hot plugging optical modules is not supported.
- Only single speed, 10 gigabit modules are supported.
- LAN on Motherboard (LOMs) may support DA, SR, or LR modules. Other module
types are not supported. Please see your system documentation for details.
The following is a list of SFP+ modules and direct attach cables that have
received some testing. Not all modules are applicable to all devices.
+---------------+---------------------------------------+------------------+
| Supplier | Type | Part Numbers |
+===============+=======================================+==================+
| Finisar | SFP+ SR bailed, 10g single rate | FTLX8571D3BCL |
+---------------+---------------------------------------+------------------+
| Avago | SFP+ SR bailed, 10g single rate | AFBR-700SDZ |
+---------------+---------------------------------------+------------------+
| Finisar | SFP+ LR bailed, 10g single rate | FTLX1471D3BCL |
+---------------+---------------------------------------+------------------+
82598-based adapters support all passive direct attach cables that comply with
SFF-8431 v4.1 and SFF-8472 v10.4 specifications. Active direct attach cables
are not supported.
Third party optic modules and cables referred to above are listed only for the
purpose of highlighting third party specifications and potential
compatibility, and are not recommendations or endorsements or sponsorship of
any third party's product by Intel. Intel is not endorsing or promoting
products made by any third party and the third party reference is provided
only to share information regarding certain optic modules and cables with the
above specifications. There may be other manufacturers or suppliers, producing
or supplying optic modules and cables with similar or matching descriptions.
Customers must use their own discretion and diligence to purchase optic
modules and cables from any third party of their choice. Customers are solely
responsible for assessing the suitability of the product and/or devices and
for the selection of the vendor for purchasing any product. THE OPTIC MODULES
AND CABLES REFERRED TO ABOVE ARE NOT WARRANTED OR SUPPORTED BY INTEL. INTEL
ASSUMES NO LIABILITY WHATSOEVER, AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED
WARRANTY, RELATING TO SALE AND/OR USE OF SUCH THIRD PARTY PRODUCTS OR
SELECTION OF VENDOR BY CUSTOMERS.
Command Line Parameters
=======================
max_vfs
-------
:Valid Range: 1-63
This parameter adds support for SR-IOV. It causes the driver to spawn up to
max_vfs worth of virtual functions.
If the value is greater than 0 it will also force the VMDq parameter to be 1 or
more.
NOTE: This parameter is only used on kernel 3.7.x and below. On kernel 3.8.x
and above, use sysfs to enable VFs. Also, for Red Hat distributions, this
parameter is only used on version 6.6 and older. For version 6.7 and newer, use
sysfs. For example::
#echo $num_vf_enabled > /sys/class/net/$dev/device/sriov_numvfs // enable VFs
#echo 0 > /sys/class/net/$dev/device/sriov_numvfs //disable VFs
The parameters for the driver are referenced by position. Thus, if you have a
dual port adapter, or more than one adapter in your system, and want N virtual
functions per port, you must specify a number for each port with each parameter
separated by a comma. For example::
modprobe ixgbe max_vfs=4
This will spawn 4 VFs on the first port.
::
modprobe ixgbe max_vfs=2,4
This will spawn 2 VFs on the first port and 4 VFs on the second port.
NOTE: Caution must be used in loading the driver with these parameters.
Depending on your system configuration, number of slots, etc., it is impossible
to predict in all cases where the positions would be on the command line.
NOTE: Neither the device nor the driver control how VFs are mapped into config
space. Bus layout will vary by operating system. On operating systems that
support it, you can check sysfs to find the mapping.
NOTE: When either SR-IOV mode or VMDq mode is enabled, hardware VLAN filtering
and VLAN tag stripping/insertion will remain enabled. Please remove the old
VLAN filter before the new VLAN filter is added. For example,
::
ip link set eth0 vf 0 vlan 100 // set VLAN 100 for VF 0
ip link set eth0 vf 0 vlan 0 // Delete VLAN 100
ip link set eth0 vf 0 vlan 200 // set a new VLAN 200 for VF 0
With kernel 3.6, the driver supports the simultaneous usage of max_vfs and DCB
features, subject to the constraints described below. Prior to kernel 3.6, the
driver did not support the simultaneous operation of max_vfs greater than 0 and
the DCB features (multiple traffic classes utilizing Priority Flow Control and
Extended Transmission Selection).
When DCB is enabled, network traffic is transmitted and received through
multiple traffic classes (packet buffers in the NIC). The traffic is associated
with a specific class based on priority, which has a value of 0 through 7 used
in the VLAN tag. When SR-IOV is not enabled, each traffic class is associated
with a set of receive/transmit descriptor queue pairs. The number of queue
pairs for a given traffic class depends on the hardware configuration. When
SR-IOV is enabled, the descriptor queue pairs are grouped into pools. The
Physical Function (PF) and each Virtual Function (VF) is allocated a pool of
receive/transmit descriptor queue pairs. When multiple traffic classes are
configured (for example, DCB is enabled), each pool contains a queue pair from
each traffic class. When a single traffic class is configured in the hardware,
the pools contain multiple queue pairs from the single traffic class.
The number of VFs that can be allocated depends on the number of traffic
classes that can be enabled. The configurable number of traffic classes for
each enabled VF is as follows:
0 - 15 VFs = Up to 8 traffic classes, depending on device support
16 - 31 VFs = Up to 4 traffic classes
32 - 63 VFs = 1 traffic class
When VFs are configured, the PF is allocated one pool as well. The PF supports
the DCB features with the constraint that each traffic class will only use a
single queue pair. When zero VFs are configured, the PF can support multiple
queue pairs per traffic class.
allow_unsupported_sfp
---------------------
:Valid Range: 0,1
:Default Value: 0 (disabled)
This parameter allows unsupported and untested SFP+ modules on 82599-based
adapters, as long as the type of module is known to the driver.
debug
-----
:Valid Range: 0-16 (0=none,...,16=all)
:Default Value: 0
This parameter adjusts the level of debug messages displayed in the system
logs.
Additional Features and Configurations
======================================
Flow Control
------------
Ethernet Flow Control (IEEE 802.3x) can be configured with ethtool to enable
receiving and transmitting pause frames for ixgbe. When transmit is enabled,
pause frames are generated when the receive packet buffer crosses a predefined
threshold. When receive is enabled, the transmit unit will halt for the time
delay specified when a pause frame is received.
NOTE: You must have a flow control capable link partner.
Flow Control is enabled by default.
Use ethtool to change the flow control settings. To enable or disable Rx or
Tx Flow Control::
ethtool -A eth? rx <on|off> tx <on|off>
Note: This command only enables or disables Flow Control if auto-negotiation is
disabled. If auto-negotiation is enabled, this command changes the parameters
used for auto-negotiation with the link partner.
To enable or disable auto-negotiation::
ethtool -s eth? autoneg <on|off>
Note: Flow Control auto-negotiation is part of link auto-negotiation. Depending
on your device, you may not be able to change the auto-negotiation setting.
NOTE: For 82598 backplane cards entering 1 gigabit mode, flow control default
behavior is changed to off. Flow control in 1 gigabit mode on these devices can
lead to transmit hangs.
Intel(R) Ethernet Flow Director
-------------------------------
The Intel Ethernet Flow Director performs the following tasks:
- Directs receive packets according to their flows to different queues.
- Enables tight control on routing a flow in the platform.
- Matches flows and CPU cores for flow affinity.
- Supports multiple parameters for flexible flow classification and load
balancing (in SFP mode only).
NOTE: Intel Ethernet Flow Director masking works in the opposite manner from
subnet masking. In the following command::
#ethtool -N eth11 flow-type ip4 src-ip 172.4.1.2 m 255.0.0.0 dst-ip \
172.21.1.1 m 255.128.0.0 action 31
The src-ip value that is written to the filter will be 0.4.1.2, not 172.0.0.0
as might be expected. Similarly, the dst-ip value written to the filter will be
0.21.1.1, not 172.0.0.0.
To enable or disable the Intel Ethernet Flow Director::
# ethtool -K ethX ntuple <on|off>
When disabling ntuple filters, all the user programmed filters are flushed from
the driver cache and hardware. All needed filters must be re-added when ntuple
is re-enabled.
To add a filter that directs packet to queue 2, use -U or -N switch::
# ethtool -N ethX flow-type tcp4 src-ip 192.168.10.1 dst-ip \
192.168.10.2 src-port 2000 dst-port 2001 action 2 [loc 1]
To see the list of filters currently present::
# ethtool <-u|-n> ethX
Sideband Perfect Filters
------------------------
Sideband Perfect Filters are used to direct traffic that matches specified
characteristics. They are enabled through ethtool's ntuple interface. To add a
new filter use the following command::
ethtool -U <device> flow-type <type> src-ip <ip> dst-ip <ip> src-port <port> \
dst-port <port> action <queue>
Where:
<device> - the ethernet device to program
<type> - can be ip4, tcp4, udp4, or sctp4
<ip> - the IP address to match on
<port> - the port number to match on
<queue> - the queue to direct traffic towards (-1 discards the matched traffic)
Use the following command to delete a filter::
ethtool -U <device> delete <N>
Where <N> is the filter id displayed when printing all the active filters, and
may also have been specified using "loc <N>" when adding the filter.
The following example matches TCP traffic sent from 192.168.0.1, port 5300,
directed to 192.168.0.5, port 80, and sends it to queue 7::
ethtool -U enp130s0 flow-type tcp4 src-ip 192.168.0.1 dst-ip 192.168.0.5 \
src-port 5300 dst-port 80 action 7
For each flow-type, the programmed filters must all have the same matching
input set. For example, issuing the following two commands is acceptable::
ethtool -U enp130s0 flow-type ip4 src-ip 192.168.0.1 src-port 5300 action 7
ethtool -U enp130s0 flow-type ip4 src-ip 192.168.0.5 src-port 55 action 10
Issuing the next two commands, however, is not acceptable, since the first
specifies src-ip and the second specifies dst-ip::
ethtool -U enp130s0 flow-type ip4 src-ip 192.168.0.1 src-port 5300 action 7
ethtool -U enp130s0 flow-type ip4 dst-ip 192.168.0.5 src-port 55 action 10
The second command will fail with an error. You may program multiple filters
with the same fields, using different values, but, on one device, you may not
program two TCP4 filters with different matching fields.
Matching on a sub-portion of a field is not supported by the ixgbe driver, thus
partial mask fields are not supported.
To create filters that direct traffic to a specific Virtual Function, use the
"user-def" parameter. Specify the user-def as a 64 bit value, where the lower 32
bits represents the queue number, while the next 8 bits represent which VF.
Note that 0 is the PF, so the VF identifier is offset by 1. For example::
... user-def 0x800000002 ...
specifies to direct traffic to Virtual Function 7 (8 minus 1) into queue 2 of
that VF.
Note that these filters will not break internal routing rules, and will not
route traffic that otherwise would not have been sent to the specified Virtual
Function.
Jumbo Frames
------------
Jumbo Frames support is enabled by changing the Maximum Transmission Unit (MTU)
to a value larger than the default value of 1500.
Use the ifconfig command to increase the MTU size. For example, enter the
following where <x> is the interface number::
ifconfig eth<x> mtu 9000 up
Alternatively, you can use the ip command as follows::
ip link set mtu 9000 dev eth<x>
ip link set up dev eth<x>
This setting is not saved across reboots. The setting change can be made
permanent by adding 'MTU=9000' to the file::
/etc/sysconfig/network-scripts/ifcfg-eth<x> // for RHEL
/etc/sysconfig/network/<config_file> // for SLES
NOTE: The maximum MTU setting for Jumbo Frames is 9710. This value coincides
with the maximum Jumbo Frames size of 9728 bytes.
NOTE: This driver will attempt to use multiple page sized buffers to receive
each jumbo packet. This should help to avoid buffer starvation issues when
allocating receive packets.
NOTE: For 82599-based network connections, if you are enabling jumbo frames in
a virtual function (VF), jumbo frames must first be enabled in the physical
function (PF). The VF MTU setting cannot be larger than the PF MTU.
NBASE-T Support
---------------
The ixgbe driver supports NBASE-T on some devices. However, the advertisement
of NBASE-T speeds is suppressed by default, to accommodate broken network
switches which cannot cope with advertised NBASE-T speeds. Use the ethtool
command to enable advertising NBASE-T speeds on devices which support it::
ethtool -s eth? advertise 0x1800000001028
On Linux systems with INTERFACES(5), this can be specified as a pre-up command
in /etc/network/interfaces so that the interface is always brought up with
NBASE-T support, e.g.::
iface eth? inet dhcp
pre-up ethtool -s eth? advertise 0x1800000001028 || true
Generic Receive Offload, aka GRO
--------------------------------
The driver supports the in-kernel software implementation of GRO. GRO has
shown that by coalescing Rx traffic into larger chunks of data, CPU
utilization can be significantly reduced when under large Rx load. GRO is an
evolution of the previously-used LRO interface. GRO is able to coalesce
other protocols besides TCP. It's also safe to use with configurations that
are problematic for LRO, namely bridging and iSCSI.
Data Center Bridging (DCB)
--------------------------
NOTE:
The kernel assumes that TC0 is available, and will disable Priority Flow
Control (PFC) on the device if TC0 is not available. To fix this, ensure TC0 is
enabled when setting up DCB on your switch.
DCB is a configuration Quality of Service implementation in hardware. It uses
the VLAN priority tag (802.1p) to filter traffic. That means that there are 8
different priorities that traffic can be filtered into. It also enables
priority flow control (802.1Qbb) which can limit or eliminate the number of
dropped packets during network stress. Bandwidth can be allocated to each of
these priorities, which is enforced at the hardware level (802.1Qaz).
Adapter firmware implements LLDP and DCBX protocol agents as per 802.1AB and
802.1Qaz respectively. The firmware based DCBX agent runs in willing mode only
and can accept settings from a DCBX capable peer. Software configuration of
DCBX parameters via dcbtool/lldptool are not supported.
The ixgbe driver implements the DCB netlink interface layer to allow user-space
to communicate with the driver and query DCB configuration for the port.
ethtool
-------
The driver utilizes the ethtool interface for driver configuration and
diagnostics, as well as displaying statistical information. The latest ethtool
version is required for this functionality. Download it at:
https://www.kernel.org/pub/software/network/ethtool/
FCoE
----
The ixgbe driver supports Fiber Channel over Ethernet (FCoE) and Data Center
Bridging (DCB). This code has no default effect on the regular driver
operation. Configuring DCB and FCoE is outside the scope of this README. Refer
to http://www.open-fcoe.org/ for FCoE project information and contact
ixgbe-eedc@lists.sourceforge.net for DCB information.
MAC and VLAN anti-spoofing feature
----------------------------------
When a malicious driver attempts to send a spoofed packet, it is dropped by the
hardware and not transmitted.
An interrupt is sent to the PF driver notifying it of the spoof attempt. When a
spoofed packet is detected, the PF driver will send the following message to
the system log (displayed by the "dmesg" command)::
ixgbe ethX: ixgbe_spoof_check: n spoofed packets detected
where "x" is the PF interface number; and "n" is number of spoofed packets.
NOTE: This feature can be disabled for a specific Virtual Function (VF)::
ip link set <pf dev> vf <vf id> spoofchk {off|on}
IPsec Offload
-------------
The ixgbe driver supports IPsec Hardware Offload. When creating Security
Associations with "ip xfrm ..." the 'offload' tag option can be used to
register the IPsec SA with the driver in order to get higher throughput in
the secure communications.
The offload is also supported for ixgbe's VFs, but the VF must be set as
'trusted' and the support must be enabled with::
ethtool --set-priv-flags eth<x> vf-ipsec on
ip link set eth<x> vf <y> trust on
Known Issues/Troubleshooting
============================
Enabling SR-IOV in a 64-bit Microsoft Windows Server 2012/R2 guest OS
---------------------------------------------------------------------
Linux KVM Hypervisor/VMM supports direct assignment of a PCIe device to a VM.
This includes traditional PCIe devices, as well as SR-IOV-capable devices based
on the Intel Ethernet Controller XL710.
Support
=======
For general information, go to the Intel support website at:
https://www.intel.com/support/
If an issue is identified with the released source code on a supported kernel
with a supported adapter, email the specific information related to the issue
to intel-wired-lan@lists.osuosl.org.
linux-7.2.3/Documentation/networking/device_drivers/ethernet/intel/ixgbevf.rst
+62
View File
@@ -0,0 +1,62 @@
.. SPDX-License-Identifier: GPL-2.0+
============================================================
Linux Base Virtual Function Driver for Intel(R) 10G Ethernet
============================================================
Intel 10 Gigabit Virtual Function Linux driver.
Copyright(c) 1999-2018 Intel Corporation.
Contents
========
- Identifying Your Adapter
- Known Issues
- Support
This driver supports 82599, X540, X550, and X552-based virtual function devices
that can only be activated on kernels that support SR-IOV.
For questions related to hardware requirements, refer to the documentation
supplied with your Intel adapter. All hardware requirements listed apply to use
with Linux.
Identifying Your Adapter
========================
The driver is compatible with devices based on the following:
* Intel(R) Ethernet Controller 82598
* Intel(R) Ethernet Controller 82599
* Intel(R) Ethernet Controller X520
* Intel(R) Ethernet Controller X540
* Intel(R) Ethernet Controller x550
* Intel(R) Ethernet Controller X552
* Intel(R) Ethernet Controller X553
For information on how to identify your adapter, and for the latest Intel
network drivers, refer to the Intel Support website:
https://www.intel.com/support
Known Issues/Troubleshooting
============================
SR-IOV requires the correct platform and OS support.
The guest OS loading this driver must support MSI-X interrupts.
This driver is only supported as a loadable module at this time. Intel is not
supplying patches against the kernel source to allow for static linking of the
drivers.
VLANs: There is a limit of a total of 64 shared VLANs to 1 or more VFs.
Support
=======
For general information, go to the Intel support website at:
https://www.intel.com/support/
If an issue is identified with the released source code on a supported kernel
with a supported adapter, email the specific information related to the issue
to intel-wired-lan@lists.osuosl.org.
linux-7.2.3/Documentation/networking/device_drivers/ethernet/marvell/octeon_ep.rst
+41
View File
@@ -0,0 +1,41 @@
.. SPDX-License-Identifier: GPL-2.0+
====================================================================
Linux kernel networking driver for Marvell's Octeon PCI Endpoint NIC
====================================================================
Network driver for Marvell's Octeon PCI EndPoint NIC.
Copyright (c) 2020 Marvell International Ltd.
Contents
========
- `Overview`_
- `Supported Devices`_
- `Interface Control`_
Overview
========
This driver implements networking functionality of Marvell's Octeon PCI
EndPoint NIC.
Supported Devices
=================
Currently, this driver support following devices:
* Network controller: Cavium, Inc. Device b100
* Network controller: Cavium, Inc. Device b200
* Network controller: Cavium, Inc. Device b400
* Network controller: Cavium, Inc. Device b900
* Network controller: Cavium, Inc. Device ba00
* Network controller: Cavium, Inc. Device bc00
* Network controller: Cavium, Inc. Device bd00
Interface Control
=================
Network Interface control like changing mtu, link speed, link down/up are
done by writing command to mailbox command queue, a mailbox interface
implemented through a reserved region in BAR4.
This driver writes the commands into the mailbox and the firmware on the
Octeon device processes them. The firmware also sends unsolicited notifications
to driver for events suchs as link change, through notification queue
implemented as part of mailbox interface.
linux-7.2.3/Documentation/networking/device_drivers/ethernet/marvell/octeon_ep_vf.rst
+24
View File
@@ -0,0 +1,24 @@
.. SPDX-License-Identifier: GPL-2.0+
=======================================================================
Linux kernel networking driver for Marvell's Octeon PCI Endpoint NIC VF
=======================================================================
Network driver for Marvell's Octeon PCI EndPoint NIC VF.
Copyright (c) 2020 Marvell International Ltd.
Overview
========
This driver implements networking functionality of Marvell's Octeon PCI
EndPoint NIC VF.
Supported Devices
=================
Currently, this driver support following devices:
* Network controller: Cavium, Inc. Device b203
* Network controller: Cavium, Inc. Device b403
* Network controller: Cavium, Inc. Device b103
* Network controller: Cavium, Inc. Device b903
* Network controller: Cavium, Inc. Device ba03
* Network controller: Cavium, Inc. Device bc03
* Network controller: Cavium, Inc. Device bd03
linux-7.2.3/Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst
+433
View File
@@ -0,0 +1,433 @@
.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
====================================
Marvell OcteonTx2 RVU Kernel Drivers
====================================
Copyright (c) 2020 Marvell International Ltd.
Contents
========
- `Overview`_
- `Drivers`_
- `Basic packet flow`_
- `Devlink health reporters`_
- `Quality of service`_
- `RVU representors`_
Overview
========
Resource virtualization unit (RVU) on Marvell's OcteonTX2 SOC maps HW
resources from the network, crypto and other functional blocks into
PCI-compatible physical and virtual functions. Each functional block
again has multiple local functions (LFs) for provisioning to PCI devices.
RVU supports multiple PCIe SRIOV physical functions (PFs) and virtual
functions (VFs). PF0 is called the administrative / admin function (AF)
and has privileges to provision RVU functional block's LFs to each of the
PF/VF.
RVU managed networking functional blocks
- Network pool or buffer allocator (NPA)
- Network interface controller (NIX)
- Network parser CAM (NPC)
- Schedule/Synchronize/Order unit (SSO)
- Loopback interface (LBK)
RVU managed non-networking functional blocks
- Crypto accelerator (CPT)
- Scheduled timers unit (TIM)
- Schedule/Synchronize/Order unit (SSO)
Used for both networking and non networking usecases
Resource provisioning examples
- A PF/VF with NIX-LF & NPA-LF resources works as a pure network device
- A PF/VF with CPT-LF resource works as a pure crypto offload device.
RVU functional blocks are highly configurable as per software requirements.
Firmware setups following stuff before kernel boots
- Enables required number of RVU PFs based on number of physical links.
- Number of VFs per PF are either static or configurable at compile time.
Based on config, firmware assigns VFs to each of the PFs.
- Also assigns MSIX vectors to each of PF and VFs.
- These are not changed after kernel boot.
Drivers
=======
Linux kernel will have multiple drivers registering to different PF and VFs
of RVU. Wrt networking there will be 3 flavours of drivers.
Admin Function driver
---------------------
As mentioned above RVU PF0 is called the admin function (AF), this driver
supports resource provisioning and configuration of functional blocks.
Doesn't handle any I/O. It sets up few basic stuff but most of the
functionality is achieved via configuration requests from PFs and VFs.
PF/VFs communicates with AF via a shared memory region (mailbox). Upon
receiving requests AF does resource provisioning and other HW configuration.
AF is always attached to host kernel, but PFs and their VFs may be used by host
kernel itself, or attached to VMs or to userspace applications like
DPDK etc. So AF has to handle provisioning/configuration requests sent
by any device from any domain.
AF driver also interacts with underlying firmware to
- Manage physical ethernet links ie CGX LMACs.
- Retrieve information like speed, duplex, autoneg etc
- Retrieve PHY EEPROM and stats.
- Configure FEC, PAM modes
- etc
From pure networking side AF driver supports following functionality.
- Map a physical link to a RVU PF to which a netdev is registered.
- Attach NIX and NPA block LFs to RVU PF/VF which provide buffer pools, RQs, SQs
for regular networking functionality.
- Flow control (pause frames) enable/disable/config.
- HW PTP timestamping related config.
- NPC parser profile config, basically how to parse pkt and what info to extract.
- NPC extract profile config, what to extract from the pkt to match data in MCAM entries.
- Manage NPC MCAM entries, upon request can frame and install requested packet forwarding rules.
- Defines receive side scaling (RSS) algorithms.
- Defines segmentation offload algorithms (eg TSO)
- VLAN stripping, capture and insertion config.
- SSO and TIM blocks config which provide packet scheduling support.
- Debugfs support, to check current resource provising, current status of
NPA pools, NIX RQ, SQ and CQs, various stats etc which helps in debugging issues.
- And many more.
Physical Function driver
------------------------
This RVU PF handles IO, is mapped to a physical ethernet link and this
driver registers a netdev. This supports SR-IOV. As said above this driver
communicates with AF with a mailbox. To retrieve information from physical
links this driver talks to AF and AF gets that info from firmware and responds
back ie cannot talk to firmware directly.
Supports ethtool for configuring links, RSS, queue count, queue size,
flow control, ntuple filters, dump PHY EEPROM, config FEC etc.
Virtual Function driver
-----------------------
There are two types VFs, VFs that share the physical link with their parent
SR-IOV PF and the VFs which work in pairs using internal HW loopback channels (LBK).
Type1:
- These VFs and their parent PF share a physical link and used for outside communication.
- VFs cannot communicate with AF directly, they send mbox message to PF and PF
forwards that to AF. AF after processing, responds back to PF and PF forwards
the reply to VF.
- From functionality point of view there is no difference between PF and VF as same type
HW resources are attached to both. But user would be able to configure few stuff only
from PF as PF is treated as owner/admin of the link.
Type2:
- RVU PF0 ie admin function creates these VFs and maps them to loopback block's channels.
- A set of two VFs (VF0 & VF1, VF2 & VF3 .. so on) works as a pair ie pkts sent out of
VF0 will be received by VF1 and vice versa.
- These VFs can be used by applications or virtual machines to communicate between them
without sending traffic outside. There is no switch present in HW, hence the support
for loopback VFs.
- These communicate directly with AF (PF0) via mbox.
Except for the IO channels or links used for packet reception and transmission there is
no other difference between these VF types. AF driver takes care of IO channel mapping,
hence same VF driver works for both types of devices.
Basic packet flow
=================
Ingress
-------
1. CGX LMAC receives packet.
2. Forwards the packet to the NIX block.
3. Then submitted to NPC block for parsing and then MCAM lookup to get the destination RVU device.
4. NIX LF attached to the destination RVU device allocates a buffer from RQ mapped buffer pool of NPA block LF.
5. RQ may be selected by RSS or by configuring MCAM rule with a RQ number.
6. Packet is DMA'ed and driver is notified.
Egress
------
1. Driver prepares a send descriptor and submits to SQ for transmission.
2. The SQ is already configured (by AF) to transmit on a specific link/channel.
3. The SQ descriptor ring is maintained in buffers allocated from SQ mapped pool of NPA block LF.
4. NIX block transmits the pkt on the designated channel.
5. NPC MCAM entries can be installed to divert pkt onto a different channel.
Devlink health reporters
========================
NPA Reporters
-------------
The NPA reporters are responsible for reporting and recovering the following group of errors:
1. GENERAL events
- Error due to operation of unmapped PF.
- Error due to disabled alloc/free for other HW blocks (NIX, SSO, TIM, DPI and AURA).
2. ERROR events
- Fault due to NPA_AQ_INST_S read or NPA_AQ_RES_S write.
- AQ Doorbell Error.
3. RAS events
- RAS Error Reporting for NPA_AQ_INST_S/NPA_AQ_RES_S.
4. RVU events
- Error due to unmapped slot.
Sample Output::
~# devlink health
pci/0002:01:00.0:
reporter hw_npa_intr
state healthy error 2872 recover 2872 last_dump_date 2020-12-10 last_dump_time 09:39:09 grace_period 0 auto_recover true auto_dump true
reporter hw_npa_gen
state healthy error 2872 recover 2872 last_dump_date 2020-12-11 last_dump_time 04:43:04 grace_period 0 auto_recover true auto_dump true
reporter hw_npa_err
state healthy error 2871 recover 2871 last_dump_date 2020-12-10 last_dump_time 09:39:17 grace_period 0 auto_recover true auto_dump true
reporter hw_npa_ras
state healthy error 0 recover 0 last_dump_date 2020-12-10 last_dump_time 09:32:40 grace_period 0 auto_recover true auto_dump true
Each reporter dumps the
- Error Type
- Error Register value
- Reason in words
For example::
~# devlink health dump show pci/0002:01:00.0 reporter hw_npa_gen
NPA_AF_GENERAL:
NPA General Interrupt Reg : 1
NIX0: free disabled RX
~# devlink health dump show pci/0002:01:00.0 reporter hw_npa_intr
NPA_AF_RVU:
NPA RVU Interrupt Reg : 1
Unmap Slot Error
~# devlink health dump show pci/0002:01:00.0 reporter hw_npa_err
NPA_AF_ERR:
NPA Error Interrupt Reg : 4096
AQ Doorbell Error
NIX Reporters
-------------
The NIX reporters are responsible for reporting and recovering the following group of errors:
1. GENERAL events
- Receive mirror/multicast packet drop due to insufficient buffer.
- SMQ Flush operation.
2. ERROR events
- Memory Fault due to WQE read/write from multicast/mirror buffer.
- Receive multicast/mirror replication list error.
- Receive packet on an unmapped PF.
- Fault due to NIX_AQ_INST_S read or NIX_AQ_RES_S write.
- AQ Doorbell Error.
3. RAS events
- RAS Error Reporting for NIX Receive Multicast/Mirror Entry Structure.
- RAS Error Reporting for WQE/Packet Data read from Multicast/Mirror Buffer..
- RAS Error Reporting for NIX_AQ_INST_S/NIX_AQ_RES_S.
4. RVU events
- Error due to unmapped slot.
Sample Output::
~# ./devlink health
pci/0002:01:00.0:
reporter hw_npa_intr
state healthy error 0 recover 0 grace_period 0 auto_recover true auto_dump true
reporter hw_npa_gen
state healthy error 0 recover 0 grace_period 0 auto_recover true auto_dump true
reporter hw_npa_err
state healthy error 0 recover 0 grace_period 0 auto_recover true auto_dump true
reporter hw_npa_ras
state healthy error 0 recover 0 grace_period 0 auto_recover true auto_dump true
reporter hw_nix_intr
state healthy error 1121 recover 1121 last_dump_date 2021-01-19 last_dump_time 05:42:26 grace_period 0 auto_recover true auto_dump true
reporter hw_nix_gen
state healthy error 949 recover 949 last_dump_date 2021-01-19 last_dump_time 05:42:43 grace_period 0 auto_recover true auto_dump true
reporter hw_nix_err
state healthy error 1147 recover 1147 last_dump_date 2021-01-19 last_dump_time 05:42:59 grace_period 0 auto_recover true auto_dump true
reporter hw_nix_ras
state healthy error 409 recover 409 last_dump_date 2021-01-19 last_dump_time 05:43:16 grace_period 0 auto_recover true auto_dump true
Each reporter dumps the
- Error Type
- Error Register value
- Reason in words
For example::
~# devlink health dump show pci/0002:01:00.0 reporter hw_nix_intr
NIX_AF_RVU:
NIX RVU Interrupt Reg : 1
Unmap Slot Error
~# devlink health dump show pci/0002:01:00.0 reporter hw_nix_gen
NIX_AF_GENERAL:
NIX General Interrupt Reg : 1
Rx multicast pkt drop
~# devlink health dump show pci/0002:01:00.0 reporter hw_nix_err
NIX_AF_ERR:
NIX Error Interrupt Reg : 64
Rx on unmapped PF_FUNC
Quality of service
==================
Hardware algorithms used in scheduling
--------------------------------------
octeontx2 silicon and CN10K transmit interface consists of five transmit levels
starting from SMQ/MDQ, TL4 to TL1. Each packet will traverse MDQ, TL4 to TL1
levels. Each level contains an array of queues to support scheduling and shaping.
The hardware uses the below algorithms depending on the priority of scheduler queues.
once the usercreates tc classes with different priorities, the driver configures
schedulers allocated to the class with specified priority along with rate-limiting
configuration.
1. Strict Priority
- Once packets are submitted to MDQ, hardware picks all active MDQs having different priority
using strict priority.
2. Round Robin
- Active MDQs having the same priority level are chosen using round robin.
Setup HTB offload
-----------------
1. Enable HW TC offload on the interface::
# ethtool -K <interface> hw-tc-offload on
2. Create htb root::
# tc qdisc add dev <interface> clsact
# tc qdisc replace dev <interface> root handle 1: htb offload
3. Create tc classes with different priorities::
# tc class add dev <interface> parent 1: classid 1:1 htb rate 10Gbit prio 1
# tc class add dev <interface> parent 1: classid 1:2 htb rate 10Gbit prio 7
4. Create tc classes with same priorities and different quantum::
# tc class add dev <interface> parent 1: classid 1:1 htb rate 10Gbit prio 2 quantum 409600
# tc class add dev <interface> parent 1: classid 1:2 htb rate 10Gbit prio 2 quantum 188416
# tc class add dev <interface> parent 1: classid 1:3 htb rate 10Gbit prio 2 quantum 32768
RVU Representors
================
RVU representor driver adds support for creation of representor devices for
RVU PFs' VFs in the system. Representor devices are created when user enables
the switchdev mode.
Switchdev mode can be enabled either before or after setting up SRIOV numVFs.
All representor devices share a single NIXLF but each has a dedicated Rx/Tx
queues. RVU PF representor driver registers a separate netdev for each
Rx/Tx queue pair.
Current HW does not support built-in switch which can do L2 learning and
forwarding packets between representee and representor. Hence, packet path
between representee and it's representor is achieved by setting up appropriate
NPC MCAM filters.
Transmit packets matching these filters will be loopbacked through hardware
loopback channel/interface (i.e, instead of sending them out of MAC interface).
Which will again match the installed filters and will be forwarded.
This way representee => representor and representor => representee packet
path is achieved. These rules get installed when representors are created
and gets active/deactivate based on the representor/representee interface state.
Usage example:
- Change device to switchdev mode::
# devlink dev eswitch set pci/0002:1c:00.0 mode switchdev
- List of representor devices on the system::
# ip link show
Rpf1vf0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000 link/ether f6:43:83:ee:26:21 brd ff:ff:ff:ff:ff:ff
Rpf1vf1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000 link/ether 12:b2:54:0e:24:54 brd ff:ff:ff:ff:ff:ff
Rpf1vf2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000 link/ether 4a:12:c4:4c:32:62 brd ff:ff:ff:ff:ff:ff
Rpf1vf3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000 link/ether ca:cb:68:0e:e2:6e brd ff:ff:ff:ff:ff:ff
Rpf2vf0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000 link/ether 06:cc:ad:b4:f0:93 brd ff:ff:ff:ff:ff:ff
To delete the representors devices from the system. Change the device to legacy mode.
- Change device to legacy mode::
# devlink dev eswitch set pci/0002:1c:00.0 mode legacy
RVU representors can be managed using devlink ports
(see :ref:`Documentation/networking/devlink/devlink-port.rst <devlink_port>`) interface.
- Show devlink ports of representors::
# devlink port
pci/0002:1c:00.0/0: type eth netdev Rpf1vf0 flavour physical port 0 splittable false
pci/0002:1c:00.0/1: type eth netdev Rpf1vf1 flavour pcivf controller 0 pfnum 1 vfnum 1 external false splittable false
pci/0002:1c:00.0/2: type eth netdev Rpf1vf2 flavour pcivf controller 0 pfnum 1 vfnum 2 external false splittable false
pci/0002:1c:00.0/3: type eth netdev Rpf1vf3 flavour pcivf controller 0 pfnum 1 vfnum 3 external false splittable false
Function attributes
===================
The RVU representor support function attributes for representors.
Port function configuration of the representors are supported through devlink eswitch port.
MAC address setup
-----------------
RVU representor driver support devlink port function attr mechanism to setup MAC
address. (refer to Documentation/networking/devlink/devlink-port.rst)
- To setup MAC address for port 2::
# devlink port function set pci/0002:1c:00.0/2 hw_addr 5c:a1:1b:5e:43:11
# devlink port show pci/0002:1c:00.0/2
pci/0002:1c:00.0/2: type eth netdev Rpf1vf2 flavour pcivf controller 0 pfnum 1 vfnum 2 external false splittable false
function:
hw_addr 5c:a1:1b:5e:43:11
TC offload
==========
The rvu representor driver implements support for offloading tc rules using port representors.
- Drop packets with vlan id 3::
# tc filter add dev Rpf1vf0 protocol 802.1Q parent ffff: flower vlan_id 3 vlan_ethtype ipv4 skip_sw action drop
- Redirect packets with vlan id 5 and IPv4 packets to eth1, after stripping vlan header.::
# tc filter add dev Rpf1vf0 ingress protocol 802.1Q flower vlan_id 5 vlan_ethtype ipv4 skip_sw action vlan pop action mirred ingress redirect dev eth1
linux-7.2.3/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/counters.rst
+1380
View File
File diff suppressed because it is too large Load Diff
linux-7.2.3/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/index.rst
+18
View File
@@ -0,0 +1,18 @@
.. SPDX-License-Identifier: GPL-2.0 OR Linux-OpenIB
.. include:: <isonum.txt>
Mellanox ConnectX(R) mlx5 core VPI Network Driver
=================================================
:Copyright: |copy| 2019, Mellanox Technologies LTD.
:Copyright: |copy| 2020-2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved.
Contents:
.. toctree::
:maxdepth: 2
kconfig
switchdev
tracepoints
counters
linux-7.2.3/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/kconfig.rst
+171
View File
@@ -0,0 +1,171 @@
.. SPDX-License-Identifier: GPL-2.0 OR Linux-OpenIB
.. include:: <isonum.txt>
=======================================
Enabling the driver and kconfig options
=======================================
:Copyright: |copy| 2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved.
| mlx5 core is modular and most of the major mlx5 core driver features can be selected (compiled in/out)
| at build time via kernel Kconfig flags.
| Basic features, ethernet net device rx/tx offloads and XDP, are available with the most basic flags
| CONFIG_MLX5_CORE=y/m and CONFIG_MLX5_CORE_EN=y.
| For the list of advanced features, please see below.
**CONFIG_MLX5_BRIDGE=(y/n)**
| Enable :ref:`Ethernet Bridging (BRIDGE) offloading support <mlx5_bridge_offload>`.
| This will provide the ability to add representors of mlx5 uplink and VF
| ports to Bridge and offloading rules for traffic between such ports.
| Supports VLANs (trunk and access modes).
**CONFIG_MLX5_CORE=(y/m/n)** (module mlx5_core.ko)
| The driver can be enabled by choosing CONFIG_MLX5_CORE=y/m in kernel config.
| This will provide mlx5 core driver for mlx5 ulps to interface with (mlx5e, mlx5_ib).
**CONFIG_MLX5_CORE_EN=(y/n)**
| Choosing this option will allow basic ethernet netdevice support with all of the standard rx/tx offloads.
| mlx5e is the mlx5 ulp driver which provides netdevice kernel interface, when chosen, mlx5e will be
| built-in into mlx5_core.ko.
**CONFIG_MLX5_CORE_EN_DCB=(y/n)**:
| Enables `Data Center Bridging (DCB) Support <https://enterprise-support.nvidia.com/s/article/howto-auto-config-pfc-and-ets-on-connectx-4-via-lldp-dcbx>`_.
**CONFIG_MLX5_CORE_IPOIB=(y/n)**
| IPoIB offloads & acceleration support.
| Requires CONFIG_MLX5_CORE_EN to provide an accelerated interface for the rdma
| IPoIB ulp netdevice.
**CONFIG_MLX5_CLS_ACT=(y/n)**
| Enables offload support for TC classifier action (NET_CLS_ACT).
| Works in both native NIC mode and Switchdev SRIOV mode.
| Flow-based classifiers, such as those registered through
| `tc-flower(8)`, are processed by the device, rather than the
| host. Actions that would then overwrite matching classification
| results would then be instant due to the offload.
**CONFIG_MLX5_EN_ARFS=(y/n)**
| Enables Hardware-accelerated receive flow steering (arfs) support, and ntuple filtering.
| https://enterprise-support.nvidia.com/s/article/howto-configure-arfs-on-connectx-4
**CONFIG_MLX5_EN_IPSEC=(y/n)**
| Enables :ref:`IPSec XFRM cryptography-offload acceleration <xfrm_device>`.
**CONFIG_MLX5_MACSEC=(y/n)**
| Build support for MACsec cryptography-offload acceleration in the NIC.
**CONFIG_MLX5_EN_RXNFC=(y/n)**
| Enables ethtool receive network flow classification, which allows user defined
| flow rules to direct traffic into arbitrary rx queue via ethtool set/get_rxnfc API.
**CONFIG_MLX5_EN_TLS=(y/n)**
| TLS cryptography-offload acceleration.
**CONFIG_MLX5_ESWITCH=(y/n)**
| Ethernet SRIOV E-Switch support in ConnectX NIC. E-Switch provides internal SRIOV packet steering
| and switching for the enabled VFs and PF in two available modes:
| 1) `Legacy SRIOV mode (L2 mac vlan steering based) <https://enterprise-support.nvidia.com/s/article/HowTo-Configure-SR-IOV-for-ConnectX-4-ConnectX-5-ConnectX-6-with-KVM-Ethernet>`_.
| 2) :ref:`Switchdev mode (eswitch offloads) <switchdev>`.
**CONFIG_MLX5_FPGA=(y/n)**
| Build support for the Innova family of network cards by Mellanox Technologies.
| Innova network cards are comprised of a ConnectX chip and an FPGA chip on one board.
| If you select this option, the mlx5_core driver will include the Innova FPGA core and allow
| building sandbox-specific client drivers.
**CONFIG_MLX5_INFINIBAND=(y/n/m)** (module mlx5_ib.ko)
| Provides low-level InfiniBand/RDMA and `RoCE <https://enterprise-support.nvidia.com/s/article/recommended-network-configuration-examples-for-roce-deployment>`_ support.
**CONFIG_MLX5_MPFS=(y/n)**
| Ethernet Multi-Physical Function Switch (MPFS) support in ConnectX NIC.
| MPFs is required for when `Multi-Host <https://www.nvidia.com/en-us/networking/multi-host/>`_ configuration is enabled to allow passing
| user configured unicast MAC addresses to the requesting PF.
**CONFIG_MLX5_SF=(y/n)**
| Build support for subfunction.
| Subfunctions are more light weight than PCI SRIOV VFs. Choosing this option
| will enable support for creating subfunction devices.
**CONFIG_MLX5_SF_MANAGER=(y/n)**
| Build support for subfunction port in the NIC. A Mellanox subfunction
| port is managed through devlink. A subfunction supports RDMA, netdevice
| and vdpa device. It is similar to a SRIOV VF but it doesn't require
| SRIOV support.
**CONFIG_MLX5_SW_STEERING=(y/n)**
| Build support for software-managed steering in the NIC.
**CONFIG_MLX5_HW_STEERING=(y/n)**
| Build support for hardware-managed steering in the NIC.
**CONFIG_MLX5_TC_CT=(y/n)**
| Support offloading connection tracking rules via tc ct action.
**CONFIG_MLX5_TC_SAMPLE=(y/n)**
| Support offloading sample rules via tc sample action.
**CONFIG_MLX5_VDPA=(y/n)**
| Support library for Mellanox VDPA drivers. Provides code that is
| common for all types of VDPA drivers. The following drivers are planned:
| net, block.
**CONFIG_MLX5_VDPA_NET=(y/n)**
| VDPA network driver for ConnectX6 and newer. Provides offloading
| of virtio net datapath such that descriptors put on the ring will
| be executed by the hardware. It also supports a variety of stateless
| offloads depending on the actual device used and firmware version.
**CONFIG_MLX5_VFIO_PCI=(y/n)**
| This provides migration support for MLX5 devices using the VFIO framework.
**External options** ( Choose if the corresponding mlx5 feature is required )
- CONFIG_MLXFW: When chosen, mlx5 firmware flashing support will be enabled (via devlink and ethtool).
- CONFIG_PTP_1588_CLOCK: When chosen, mlx5 ptp support will be enabled
- CONFIG_VXLAN: When chosen, mlx5 vxlan support will be enabled.
linux-7.2.3/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/switchdev.rst
+281
View File
@@ -0,0 +1,281 @@
.. SPDX-License-Identifier: GPL-2.0 OR Linux-OpenIB
.. include:: <isonum.txt>
=========
Switchdev
=========
:Copyright: |copy| 2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved.
.. _mlx5_bridge_offload:
Bridge offload
==============
The mlx5 driver implements support for offloading bridge rules when in switchdev
mode. Linux bridge FDBs are automatically offloaded when mlx5 switchdev
representor is attached to bridge.
- Change device to switchdev mode::
$ devlink dev eswitch set pci/0000:06:00.0 mode switchdev
- Attach mlx5 switchdev representor 'enp8s0f0' to bridge netdev 'bridge1'::
$ ip link set enp8s0f0 master bridge1
VLANs
-----
Following bridge VLAN functions are supported by mlx5:
- VLAN filtering (including multiple VLANs per port)::
$ ip link set bridge1 type bridge vlan_filtering 1
$ bridge vlan add dev enp8s0f0 vid 2-3
- VLAN push on bridge ingress::
$ bridge vlan add dev enp8s0f0 vid 3 pvid
- VLAN pop on bridge egress::
$ bridge vlan add dev enp8s0f0 vid 3 untagged
Subfunction
===========
Subfunction which are spawned over the E-switch are created only with devlink
device, and by default all the SF auxiliary devices are disabled.
This will allow user to configure the SF before the SF have been fully probed,
which will save time.
Usage example:
- Create SF::
$ devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 11
$ devlink port function set pci/0000:08:00.0/32768 hw_addr 00:00:00:00:00:11 state active
- Enable ETH auxiliary device::
$ devlink dev param set auxiliary/mlx5_core.sf.1 name enable_eth value true cmode driverinit
- Now, in order to fully probe the SF, use devlink reload::
$ devlink dev reload auxiliary/mlx5_core.sf.1
mlx5 supports ETH,rdma and vdpa (vnet) auxiliary devices devlink params (see :ref:`Documentation/networking/devlink/devlink-params.rst <devlink_params_generic>`).
mlx5 supports subfunction management using devlink port (see :ref:`Documentation/networking/devlink/devlink-port.rst <devlink_port>`) interface.
A subfunction has its own function capabilities and its own resources. This
means a subfunction has its own dedicated queues (txq, rxq, cq, eq). These
queues are neither shared nor stolen from the parent PCI function.
When a subfunction is RDMA capable, it has its own QP1, GID table, and RDMA
resources neither shared nor stolen from the parent PCI function.
A subfunction has a dedicated window in PCI BAR space that is not shared
with the other subfunctions or the parent PCI function. This ensures that all
devices (netdev, rdma, vdpa, etc.) of the subfunction accesses only assigned
PCI BAR space.
A subfunction supports eswitch representation through which it supports tc
offloads. The user configures eswitch to send/receive packets from/to
the subfunction port.
Subfunctions share PCI level resources such as PCI MSI-X IRQs with
other subfunctions and/or with its parent PCI function.
Example mlx5 software, system, and device view::
_______
| admin |
| user |----------
|_______| |
| |
____|____ __|______ _________________
| | | | | |
| devlink | | tc tool | | user |
| tool | |_________| | applications |
|_________| | |_________________|
| | | |
| | | | Userspace
+---------|-------------|-------------------|----------|--------------------+
| | +----------+ +----------+ Kernel
| | | netdev | | rdma dev |
| | +----------+ +----------+
(devlink port add/del | ^ ^
port function set) | | |
| | +---------------|
_____|___ | | _______|_______
| | | | | mlx5 class |
| devlink | +------------+ | | drivers |
| kernel | | rep netdev | | |(mlx5_core,ib) |
|_________| +------------+ | |_______________|
| | | ^
(devlink ops) | | (probe/remove)
_________|________ | | ____|________
| subfunction | | +---------------+ | subfunction |
| management driver|----- | subfunction |---| driver |
| (mlx5_core) | | auxiliary dev | | (mlx5_core) |
|__________________| +---------------+ |_____________|
| ^
(sf add/del, vhca events) |
| (device add/del)
_____|____ ____|________
| | | subfunction |
| PCI NIC |--- activate/deactivate events--->| host driver |
|__________| | (mlx5_core) |
|_____________|
Subfunction is created using devlink port interface.
- Change device to switchdev mode::
$ devlink dev eswitch set pci/0000:06:00.0 mode switchdev
- Add a devlink port of subfunction flavour::
$ devlink port add pci/0000:06:00.0 flavour pcisf pfnum 0 sfnum 88
pci/0000:06:00.0/32768: type eth netdev eth6 flavour pcisf controller 0 pfnum 0 sfnum 88 external false splittable false
function:
hw_addr 00:00:00:00:00:00 state inactive opstate detached
- Show a devlink port of the subfunction::
$ devlink port show pci/0000:06:00.0/32768
pci/0000:06:00.0/32768: type eth netdev enp6s0pf0sf88 flavour pcisf pfnum 0 sfnum 88
function:
hw_addr 00:00:00:00:00:00 state inactive opstate detached
- Delete a devlink port of subfunction after use::
$ devlink port del pci/0000:06:00.0/32768
Function attributes
===================
The mlx5 driver provides a mechanism to setup PCI VF/SF function attributes in
a unified way for SmartNIC and non-SmartNIC.
This is supported only when the eswitch mode is set to switchdev. Port function
configuration of the PCI VF/SF is supported through devlink eswitch port.
Port function attributes should be set before PCI VF/SF is enumerated by the
driver.
MAC address setup
-----------------
mlx5 driver support devlink port function attr mechanism to setup MAC
address. (refer to Documentation/networking/devlink/devlink-port.rst)
RoCE capability setup
~~~~~~~~~~~~~~~~~~~~~
Not all mlx5 PCI devices/SFs require RoCE capability.
When RoCE capability is disabled, it saves 1 Mbytes worth of system memory per
PCI devices/SF.
mlx5 driver support devlink port function attr mechanism to setup RoCE
capability. (refer to Documentation/networking/devlink/devlink-port.rst)
migratable capability setup
~~~~~~~~~~~~~~~~~~~~~~~~~~~
User who wants mlx5 PCI VFs to be able to perform live migration need to
explicitly enable the VF migratable capability.
mlx5 driver support devlink port function attr mechanism to setup migratable
capability. (refer to Documentation/networking/devlink/devlink-port.rst)
IPsec crypto capability setup
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
User who wants mlx5 PCI VFs to be able to perform IPsec crypto offloading need
to explicitly enable the VF ipsec_crypto capability. Enabling IPsec capability
for VFs is supported starting with ConnectX6dx devices and above. When a VF has
IPsec capability enabled, any IPsec offloading is blocked on the PF.
mlx5 driver support devlink port function attr mechanism to setup ipsec_crypto
capability. (refer to Documentation/networking/devlink/devlink-port.rst)
IPsec packet capability setup
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
User who wants mlx5 PCI VFs to be able to perform IPsec packet offloading need
to explicitly enable the VF ipsec_packet capability. Enabling IPsec capability
for VFs is supported starting with ConnectX6dx devices and above. When a VF has
IPsec capability enabled, any IPsec offloading is blocked on the PF.
mlx5 driver support devlink port function attr mechanism to setup ipsec_packet
capability. (refer to Documentation/networking/devlink/devlink-port.rst)
SF state setup
--------------
To use the SF, the user must activate the SF using the SF function state
attribute.
- Get the state of the SF identified by its unique devlink port index::
$ devlink port show ens2f0npf0sf88
pci/0000:06:00.0/32768: type eth netdev ens2f0npf0sf88 flavour pcisf controller 0 pfnum 0 sfnum 88 external false splittable false
function:
hw_addr 00:00:00:00:88:88 state inactive opstate detached
- Activate the function and verify its state is active::
$ devlink port function set ens2f0npf0sf88 state active
$ devlink port show ens2f0npf0sf88
pci/0000:06:00.0/32768: type eth netdev ens2f0npf0sf88 flavour pcisf controller 0 pfnum 0 sfnum 88 external false splittable false
function:
hw_addr 00:00:00:00:88:88 state active opstate detached
Upon function activation, the PF driver instance gets the event from the device
that a particular SF was activated. It's the cue to put the device on bus, probe
it and instantiate the devlink instance and class specific auxiliary devices
for it.
- Show the auxiliary device and port of the subfunction::
$ devlink dev show
devlink dev show auxiliary/mlx5_core.sf.4
$ devlink port show auxiliary/mlx5_core.sf.4/1
auxiliary/mlx5_core.sf.4/1: type eth netdev p0sf88 flavour virtual port 0 splittable false
$ rdma link show mlx5_0/1
link mlx5_0/1 state ACTIVE physical_state LINK_UP netdev p0sf88
$ rdma dev show
8: rocep6s0f1: node_type ca fw 16.29.0550 node_guid 248a:0703:00b3:d113 sys_image_guid 248a:0703:00b3:d112
13: mlx5_0: node_type ca fw 16.29.0550 node_guid 0000:00ff:fe00:8888 sys_image_guid 248a:0703:00b3:d112
- Subfunction auxiliary device and class device hierarchy::
mlx5_core.sf.4
(subfunction auxiliary device)
/\
/ \
/ \
/ \
/ \
mlx5_core.eth.4 mlx5_core.rdma.4
(sf eth aux dev) (sf rdma aux dev)
| |
| |
p0sf88 mlx5_0
(sf netdev) (sf rdma device)
Additionally, the SF port also gets the event when the driver attaches to the
auxiliary device of the subfunction. This results in changing the operational
state of the function. This provides visibility to the user to decide when is it
safe to delete the SF port for graceful termination of the subfunction.
- Show the SF port operational state::
$ devlink port show ens2f0npf0sf88
pci/0000:06:00.0/32768: type eth netdev ens2f0npf0sf88 flavour pcisf controller 0 pfnum 0 sfnum 88 external false splittable false
function:
hw_addr 00:00:00:00:88:88 state active opstate attached
linux-7.2.3/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/tracepoints.rst
+229
View File
@@ -0,0 +1,229 @@
.. SPDX-License-Identifier: GPL-2.0 OR Linux-OpenIB
.. include:: <isonum.txt>
===========
Tracepoints
===========
:Copyright: |copy| 2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved.
mlx5 driver provides internal tracepoints for tracking and debugging using
kernel tracepoints interfaces (refer to Documentation/trace/ftrace.rst).
For the list of support mlx5 events, check /sys/kernel/tracing/events/mlx5/.
tc and eswitch offloads tracepoints:
- mlx5e_configure_flower: trace flower filter actions and cookies offloaded to mlx5::
$ echo mlx5:mlx5e_configure_flower >> /sys/kernel/tracing/set_event
$ cat /sys/kernel/tracing/trace
...
tc-6535 [019] ...1 2672.404466: mlx5e_configure_flower: cookie=0000000067874a55 actions= REDIRECT
- mlx5e_delete_flower: trace flower filter actions and cookies deleted from mlx5::
$ echo mlx5:mlx5e_delete_flower >> /sys/kernel/tracing/set_event
$ cat /sys/kernel/tracing/trace
...
tc-6569 [010] .N.1 2686.379075: mlx5e_delete_flower: cookie=0000000067874a55 actions= NULL
- mlx5e_stats_flower: trace flower stats request::
$ echo mlx5:mlx5e_stats_flower >> /sys/kernel/tracing/set_event
$ cat /sys/kernel/tracing/trace
...
tc-6546 [010] ...1 2679.704889: mlx5e_stats_flower: cookie=0000000060eb3d6a bytes=0 packets=0 lastused=4295560217
- mlx5e_tc_update_neigh_used_value: trace tunnel rule neigh update value offloaded to mlx5::
$ echo mlx5:mlx5e_tc_update_neigh_used_value >> /sys/kernel/tracing/set_event
$ cat /sys/kernel/tracing/trace
...
kworker/u48:4-8806 [009] ...1 55117.882428: mlx5e_tc_update_neigh_used_value: netdev: ens1f0 IPv4: 1.1.1.10 IPv6: ::ffff:1.1.1.10 neigh_used=1
- mlx5e_rep_neigh_update: trace neigh update tasks scheduled due to neigh state change events::
$ echo mlx5:mlx5e_rep_neigh_update >> /sys/kernel/tracing/set_event
$ cat /sys/kernel/tracing/trace
...
kworker/u48:7-2221 [009] ...1 1475.387435: mlx5e_rep_neigh_update: netdev: ens1f0 MAC: 24:8a:07:9a:17:9a IPv4: 1.1.1.10 IPv6: ::ffff:1.1.1.10 neigh_connected=1
Bridge offloads tracepoints:
- mlx5_esw_bridge_fdb_entry_init: trace bridge FDB entry offloaded to mlx5::
$ echo mlx5:mlx5_esw_bridge_fdb_entry_init >> set_event
$ cat /sys/kernel/tracing/trace
...
kworker/u20:9-2217 [003] ...1 318.582243: mlx5_esw_bridge_fdb_entry_init: net_device=enp8s0f0_0 addr=e4:fd:05:08:00:02 vid=0 flags=0 used=0
- mlx5_esw_bridge_fdb_entry_cleanup: trace bridge FDB entry deleted from mlx5::
$ echo mlx5:mlx5_esw_bridge_fdb_entry_cleanup >> set_event
$ cat /sys/kernel/tracing/trace
...
ip-2581 [005] ...1 318.629871: mlx5_esw_bridge_fdb_entry_cleanup: net_device=enp8s0f0_1 addr=e4:fd:05:08:00:03 vid=0 flags=0 used=16
- mlx5_esw_bridge_fdb_entry_refresh: trace bridge FDB entry offload refreshed in
mlx5::
$ echo mlx5:mlx5_esw_bridge_fdb_entry_refresh >> set_event
$ cat /sys/kernel/tracing/trace
...
kworker/u20:8-3849 [003] ...1 466716: mlx5_esw_bridge_fdb_entry_refresh: net_device=enp8s0f0_0 addr=e4:fd:05:08:00:02 vid=3 flags=0 used=0
- mlx5_esw_bridge_vlan_create: trace bridge VLAN object add on mlx5
representor::
$ echo mlx5:mlx5_esw_bridge_vlan_create >> set_event
$ cat /sys/kernel/tracing/trace
...
ip-2560 [007] ...1 318.460258: mlx5_esw_bridge_vlan_create: vid=1 flags=6
- mlx5_esw_bridge_vlan_cleanup: trace bridge VLAN object delete from mlx5
representor::
$ echo mlx5:mlx5_esw_bridge_vlan_cleanup >> set_event
$ cat /sys/kernel/tracing/trace
...
bridge-2582 [007] ...1 318.653496: mlx5_esw_bridge_vlan_cleanup: vid=2 flags=8
- mlx5_esw_bridge_vport_init: trace mlx5 vport assigned with bridge upper
device::
$ echo mlx5:mlx5_esw_bridge_vport_init >> set_event
$ cat /sys/kernel/tracing/trace
...
ip-2560 [007] ...1 318.458915: mlx5_esw_bridge_vport_init: vport_num=1
- mlx5_esw_bridge_vport_cleanup: trace mlx5 vport removed from bridge upper
device::
$ echo mlx5:mlx5_esw_bridge_vport_cleanup >> set_event
$ cat /sys/kernel/tracing/trace
...
ip-5387 [000] ...1 573713: mlx5_esw_bridge_vport_cleanup: vport_num=1
Eswitch QoS tracepoints:
- mlx5_esw_vport_qos_create: trace creation of transmit scheduler arbiter for vport::
$ echo mlx5:mlx5_esw_vport_qos_create >> /sys/kernel/tracing/set_event
$ cat /sys/kernel/tracing/trace
...
<...>-23496 [018] .... 73136.838831: mlx5_esw_vport_qos_create: (0000:82:00.0) vport=2 tsar_ix=4 bw_share=0, max_rate=0 group=000000007b576bb3
- mlx5_esw_vport_qos_config: trace configuration of transmit scheduler arbiter for vport::
$ echo mlx5:mlx5_esw_vport_qos_config >> /sys/kernel/tracing/set_event
$ cat /sys/kernel/tracing/trace
...
<...>-26548 [023] .... 75754.223823: mlx5_esw_vport_qos_config: (0000:82:00.0) vport=1 tsar_ix=3 bw_share=34, max_rate=10000 group=000000007b576bb3
- mlx5_esw_vport_qos_destroy: trace deletion of transmit scheduler arbiter for vport::
$ echo mlx5:mlx5_esw_vport_qos_destroy >> /sys/kernel/tracing/set_event
$ cat /sys/kernel/tracing/trace
...
<...>-27418 [004] .... 76546.680901: mlx5_esw_vport_qos_destroy: (0000:82:00.0) vport=1 tsar_ix=3
- mlx5_esw_group_qos_create: trace creation of transmit scheduler arbiter for rate group::
$ echo mlx5:mlx5_esw_group_qos_create >> /sys/kernel/tracing/set_event
$ cat /sys/kernel/tracing/trace
...
<...>-26578 [008] .... 75776.022112: mlx5_esw_group_qos_create: (0000:82:00.0) group=000000008dac63ea tsar_ix=5
- mlx5_esw_group_qos_config: trace configuration of transmit scheduler arbiter for rate group::
$ echo mlx5:mlx5_esw_group_qos_config >> /sys/kernel/tracing/set_event
$ cat /sys/kernel/tracing/trace
...
<...>-27303 [020] .... 76461.455356: mlx5_esw_group_qos_config: (0000:82:00.0) group=000000008dac63ea tsar_ix=5 bw_share=100 max_rate=20000
- mlx5_esw_group_qos_destroy: trace deletion of transmit scheduler arbiter for group::
$ echo mlx5:mlx5_esw_group_qos_destroy >> /sys/kernel/tracing/set_event
$ cat /sys/kernel/tracing/trace
...
<...>-27418 [006] .... 76547.187258: mlx5_esw_group_qos_destroy: (0000:82:00.0) group=000000007b576bb3 tsar_ix=1
SF tracepoints:
- mlx5_sf_add: trace addition of the SF port::
$ echo mlx5:mlx5_sf_add >> /sys/kernel/tracing/set_event
$ cat /sys/kernel/tracing/trace
...
devlink-9363 [031] ..... 24610.188722: mlx5_sf_add: (0000:06:00.0) port_index=32768 controller=0 hw_id=0x8000 sfnum=88
- mlx5_sf_free: trace freeing of the SF port::
$ echo mlx5:mlx5_sf_free >> /sys/kernel/tracing/set_event
$ cat /sys/kernel/tracing/trace
...
devlink-9830 [038] ..... 26300.404749: mlx5_sf_free: (0000:06:00.0) port_index=32768 controller=0 hw_id=0x8000
- mlx5_sf_activate: trace activation of the SF port::
$ echo mlx5:mlx5_sf_activate >> /sys/kernel/tracing/set_event
$ cat /sys/kernel/tracing/trace
...
devlink-29841 [008] ..... 3669.635095: mlx5_sf_activate: (0000:08:00.0) port_index=32768 controller=0 hw_id=0x8000
- mlx5_sf_deactivate: trace deactivation of the SF port::
$ echo mlx5:mlx5_sf_deactivate >> /sys/kernel/tracing/set_event
$ cat /sys/kernel/tracing/trace
...
devlink-29994 [008] ..... 4015.969467: mlx5_sf_deactivate: (0000:08:00.0) port_index=32768 controller=0 hw_id=0x8000
- mlx5_sf_hwc_alloc: trace allocating of the hardware SF context::
$ echo mlx5:mlx5_sf_hwc_alloc >> /sys/kernel/tracing/set_event
$ cat /sys/kernel/tracing/trace
...
devlink-9775 [031] ..... 26296.385259: mlx5_sf_hwc_alloc: (0000:06:00.0) controller=0 hw_id=0x8000 sfnum=88
- mlx5_sf_hwc_free: trace freeing of the hardware SF context::
$ echo mlx5:mlx5_sf_hwc_free >> /sys/kernel/tracing/set_event
$ cat /sys/kernel/tracing/trace
...
kworker/u128:3-9093 [046] ..... 24625.365771: mlx5_sf_hwc_free: (0000:06:00.0) hw_id=0x8000
- mlx5_sf_hwc_deferred_free: trace deferred freeing of the hardware SF context::
$ echo mlx5:mlx5_sf_hwc_deferred_free >> /sys/kernel/tracing/set_event
$ cat /sys/kernel/tracing/trace
...
devlink-9519 [046] ..... 24624.400271: mlx5_sf_hwc_deferred_free: (0000:06:00.0) hw_id=0x8000
- mlx5_sf_update_state: trace state updates for SF contexts::
$ echo mlx5:mlx5_sf_update_state >> /sys/kernel/tracing/set_event
$ cat /sys/kernel/tracing/trace
...
kworker/u20:3-29490 [009] ..... 4141.453530: mlx5_sf_update_state: (0000:08:00.0) port_index=32768 controller=0 hw_id=0x8000 state=2
- mlx5_sf_vhca_event: trace SF vhca event and state::
$ echo mlx5:mlx5_sf_vhca_event >> /sys/kernel/tracing/set_event
$ cat /sys/kernel/tracing/trace
...
kworker/u128:3-9093 [046] ..... 24625.365525: mlx5_sf_vhca_event: (0000:06:00.0) hw_id=0x8000 sfnum=88 vhca_state=1
- mlx5_sf_dev_add: trace SF device add event::
$ echo mlx5:mlx5_sf_dev_add>> /sys/kernel/tracing/set_event
$ cat /sys/kernel/tracing/trace
...
kworker/u128:3-9093 [000] ..... 24616.524495: mlx5_sf_dev_add: (0000:06:00.0) sfdev=00000000fc5d96fd aux_id=4 hw_id=0x8000 sfnum=88
- mlx5_sf_dev_del: trace SF device delete event::
$ echo mlx5:mlx5_sf_dev_del >> /sys/kernel/tracing/set_event
$ cat /sys/kernel/tracing/trace
...
kworker/u128:3-9093 [044] ..... 24624.400749: mlx5_sf_dev_del: (0000:06:00.0) sfdev=00000000fc5d96fd aux_id=4 hw_id=0x8000 sfnum=88
linux-7.2.3/Documentation/networking/device_drivers/ethernet/meta/fbnic.rst
+192
View File
@@ -0,0 +1,192 @@
.. SPDX-License-Identifier: GPL-2.0+
=====================================
Meta Platforms Host Network Interface
=====================================
Firmware Versions
-----------------
fbnic has three components stored on the flash which are provided in one PLDM
image:
1. fw - The control firmware used to view and modify firmware settings, request
firmware actions, and retrieve firmware counters outside of the data path.
This is the firmware which fbnic_fw.c interacts with.
2. bootloader - The firmware which validate firmware security and control basic
operations including loading and updating the firmware. This is also known
as the cmrt firmware.
3. undi - This is the UEFI driver which is based on the Linux driver.
fbnic stores two copies of these three components on flash. This allows fbnic
to fall back to an older version of firmware automatically in case firmware
fails to boot. Version information for both is provided as running and stored.
The undi is only provided in stored as it is not actively running once the Linux
driver takes over.
devlink dev info provides version information for all three components. In
addition to the version the hg commit hash of the build is included as a
separate entry.
Configuration
-------------
Ringparams (ethtool -g / -G)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
fbnic has two submission (host -> device) rings for every completion
(device -> host) ring. The three ring objects together form a single
"queue" as used by higher layer software (a Rx, or a Tx queue).
For Rx the two submission rings are used to pass empty pages to the NIC.
Ring 0 is the Header Page Queue (HPQ), NIC will use its pages to place
L2-L4 headers (or full frames if frame is not header-data split).
Ring 1 is the Payload Page Queue (PPQ) and used for packet payloads.
The completion ring is used to receive packet notifications / metadata.
ethtool ``rx`` ringparam maps to the size of the completion ring,
``rx-mini`` to the HPQ, and ``rx-jumbo`` to the PPQ.
For Tx both submission rings can be used to submit packets, the completion
ring carries notifications for both. fbnic uses one of the submission
rings for normal traffic from the stack and the second one for XDP frames.
ethtool ``tx`` ringparam controls both the size of the submission rings
and the completion ring.
Every single entry on the HPQ and PPQ (``rx-mini``, ``rx-jumbo``)
corresponds to 4kB of allocated memory, while entries on the remaining
rings are in units of descriptors (8B). The ideal ratio of submission
and completion ring sizes will depend on the workload, as for small packets
multiple packets will fit into a single page.
Upgrading Firmware
------------------
fbnic supports updating firmware using signed PLDM images with devlink dev
flash. PLDM images are written into the flash. Flashing does not interrupt
the operation of the device.
On host boot the latest UEFI driver is always used, no explicit activation
is required. Firmware activation is required to run new control firmware. cmrt
firmware can only be activated by power cycling the NIC.
Health reporters
----------------
fw reporter
~~~~~~~~~~~
The ``fw`` health reporter tracks FW crashes. Dumping the reporter will
show the core dump of the most recent FW crash, and if no FW crash has
happened since power cycle - a snapshot of the FW memory. Diagnose callback
shows FW uptime based on the most recently received heartbeat message
(the crashes are detected by checking if uptime goes down).
otp reporter
~~~~~~~~~~~~
OTP memory ("fuses") are used for secure boot and anti-rollback
protection. The OTP memory is ECC protected, ECC errors indicate
either manufacturing defect or part deteriorating with age.
Statistics
----------
TX MAC Interface
~~~~~~~~~~~~~~~~
- ``ptp_illegal_req``: packets sent to the NIC with PTP request bit set but routed to BMC/FW
- ``ptp_good_ts``: packets successfully routed to MAC with PTP request bit set
- ``ptp_bad_ts``: packets destined for MAC with PTP request bit set but aborted because of some error (e.g., DMA read error)
TX Extension (TEI) Interface (TTI)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- ``tti_cm_drop``: control messages dropped at the TX Extension (TEI) Interface because of credit starvation
- ``tti_frame_drop``: packets dropped at the TX Extension (TEI) Interface because of credit starvation
- ``tti_tbi_drop``: packets dropped at the TX BMC Interface (TBI) because of credit starvation
RXB (RX Buffer) Enqueue
~~~~~~~~~~~~~~~~~~~~~~~
- ``rxb_integrity_err[i]``: frames enqueued with integrity errors (e.g., multi-bit ECC errors) on RXB input i
- ``rxb_mac_err[i]``: frames enqueued with MAC end-of-frame errors (e.g., bad FCS) on RXB input i
- ``rxb_parser_err[i]``: frames experienced RPC parser errors
- ``rxb_frm_err[i]``: frames experienced signaling errors (e.g., missing end-of-packet/start-of-packet) on RXB input i
- ``rxb_drbo[i]_frames``: frames received at RXB input i
- ``rxb_drbo[i]_bytes``: bytes received at RXB input i
RXB (RX Buffer) FIFO
~~~~~~~~~~~~~~~~~~~~
- ``rxb_fifo[i]_drop``: transitions into the drop state on RXB pool i
- ``rxb_fifo[i]_dropped_frames``: frames dropped on RXB pool i
- ``rxb_fifo[i]_ecn``: transitions into the ECN mark state on RXB pool i
- ``rxb_fifo[i]_level``: current occupancy of RXB pool i
RXB (RX Buffer) Dequeue
~~~~~~~~~~~~~~~~~~~~~~~
- ``rxb_intf[i]_frames``: frames sent to the output i
- ``rxb_intf[i]_bytes``: bytes sent to the output i
- ``rxb_pbuf[i]_frames``: frames sent to output i from the perspective of internal packet buffer
- ``rxb_pbuf[i]_bytes``: bytes sent to output i from the perspective of internal packet buffer
RPC (Rx parser)
~~~~~~~~~~~~~~~
- ``rpc_unkn_etype``: frames containing unknown EtherType
- ``rpc_unkn_ext_hdr``: frames containing unknown IPv6 extension header
- ``rpc_ipv4_frag``: frames containing IPv4 fragment
- ``rpc_ipv6_frag``: frames containing IPv6 fragment
- ``rpc_ipv4_esp``: frames with IPv4 ESP encapsulation
- ``rpc_ipv6_esp``: frames with IPv6 ESP encapsulation
- ``rpc_tcp_opt_err``: frames which encountered TCP option parsing error
- ``rpc_out_of_hdr_err``: frames where header was larger than parsable region
- ``ovr_size_err``: oversized frames
Hardware Queues
~~~~~~~~~~~~~~~
1. RX DMA Engine:
- ``rde_[i]_pkt_err``: packets with MAC EOP, RPC parser, RXB truncation, or RDE frame truncation errors. These error are flagged in the packet metadata because of cut-through support but the actual drop happens once PCIE/RDE is reached.
- ``rde_[i]_pkt_cq_drop``: packets dropped because RCQ is full
- ``rde_[i]_pkt_bdq_drop``: packets dropped because HPQ or PPQ ran out of host buffer
PCIe
~~~~
The fbnic driver exposes PCIe hardware performance statistics through debugfs
(``pcie_stats``). These statistics provide insights into PCIe transaction
behavior and potential performance bottlenecks.
1. PCIe Transaction Counters:
These counters track PCIe transaction activity:
- ``pcie_ob_rd_tlp``: Outbound read Transaction Layer Packets count
- ``pcie_ob_rd_dword``: DWORDs transferred in outbound read transactions
- ``pcie_ob_wr_tlp``: Outbound write Transaction Layer Packets count
- ``pcie_ob_wr_dword``: DWORDs transferred in outbound write
transactions
- ``pcie_ob_cpl_tlp``: Outbound completion TLP count
- ``pcie_ob_cpl_dword``: DWORDs transferred in outbound completion TLPs
2. PCIe Resource Monitoring:
These counters indicate PCIe resource exhaustion events:
- ``pcie_ob_rd_no_tag``: Read requests dropped due to tag unavailability
- ``pcie_ob_rd_no_cpl_cred``: Read requests dropped due to completion
credit exhaustion
- ``pcie_ob_rd_no_np_cred``: Read requests dropped due to non-posted
credit exhaustion
XDP Length Error:
~~~~~~~~~~~~~~~~~
For XDP programs without frags support, fbnic tries to make sure that MTU fits
into a single buffer. If an oversized frame is received and gets fragmented,
it is dropped and the following netlink counters are updated
- ``rx-length``: number of frames dropped due to lack of fragmentation
support in the attached XDP program
- ``rx-errors``: total number of packets with errors received on the interface
linux-7.2.3/Documentation/networking/device_drivers/ethernet/microsoft/netvsc.rst
+120
View File
@@ -0,0 +1,120 @@
.. SPDX-License-Identifier: GPL-2.0
======================
Hyper-V network driver
======================
Compatibility
=============
This driver is compatible with Windows Server 2012 R2, 2016 and
Windows 10.
Features
========
Checksum offload
----------------
The netvsc driver supports checksum offload as long as the
Hyper-V host version does. Windows Server 2016 and Azure
support checksum offload for TCP and UDP for both IPv4 and
IPv6. Windows Server 2012 only supports checksum offload for TCP.
Receive Side Scaling
--------------------
Hyper-V supports receive side scaling. For TCP & UDP, packets can
be distributed among available queues based on IP address and port
number.
For TCP & UDP, we can switch hash level between L3 and L4 by ethtool
command. TCP/UDP over IPv4 and v6 can be set differently. The default
hash level is L4. We currently only allow switching TX hash level
from within the guests.
On Azure, fragmented UDP packets have high loss rate with L4
hashing. Using L3 hashing is recommended in this case.
For example, for UDP over IPv4 on eth0:
To include UDP port numbers in hashing::
ethtool -N eth0 rx-flow-hash udp4 sdfn
To exclude UDP port numbers in hashing::
ethtool -N eth0 rx-flow-hash udp4 sd
To show UDP hash level::
ethtool -n eth0 rx-flow-hash udp4
Generic Receive Offload, aka GRO
--------------------------------
The driver supports GRO and it is enabled by default. GRO coalesces
like packets and significantly reduces CPU usage under heavy Rx
load.
Large Receive Offload (LRO), or Receive Side Coalescing (RSC)
-------------------------------------------------------------
The driver supports LRO/RSC in the vSwitch feature. It reduces the per packet
processing overhead by coalescing multiple TCP segments when possible. The
feature is enabled by default on VMs running on Windows Server 2019 and
later. It may be changed by ethtool command::
ethtool -K eth0 lro on
ethtool -K eth0 lro off
SR-IOV support
--------------
Hyper-V supports SR-IOV as a hardware acceleration option. If SR-IOV
is enabled in both the vSwitch and the guest configuration, then the
Virtual Function (VF) device is passed to the guest as a PCI
device. In this case, both a synthetic (netvsc) and VF device are
visible in the guest OS and both NIC's have the same MAC address.
The VF is enslaved by netvsc device. The netvsc driver will transparently
switch the data path to the VF when it is available and up.
Network state (addresses, firewall, etc) should be applied only to the
netvsc device; the slave device should not be accessed directly in
most cases. The exceptions are if some special queue discipline or
flow direction is desired, these should be applied directly to the
VF slave device.
Receive Buffer
--------------
Packets are received into a receive area which is created when device
is probed. The receive area is broken into MTU sized chunks and each may
contain one or more packets. The number of receive sections may be changed
via ethtool Rx ring parameters.
There is a similar send buffer which is used to aggregate packets
for sending. The send area is broken into chunks, typically of 6144
bytes, each of section may contain one or more packets. Small
packets are usually transmitted via copy to the send buffer. However,
if the buffer is temporarily exhausted, or the packet to be transmitted is
an LSO packet, the driver will provide the host with pointers to the data
from the SKB. This attempts to achieve a balance between the overhead of
data copy and the impact of remapping VM memory to be accessible by the
host.
XDP support
-----------
XDP (eXpress Data Path) is a feature that runs eBPF bytecode at the early
stage when packets arrive at a NIC card. The goal is to increase performance
for packet processing, reducing the overhead of SKB allocation and other
upper network layers.
hv_netvsc supports XDP in native mode, and transparently sets the XDP
program on the associated VF NIC as well.
Setting / unsetting XDP program on synthetic NIC (netvsc) propagates to
VF NIC automatically. Setting / unsetting XDP program on VF NIC directly
is not recommended, also not propagated to synthetic NIC, and may be
overwritten by setting of synthetic NIC.
XDP program cannot run with LRO (RSC) enabled, so you need to disable LRO
before running XDP::
ethtool -K eth0 lro off
XDP_REDIRECT action is not yet supported.
linux-7.2.3/Documentation/networking/device_drivers/ethernet/mucse/rnpgbe.rst
+17
View File
@@ -0,0 +1,17 @@
.. SPDX-License-Identifier: GPL-2.0
===========================================================
Linux Base Driver for MUCSE(R) Gigabit PCI Express Adapters
===========================================================
Contents
========
- Identifying Your Adapter
Identifying Your Adapter
========================
The driver is compatible with devices based on the following:
* MUCSE(R) Ethernet Controller N210 series
* MUCSE(R) Ethernet Controller N500 series
linux-7.2.3/Documentation/networking/device_drivers/ethernet/netronome/nfp.rst
+374
View File
@@ -0,0 +1,374 @@
.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
.. include:: <isonum.txt>
===========================================
Network Flow Processor (NFP) Kernel Drivers
===========================================
:Copyright: |copy| 2019, Netronome Systems, Inc.
:Copyright: |copy| 2022, Corigine, Inc.
Contents
========
- `Overview`_
- `Acquiring Firmware`_
- `Devlink Info`_
- `Configure Device`_
- `Statistics`_
Overview
========
This driver supports Netronome and Corigine's line of Network Flow Processor
devices, including the NFP3800, NFP4000, NFP5000, and NFP6000 models, which
are also incorporated in the companies' family of Agilio SmartNICs. The SR-IOV
physical and virtual functions for these devices are supported by the driver.
Acquiring Firmware
==================
The NFP3800, NFP4000 and NFP6000 devices require application specific firmware
to function. Application firmware can be located either on the host file system
or in the device flash (if supported by management firmware).
Firmware files on the host filesystem contain card type (`AMDA-*` string), media
config etc. They should be placed in `/lib/firmware/netronome` directory to
load firmware from the host file system.
Firmware for basic NIC operation is available in the upstream
`linux-firmware.git` repository.
A more comprehensive list of firmware can be downloaded from the
`Corigine Support site <https://www.corigine.com/DPUDownload.html>`_.
Firmware in NVRAM
-----------------
Recent versions of management firmware supports loading application
firmware from flash when the host driver gets probed. The firmware loading
policy configuration may be used to configure this feature appropriately.
Devlink or ethtool can be used to update the application firmware on the device
flash by providing the appropriate `nic_AMDA*.nffw` file to the respective
command. Users need to take care to write the correct firmware image for the
card and media configuration to flash.
Available storage space in flash depends on the card being used.
Dealing with multiple projects
------------------------------
NFP hardware is fully programmable therefore there can be different
firmware images targeting different applications.
When using application firmware from host, we recommend placing
actual firmware files in application-named subdirectories in
`/lib/firmware/netronome` and linking the desired files, e.g.::
$ tree /lib/firmware/netronome/
/lib/firmware/netronome/
├── bpf
│   ├── nic_AMDA0081-0001_1x40.nffw
│   └── nic_AMDA0081-0001_4x10.nffw
├── flower
│   ├── nic_AMDA0081-0001_1x40.nffw
│   └── nic_AMDA0081-0001_4x10.nffw
├── nic
│   ├── nic_AMDA0081-0001_1x40.nffw
│   └── nic_AMDA0081-0001_4x10.nffw
├── nic_AMDA0081-0001_1x40.nffw -> bpf/nic_AMDA0081-0001_1x40.nffw
└── nic_AMDA0081-0001_4x10.nffw -> bpf/nic_AMDA0081-0001_4x10.nffw
3 directories, 8 files
You may need to use hard instead of symbolic links on distributions
which use old `mkinitrd` command instead of `dracut` (e.g. Ubuntu).
After changing firmware files you may need to regenerate the initramfs
image. Initramfs contains drivers and firmware files your system may
need to boot. Refer to the documentation of your distribution to find
out how to update initramfs. Good indication of stale initramfs
is system loading wrong driver or firmware on boot, but when driver is
later reloaded manually everything works correctly.
Selecting firmware per device
-----------------------------
Most commonly all cards on the system use the same type of firmware.
If you want to load a specific firmware image for a specific card, you
can use either the PCI bus address or serial number. The driver will
print which files it's looking for when it recognizes a NFP device::
nfp: Looking for firmware file in order of priority:
nfp: netronome/serial-00-12-34-aa-bb-cc-10-ff.nffw: not found
nfp: netronome/pci-0000:02:00.0.nffw: not found
nfp: netronome/nic_AMDA0081-0001_1x40.nffw: found, loading...
In this case if file (or link) called *serial-00-12-34-aa-bb-5d-10-ff.nffw*
or *pci-0000:02:00.0.nffw* is present in `/lib/firmware/netronome` this
firmware file will take precedence over `nic_AMDA*` files.
Note that `serial-*` and `pci-*` files are **not** automatically included
in initramfs, you will have to refer to documentation of appropriate tools
to find out how to include them.
Running firmware version
------------------------
The version of the loaded firmware for a particular <netdev> interface,
(e.g. enp4s0), or an interface's port <netdev port> (e.g. enp4s0np0) can
be displayed with the ethtool command::
$ ethtool -i <netdev>
Firmware loading policy
-----------------------
Firmware loading policy is controlled via three HWinfo parameters
stored as key value pairs in the device flash:
app_fw_from_flash
Defines which firmware should take precedence, 'Disk' (0), 'Flash' (1) or
the 'Preferred' (2) firmware. When 'Preferred' is selected, the management
firmware makes the decision over which firmware will be loaded by comparing
versions of the flash firmware and the host supplied firmware.
This variable is configurable using the 'fw_load_policy'
devlink parameter.
abi_drv_reset
Defines if the driver should reset the firmware when
the driver is probed, either 'Disk' (0) if firmware was found on disk,
'Always' (1) reset or 'Never' (2) reset. Note that the device is always
reset on driver unload if firmware was loaded when the driver was probed.
This variable is configurable using the 'reset_dev_on_drv_probe'
devlink parameter.
abi_drv_load_ifc
Defines a list of PF devices allowed to load FW on the device.
This variable is not currently user configurable.
Devlink Info
============
The devlink info command displays the running and stored firmware versions
on the device, serial number and board information.
Devlink info command example (replace PCI address)::
$ devlink dev info pci/0000:03:00.0
pci/0000:03:00.0:
driver nfp
serial_number CSAAMDA2001-1003000111
versions:
fixed:
board.id AMDA2001-1003
board.rev 01
board.manufacture CSA
board.model mozart
running:
fw.mgmt 22.10.0-rc3
fw.cpld 0x1000003
fw.app nic-22.09.0
chip.init AMDA-2001-1003 1003000111
stored:
fw.bundle_id bspbundle_1003000111
fw.mgmt 22.10.0-rc3
fw.cpld 0x0
chip.init AMDA-2001-1003 1003000111
Configure Device
================
This section explains how to use Agilio SmartNICs running basic NIC firmware.
Configure interface link-speed
------------------------------
The following steps explains how to change between 10G mode and 25G mode on
Agilio CX 2x25GbE cards. The changing of port speed must be done in order,
port 0 (p0) must be set to 10G before port 1 (p1) may be set to 10G.
Down the respective interface(s)::
$ ip link set dev <netdev port 0> down
$ ip link set dev <netdev port 1> down
Set interface link-speed to 10G::
$ ethtool -s <netdev port 0> speed 10000
$ ethtool -s <netdev port 1> speed 10000
Set interface link-speed to 25G::
$ ethtool -s <netdev port 0> speed 25000
$ ethtool -s <netdev port 1> speed 25000
Reload driver for changes to take effect::
$ rmmod nfp; modprobe nfp
Configure interface Maximum Transmission Unit (MTU)
---------------------------------------------------
The MTU of interfaces can temporarily be set using the iproute2, ip link or
ifconfig tools. Note that this change will not persist. Setting this via
Network Manager, or another appropriate OS configuration tool, is
recommended as changes to the MTU using Network Manager can be made to
persist.
Set interface MTU to 9000 bytes::
$ ip link set dev <netdev port> mtu 9000
It is the responsibility of the user or the orchestration layer to set
appropriate MTU values when handling jumbo frames or utilizing tunnels. For
example, if packets sent from a VM are to be encapsulated on the card and
egress a physical port, then the MTU of the VF should be set to lower than
that of the physical port to account for the extra bytes added by the
additional header. If a setup is expected to see fallback traffic between
the SmartNIC and the kernel then the user should also ensure that the PF MTU
is appropriately set to avoid unexpected drops on this path.
Configure Forward Error Correction (FEC) modes
----------------------------------------------
Agilio SmartNICs support FEC mode configuration, e.g. Auto, Firecode Base-R,
ReedSolomon and Off modes. Each physical port's FEC mode can be set
independently using ethtool. The supported FEC modes for an interface can
be viewed using::
$ ethtool <netdev>
The currently configured FEC mode can be viewed using::
$ ethtool --show-fec <netdev>
To force the FEC mode for a particular port, auto-negotiation must be disabled
(see the `Auto-negotiation`_ section). An example of how to set the FEC mode
to Reed-Solomon is::
$ ethtool --set-fec <netdev> encoding rs
Auto-negotiation
----------------
To change auto-negotiation settings, the link must first be put down. After the
link is down, auto-negotiation can be enabled or disabled using::
ethtool -s <netdev> autoneg <on|off>
Statistics
==========
Following device statistics are available through the ``ethtool -S`` interface:
.. flat-table:: NFP device statistics
:header-rows: 1
:widths: 3 1 11
* - Name
- ID
- Meaning
* - dev_rx_discards
- 1
- Packet can be discarded on the RX path for one of the following reasons:
* The NIC is not in promisc mode, and the destination MAC address
doesn't match the interfaces' MAC address.
* The received packet is larger than the max buffer size on the host.
I.e. it exceeds the Layer 3 MRU.
* There is no freelist descriptor available on the host for the packet.
It is likely that the NIC couldn't cache one in time.
* A BPF program discarded the packet.
* The datapath drop action was executed.
* The MAC discarded the packet due to lack of ingress buffer space
on the NIC.
* - dev_rx_errors
- 2
- A packet can be counted (and dropped) as RX error for the following
reasons:
* A problem with the VEB lookup (only when SR-IOV is used).
* A physical layer problem that causes Ethernet errors, like FCS or
alignment errors. The cause is usually faulty cables or SFPs.
* - dev_rx_bytes
- 3
- Total number of bytes received.
* - dev_rx_uc_bytes
- 4
- Unicast bytes received.
* - dev_rx_mc_bytes
- 5
- Multicast bytes received.
* - dev_rx_bc_bytes
- 6
- Broadcast bytes received.
* - dev_rx_pkts
- 7
- Total number of packets received.
* - dev_rx_mc_pkts
- 8
- Multicast packets received.
* - dev_rx_bc_pkts
- 9
- Broadcast packets received.
* - dev_tx_discards
- 10
- A packet can be discarded in the TX direction if the MAC is
being flow controlled and the NIC runs out of TX queue space.
* - dev_tx_errors
- 11
- A packet can be counted as TX error (and dropped) for one for the
following reasons:
* The packet is an LSO segment, but the Layer 3 or Layer 4 offset
could not be determined. Therefore LSO could not continue.
* An invalid packet descriptor was received over PCIe.
* The packet Layer 3 length exceeds the device MTU.
* An error on the MAC/physical layer. Usually due to faulty cables or
SFPs.
* A CTM buffer could not be allocated.
* The packet offset was incorrect and could not be fixed by the NIC.
* - dev_tx_bytes
- 12
- Total number of bytes transmitted.
* - dev_tx_uc_bytes
- 13
- Unicast bytes transmitted.
* - dev_tx_mc_bytes
- 14
- Multicast bytes transmitted.
* - dev_tx_bc_bytes
- 15
- Broadcast bytes transmitted.
* - dev_tx_pkts
- 16
- Total number of packets transmitted.
* - dev_tx_mc_pkts
- 17
- Multicast packets transmitted.
* - dev_tx_bc_pkts
- 18
- Broadcast packets transmitted.
Note that statistics unknown to the driver will be displayed as
``dev_unknown_stat$ID``, where ``$ID`` refers to the second column
above.
linux-7.2.3/Documentation/networking/device_drivers/ethernet/pensando/ionic.rst
+306
View File
@@ -0,0 +1,306 @@
.. SPDX-License-Identifier: GPL-2.0+
========================================================
Linux Driver for the Pensando(R) Ethernet adapter family
========================================================
Pensando Linux Ethernet driver.
Copyright(c) 2019 Pensando Systems, Inc
Contents
========
- Identifying the Adapter
- Enabling the driver
- Configuring the driver
- RDMA Support via Auxiliary Device
- Statistics
- Support
Identifying the Adapter
=======================
To find if one or more Pensando PCI Ethernet devices are installed on the
host, check for the PCI devices::
$ lspci -d 1dd8:
b5:00.0 Ethernet controller: Device 1dd8:1002
b6:00.0 Ethernet controller: Device 1dd8:1002
If such devices are listed as above, then the ionic.ko driver should find
and configure them for use. There should be log entries in the kernel
messages such as these::
$ dmesg | grep ionic
ionic 0000:b5:00.0: 126.016 Gb/s available PCIe bandwidth (8.0 GT/s PCIe x16 link)
ionic 0000:b5:00.0 enp181s0: renamed from eth0
ionic 0000:b5:00.0 enp181s0: Link up - 100 Gbps
ionic 0000:b6:00.0: 126.016 Gb/s available PCIe bandwidth (8.0 GT/s PCIe x16 link)
ionic 0000:b6:00.0 enp182s0: renamed from eth0
ionic 0000:b6:00.0 enp182s0: Link up - 100 Gbps
Driver and firmware version information can be gathered with either of
ethtool or devlink tools::
$ ethtool -i enp181s0
driver: ionic
version: 5.7.0
firmware-version: 1.8.0-28
...
$ devlink dev info pci/0000:b5:00.0
pci/0000:b5:00.0:
driver ionic
serial_number FLM18420073
versions:
fixed:
asic.id 0x0
asic.rev 0x0
running:
fw 1.8.0-28
See Documentation/networking/devlink/ionic.rst for more information
on the devlink dev info data.
Enabling the driver
===================
The driver is enabled via the standard kernel configuration system,
using the make command::
make oldconfig/menuconfig/etc.
The driver is located in the menu structure at:
-> Device Drivers
-> Network device support (NETDEVICES [=y])
-> Ethernet driver support
-> Pensando devices
-> Pensando Ethernet IONIC Support
Configuring the Driver
======================
MTU
---
Jumbo frame support is available with a maximum size of 9194 bytes.
Interrupt coalescing
--------------------
Interrupt coalescing can be configured by changing the rx-usecs value with
the "ethtool -C" command. The rx-usecs range is 0-190. The tx-usecs value
reflects the rx-usecs value as they are tied together on the same interrupt.
SR-IOV
------
Minimal SR-IOV support is currently offered and can be enabled by setting
the sysfs 'sriov_numvfs' value, if supported by your particular firmware
configuration.
XDP
---
Support for XDP includes the basics, plus Jumbo frames, Redirect and
ndo_xmit. There is no current support for zero-copy sockets or HW offload.
RDMA Support via Auxiliary Device
=================================
The ionic driver supports RDMA (Remote Direct Memory Access) functionality
through the Linux auxiliary device framework when advertised by the firmware.
RDMA capability is detected during device initialization, and if supported,
the ethernet driver will create an auxiliary device that allows the RDMA
driver to bind and provide InfiniBand/RoCE functionality.
Statistics
==========
Basic hardware stats
--------------------
The commands ``netstat -i``, ``ip -s link show``, and ``ifconfig`` show
a limited set of statistics taken directly from firmware. For example::
$ ip -s link show enp181s0
7: enp181s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 00:ae:cd:00:07:68 brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
414 5 0 0 0 0
TX: bytes packets errors dropped carrier collsns
1384 18 0 0 0 0
ethtool -S
----------
The statistics shown from the ``ethtool -S`` command includes a combination of
driver counters and firmware counters, including port and queue specific values.
The driver values are counters computed by the driver, and the firmware values
are gathered by the firmware from the port hardware and passed through the
driver with no further interpretation.
Driver port specific::
tx_packets: 12
tx_bytes: 964
rx_packets: 5
rx_bytes: 414
tx_tso: 0
tx_tso_bytes: 0
tx_csum_none: 12
tx_csum: 0
rx_csum_none: 0
rx_csum_complete: 3
rx_csum_error: 0
xdp_drop: 0
xdp_aborted: 0
xdp_pass: 0
xdp_tx: 0
xdp_redirect: 0
xdp_frames: 0
Driver queue specific::
tx_0_pkts: 3
tx_0_bytes: 294
tx_0_clean: 3
tx_0_dma_map_err: 0
tx_0_linearize: 0
tx_0_frags: 0
tx_0_tso: 0
tx_0_tso_bytes: 0
tx_0_hwstamp_valid: 0
tx_0_hwstamp_invalid: 0
tx_0_csum_none: 3
tx_0_csum: 0
tx_0_vlan_inserted: 0
tx_0_xdp_frames: 0
rx_0_pkts: 2
rx_0_bytes: 120
rx_0_dma_map_err: 0
rx_0_alloc_err: 0
rx_0_csum_none: 0
rx_0_csum_complete: 0
rx_0_csum_error: 0
rx_0_hwstamp_valid: 0
rx_0_hwstamp_invalid: 0
rx_0_dropped: 0
rx_0_vlan_stripped: 0
rx_0_xdp_drop: 0
rx_0_xdp_aborted: 0
rx_0_xdp_pass: 0
rx_0_xdp_tx: 0
rx_0_xdp_redirect: 0
Firmware port specific::
hw_tx_dropped: 0
hw_rx_dropped: 0
hw_rx_over_errors: 0
hw_rx_missed_errors: 0
hw_tx_aborted_errors: 0
frames_rx_ok: 15
frames_rx_all: 15
frames_rx_bad_fcs: 0
frames_rx_bad_all: 0
octets_rx_ok: 1290
octets_rx_all: 1290
frames_rx_unicast: 10
frames_rx_multicast: 5
frames_rx_broadcast: 0
frames_rx_pause: 0
frames_rx_bad_length: 0
frames_rx_undersized: 0
frames_rx_oversized: 0
frames_rx_fragments: 0
frames_rx_jabber: 0
frames_rx_pripause: 0
frames_rx_stomped_crc: 0
frames_rx_too_long: 0
frames_rx_vlan_good: 3
frames_rx_dropped: 0
frames_rx_less_than_64b: 0
frames_rx_64b: 4
frames_rx_65b_127b: 11
frames_rx_128b_255b: 0
frames_rx_256b_511b: 0
frames_rx_512b_1023b: 0
frames_rx_1024b_1518b: 0
frames_rx_1519b_2047b: 0
frames_rx_2048b_4095b: 0
frames_rx_4096b_8191b: 0
frames_rx_8192b_9215b: 0
frames_rx_other: 0
frames_tx_ok: 31
frames_tx_all: 31
frames_tx_bad: 0
octets_tx_ok: 2614
octets_tx_total: 2614
frames_tx_unicast: 8
frames_tx_multicast: 21
frames_tx_broadcast: 2
frames_tx_pause: 0
frames_tx_pripause: 0
frames_tx_vlan: 0
frames_tx_less_than_64b: 0
frames_tx_64b: 4
frames_tx_65b_127b: 27
frames_tx_128b_255b: 0
frames_tx_256b_511b: 0
frames_tx_512b_1023b: 0
frames_tx_1024b_1518b: 0
frames_tx_1519b_2047b: 0
frames_tx_2048b_4095b: 0
frames_tx_4096b_8191b: 0
frames_tx_8192b_9215b: 0
frames_tx_other: 0
frames_tx_pri_0: 0
frames_tx_pri_1: 0
frames_tx_pri_2: 0
frames_tx_pri_3: 0
frames_tx_pri_4: 0
frames_tx_pri_5: 0
frames_tx_pri_6: 0
frames_tx_pri_7: 0
frames_rx_pri_0: 0
frames_rx_pri_1: 0
frames_rx_pri_2: 0
frames_rx_pri_3: 0
frames_rx_pri_4: 0
frames_rx_pri_5: 0
frames_rx_pri_6: 0
frames_rx_pri_7: 0
tx_pripause_0_1us_count: 0
tx_pripause_1_1us_count: 0
tx_pripause_2_1us_count: 0
tx_pripause_3_1us_count: 0
tx_pripause_4_1us_count: 0
tx_pripause_5_1us_count: 0
tx_pripause_6_1us_count: 0
tx_pripause_7_1us_count: 0
rx_pripause_0_1us_count: 0
rx_pripause_1_1us_count: 0
rx_pripause_2_1us_count: 0
rx_pripause_3_1us_count: 0
rx_pripause_4_1us_count: 0
rx_pripause_5_1us_count: 0
rx_pripause_6_1us_count: 0
rx_pripause_7_1us_count: 0
rx_pause_1us_count: 0
frames_tx_truncated: 0
Support
=======
For general Linux networking support, please use the netdev mailing
list, which is monitored by Pensando personnel::
netdev@vger.kernel.org
For more specific support needs, please use the Pensando driver support
email::
drivers@pensando.io
linux-7.2.3/Documentation/networking/device_drivers/ethernet/pensando/ionic_rdma.rst
+52
View File
@@ -0,0 +1,52 @@
.. SPDX-License-Identifier: GPL-2.0+
===========================================================
RDMA Driver for the AMD Pensando(R) Ethernet adapter family
===========================================================
AMD Pensando RDMA driver.
Copyright (C) 2018-2025, Advanced Micro Devices, Inc.
Overview
========
The ionic_rdma driver provides Remote Direct Memory Access functionality
for AMD Pensando DSC (Distributed Services Card) devices. This driver
implements RDMA capabilities as an auxiliary driver that operates in
conjunction with the ionic ethernet driver.
The ionic ethernet driver detects RDMA capability during device
initialization and creates auxiliary devices that the ionic_rdma driver
binds to, establishing the RDMA data path and control interfaces.
Identifying the Adapter
=======================
See Documentation/networking/device_drivers/ethernet/pensando/ionic.rst
for more information on identifying the adapter.
Enabling the driver
===================
The ionic_rdma driver depends on the ionic ethernet driver.
See Documentation/networking/device_drivers/ethernet/pensando/ionic.rst
for detailed information on enabling and configuring the ionic driver.
The ionic_rdma driver is enabled via the standard kernel configuration system,
using the make command::
make oldconfig/menuconfig/etc.
The driver is located in the menu structure at:
-> Device Drivers
-> InfiniBand support
-> AMD Pensando DSC RDMA/RoCE Support
Support
=======
For general Linux RDMA support, please use the RDMA mailing
list, which is monitored by AMD Pensando personnel::
linux-rdma@vger.kernel.org
linux-7.2.3/Documentation/networking/device_drivers/ethernet/qualcomm/ppe/ppe.rst
+194
View File
@@ -0,0 +1,194 @@
.. SPDX-License-Identifier: GPL-2.0
===============================================
PPE Ethernet Driver for Qualcomm IPQ SoC Family
===============================================
Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
Author: Lei Wei <quic_leiwei@quicinc.com>
Contents
========
- `PPE Overview`_
- `PPE Driver Overview`_
- `PPE Driver Supported SoCs`_
- `Enabling the Driver`_
- `Debugging`_
PPE Overview
============
IPQ (Qualcomm Internet Processor) SoC (System-on-Chip) series is Qualcomm's series of
networking SoC for Wi-Fi access points. The PPE (Packet Process Engine) is the Ethernet
packet process engine in the IPQ SoC.
Below is a simplified hardware diagram of IPQ9574 SoC which includes the PPE engine and
other blocks which are in the SoC but outside the PPE engine. These blocks work together
to enable the Ethernet for the IPQ SoC::
+------+ +------+ +------+ +------+ +------+ +------+ start +-------+
|netdev| |netdev| |netdev| |netdev| |netdev| |netdev|<------|PHYLINK|
+------+ +------+ +------+ +------+ +------+ +------+ stop +-+-+-+-+
| | | ^
+-------+ +-------------------------+--------+----------------------+ | | |
| GCC | | | EDMA | | | | |
+---+---+ | PPE +---+----+ | | | |
| clk | | | | | |
+-------->| +-----------------------+------+-----+---------------+ | | | |
| | Switch Core |Port0 | |Port7(EIP FIFO)| | | | |
| | +---+--+ +------+--------+ | | | |
| | | | | | | | |
+-------+ | | +------+---------------+----+ | | | | |
|CMN PLL| | | +---+ +---+ +----+ | +--------+ | | | | | |
+---+---+ | | |BM | |QM | |SCH | | | L2/L3 | ....... | | | | | |
| | | | +---+ +---+ +----+ | +--------+ | | | | | |
| | | | +------+--------------------+ | | | | |
| | | | | | | | | |
| v | | +-----+-+-----+-+-----+-+-+---+--+-----+-+-----+ | | | | |
| +------+ | | |Port1| |Port2| |Port3| |Port4| |Port5| |Port6| | | | | |
| |NSSCC | | | +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ | | mac| | |
| +-+-+--+ | | |MAC0 | |MAC1 | |MAC2 | |MAC3 | |MAC4 | |MAC5 | | |<---+ | |
| ^ | |clk | | +-----+-+-----+-+-----+-+-----+--+-----+-+-----+ | | ops | |
| | | +------>| +----|------|-------|-------|---------|--------|-----+ | | |
| | | +---------------------------------------------------------+ | |
| | | | | | | | | | |
| | | MII clk | QSGMII USXGMII USXGMII | |
| | +--------------->| | | | | | | |
| | +-------------------------+ +---------+ +---------+ | |
| |125/312.5MHz clk| (PCS0) | | (PCS1) | | (PCS2) | pcs ops | |
| +----------------+ UNIPHY0 | | UNIPHY1 | | UNIPHY2 |<--------+ |
+----------------->| | | | | | |
| 31.25MHz ref clk +-------------------------+ +---------+ +---------+ |
| | | | | | | |
| +-----------------------------------------------------+ |
|25/50MHz ref clk| +-------------------------+ +------+ +------+ | link |
+--------------->| | QUAD PHY | | PHY4 | | PHY5 | |---------+
| +-------------------------+ +------+ +------+ | change
| |
| MDIO bus |
+-----------------------------------------------------+
The CMN (Common) PLL, NSSCC (Networking Sub System Clock Controller) and GCC (Global
Clock Controller) blocks are in the SoC and act as clock providers.
The UNIPHY block is in the SoC and provides the PCS (Physical Coding Sublayer) and
XPCS (10-Gigabit Physical Coding Sublayer) functions to support different interface
modes between the PPE MAC and the external PHY.
This documentation focuses on the descriptions of PPE engine and the PPE driver.
The Ethernet functionality in the PPE (Packet Process Engine) is comprised of three
components: the switch core, port wrapper and Ethernet DMA.
The Switch core in the IPQ9574 PPE has maximum of 6 front panel ports and two FIFO
interfaces. One of the two FIFO interfaces is used for Ethernet port to host CPU
communication using Ethernet DMA. The other one is used to communicate to the EIP
engine which is used for IPsec offload. On the IPQ9574, the PPE includes 6 GMAC/XGMACs
that can be connected with external Ethernet PHY. Switch core also includes BM (Buffer
Management), QM (Queue Management) and SCH (Scheduler) modules for supporting the
packet processing.
The port wrapper provides connections from the 6 GMAC/XGMACS to UNIPHY (PCS) supporting
various modes such as SGMII/QSGMII/PSGMII/USXGMII/10G-BASER. There are 3 UNIPHY (PCS)
instances supported on the IPQ9574.
Ethernet DMA is used to transmit and receive packets between the Ethernet subsystem
and ARM host CPU.
The following lists the main blocks in the PPE engine which will be driven by this
PPE driver:
- BM
BM is the hardware buffer manager for the PPE switch ports.
- QM
Queue Manager for managing the egress hardware queues of the PPE switch ports.
- SCH
The scheduler which manages the hardware traffic scheduling for the PPE switch ports.
- L2
The L2 block performs the packet bridging in the switch core. The bridge domain is
represented by the VSI (Virtual Switch Instance) domain in PPE. FDB learning can be
enabled based on the VSI domain and bridge forwarding occurs within the VSI domain.
- MAC
The PPE in the IPQ9574 supports up to six MACs (MAC0 to MAC5) which are corresponding
to six switch ports (port1 to port6). The MAC block is connected with external PHY
through the UNIPHY PCS block. Each MAC block includes the GMAC and XGMAC blocks and
the switch port can select to use GMAC or XMAC through a MUX selection according to
the external PHY's capability.
- EDMA (Ethernet DMA)
The Ethernet DMA is used to transmit and receive Ethernet packets between the PPE
ports and the ARM cores.
The received packet on a PPE MAC port can be forwarded to another PPE MAC port. It can
be also forwarded to internal switch port0 so that the packet can be delivered to the
ARM cores using the Ethernet DMA (EDMA) engine. The Ethernet DMA driver will deliver the
packet to the corresponding 'netdevice' interface.
The software instantiations of the PPE MAC (netdevice), PCS and external PHYs interact
with the Linux PHYLINK framework to manage the connectivity between the PPE ports and
the connected PHYs, and the port link states. This is also illustrated in above diagram.
PPE Driver Overview
===================
PPE driver is Ethernet driver for the Qualcomm IPQ SoC. It is a single platform driver
which includes the PPE part and Ethernet DMA part. The PPE part initializes and drives the
various blocks in PPE switch core such as BM/QM/L2 blocks and the PPE MACs. The EDMA part
drives the Ethernet DMA for packet transfer between PPE ports and ARM cores, and enables
the netdevice driver for the PPE ports.
The PPE driver files in drivers/net/ethernet/qualcomm/ppe/ are listed as below:
- Makefile
- ppe.c
- ppe.h
- ppe_config.c
- ppe_config.h
- ppe_debugfs.c
- ppe_debugfs.h
- ppe_regs.h
The ppe.c file contains the main PPE platform driver and undertakes the initialization of
PPE switch core blocks such as QM, BM and L2. The configuration APIs for these hardware
blocks are provided in the ppe_config.c file.
The ppe.h defines the PPE device data structure which will be used by PPE driver functions.
The ppe_debugfs.c enables the PPE statistics counters such as PPE port Rx and Tx counters,
CPU code counters and queue counters.
PPE Driver Supported SoCs
=========================
The PPE driver supports the following IPQ SoC:
- IPQ9574
Enabling the Driver
===================
The driver is located in the menu structure at::
-> Device Drivers
-> Network device support (NETDEVICES [=y])
-> Ethernet driver support
-> Qualcomm devices
-> Qualcomm Technologies, Inc. PPE Ethernet support
If the driver is built as a module, the module will be called qcom-ppe.
The PPE driver functionally depends on the CMN PLL and NSSCC clock controller drivers.
Please make sure the dependent modules are installed before installing the PPE driver
module.
Debugging
=========
The PPE hardware counters can be accessed using debugfs interface from the
``/sys/kernel/debug/ppe/`` directory.
linux-7.2.3/Documentation/networking/device_drivers/ethernet/stmicro/stmmac.rst
+700
View File
@@ -0,0 +1,700 @@
.. SPDX-License-Identifier: GPL-2.0+
==============================================================
Linux Driver for the Synopsys(R) Ethernet Controllers "stmmac"
==============================================================
Authors: Giuseppe Cavallaro <peppe.cavallaro@st.com>,
Alexandre Torgue <alexandre.torgue@st.com>, Jose Abreu <joabreu@synopsys.com>
Contents
========
- In This Release
- Feature List
- Kernel Configuration
- Command Line Parameters
- Driver Information and Notes
- Debug Information
- Support
In This Release
===============
This file describes the stmmac Linux Driver for all the Synopsys(R) Ethernet
Controllers.
Currently, this network device driver is for all STi embedded MAC/GMAC
(i.e. 7xxx/5xxx SoCs), SPEAr (arm), Loongson1B (mips) and XILINX XC2V3000
FF1152AMT0221 D1215994A VIRTEX FPGA board. The Synopsys Ethernet QoS 5.0 IPK
is also supported.
DesignWare(R) Cores Ethernet MAC 10/100/1000 Universal version 3.70a
(and older) and DesignWare(R) Cores Ethernet Quality-of-Service version 4.0
(and upper) have been used for developing this driver as well as
DesignWare(R) Cores XGMAC - 10G Ethernet MAC and DesignWare(R) Cores
Enterprise MAC - 100G Ethernet MAC.
This driver supports both the platform bus and PCI.
This driver includes support for the following Synopsys(R) DesignWare(R)
Cores Ethernet Controllers and corresponding minimum and maximum versions:
+-------------------------------+--------------+--------------+--------------+
| Controller Name | Min. Version | Max. Version | Abbrev. Name |
+===============================+==============+==============+==============+
| Ethernet MAC Universal | N/A | 3.73a | GMAC |
+-------------------------------+--------------+--------------+--------------+
| Ethernet Quality-of-Service | 4.00a | N/A | GMAC4+ |
+-------------------------------+--------------+--------------+--------------+
| XGMAC - 10G Ethernet MAC | 2.10a | N/A | XGMAC2+ |
+-------------------------------+--------------+--------------+--------------+
| XLGMAC - 100G Ethernet MAC | 2.00a | N/A | XLGMAC2+ |
+-------------------------------+--------------+--------------+--------------+
For questions related to hardware requirements, refer to the documentation
supplied with your Ethernet adapter. All hardware requirements listed apply
to use with Linux.
Feature List
============
The following features are available in this driver:
- GMII/MII/RGMII/SGMII/RMII/XGMII/XLGMII Interface
- Half-Duplex / Full-Duplex Operation
- Energy Efficient Ethernet (EEE)
- IEEE 802.3x PAUSE Packets (Flow Control)
- RMON/MIB Counters
- IEEE 1588 Timestamping (PTP)
- Pulse-Per-Second Output (PPS)
- MDIO Clause 22 / Clause 45 Interface
- MAC Loopback
- ARP Offloading
- Automatic CRC / PAD Insertion and Checking
- Checksum Offload for Received and Transmitted Packets
- Standard or Jumbo Ethernet Packets
- Source Address Insertion / Replacement
- VLAN TAG Insertion / Replacement / Deletion / Filtering (HASH and PERFECT)
- Programmable TX and RX Watchdog and Coalesce Settings
- Destination Address Filtering (PERFECT)
- HASH Filtering (Multicast)
- Layer 3 / Layer 4 Filtering
- Remote Wake-Up Detection
- Receive Side Scaling (RSS)
- Frame Preemption for TX and RX
- Programmable Burst Length, Threshold, Queue Size
- Multiple Queues (up to 8)
- Multiple Scheduling Algorithms (TX: WRR, DWRR, WFQ, SP, CBS, EST, TBS;
RX: WRR, SP)
- Flexible RX Parser
- TCP / UDP Segmentation Offload (TSO, USO)
- Split Header (SPH)
- Safety Features (ECC Protection, Data Parity Protection)
- Selftests using Ethtool
Kernel Configuration
====================
The kernel configuration option is ``CONFIG_STMMAC_ETH``:
- ``CONFIG_STMMAC_PLATFORM``: is to enable the platform driver.
- ``CONFIG_STMMAC_PCI``: is to enable the pci driver.
Command Line Parameters
=======================
If the driver is built as a module the following optional parameters are used
by entering them on the command line with the modprobe command using this
syntax (e.g. for PCI module)::
modprobe stmmac_pci [<option>=<VAL1>,<VAL2>,...]
Driver parameters can be also passed in command line by using::
stmmaceth=watchdog:100,chain_mode=1
The default value for each parameter is generally the recommended setting,
unless otherwise noted.
watchdog
--------
:Valid Range: 5000-None
:Default Value: 5000
This parameter overrides the transmit timeout in milliseconds.
debug
-----
:Valid Range: 0-16 (0=none,...,16=all)
:Default Value: 0
This parameter adjusts the level of debug messages displayed in the system
logs.
phyaddr
-------
:Valid Range: 0-31
:Default Value: -1
This parameter overrides the physical address of the PHY device.
flow_ctrl
---------
:Valid Range: 0-3 (0=off,1=rx,2=tx,3=rx/tx)
:Default Value: 3
This parameter changes the default Flow Control ability.
pause
-----
:Valid Range: 0-65535
:Default Value: 65535
This parameter changes the default Flow Control Pause time.
tc
--
:Valid Range: 64-256
:Default Value: 64
This parameter changes the default HW FIFO Threshold control value.
buf_sz
------
:Valid Range: 1536-16384
:Default Value: 1536
This parameter changes the default RX DMA packet buffer size.
eee_timer
---------
:Valid Range: 0-None
:Default Value: 1000
This parameter changes the default LPI TX Expiration time in milliseconds.
chain_mode
----------
:Valid Range: 0-1 (0=off,1=on)
:Default Value: 0
This parameter changes the default mode of operation from Ring Mode to
Chain Mode.
Driver Information and Notes
============================
Transmit Process
----------------
The xmit method is invoked when the kernel needs to transmit a packet; it sets
the descriptors in the ring and informs the DMA engine that there is a packet
ready to be transmitted.
By default, the driver sets the ``NETIF_F_SG`` bit in the features field of
the ``net_device`` structure, enabling the scatter-gather feature. This is
true on chips and configurations where the checksum can be done in hardware.
Once the controller has finished transmitting the packet, timer will be
scheduled to release the transmit resources.
Receive Process
---------------
When one or more packets are received, an interrupt happens. The interrupts
are not queued, so the driver has to scan all the descriptors in the ring
during the receive process.
This is based on NAPI, so the interrupt handler signals only if there is work
to be done, and it exits. Then the poll method will be scheduled at some
future point.
The incoming packets are stored, by the DMA, in a list of pre-allocated socket
buffers in order to avoid the memcpy (zero-copy).
Interrupt Mitigation
--------------------
The driver is able to mitigate the number of its DMA interrupts using NAPI for
the reception on chips older than the 3.50. New chips have an HW RX Watchdog
used for this mitigation.
Mitigation parameters can be tuned by ethtool.
WoL
---
Wake up on Lan feature through Magic and Unicast frames are supported for the
GMAC, GMAC4/5 and XGMAC core.
DMA Descriptors
---------------
Driver handles both normal and alternate descriptors. The latter has been only
tested on DesignWare(R) Cores Ethernet MAC Universal version 3.41a and later.
stmmac supports DMA descriptor to operate both in dual buffer (RING) and
linked-list(CHAINED) mode. In RING each descriptor points to two data buffer
pointers whereas in CHAINED mode they point to only one data buffer pointer.
RING mode is the default.
In CHAINED mode each descriptor will have pointer to next descriptor in the
list, hence creating the explicit chaining in the descriptor itself, whereas
such explicit chaining is not possible in RING mode.
Extended Descriptors
--------------------
The extended descriptors give us information about the Ethernet payload when
it is carrying PTP packets or TCP/UDP/ICMP over IP. These are not available on
GMAC Synopsys(R) chips older than the 3.50. At probe time the driver will
decide if these can be actually used. This support also is mandatory for PTPv2
because the extra descriptors are used for saving the hardware timestamps and
Extended Status.
Ethtool Support
---------------
Ethtool is supported. For example, driver statistics (including RMON),
internal errors can be taken using::
ethtool -S ethX
Ethtool selftests are also supported. This allows to do some early sanity
checks to the HW using MAC and PHY loopback mechanisms::
ethtool -t ethX
Jumbo and Segmentation Offloading
---------------------------------
Jumbo frames are supported and tested for the GMAC. The GSO has been also
added but it's performed in software. LRO is not supported.
TSO Support
-----------
TSO (TCP Segmentation Offload) feature is supported by GMAC > 4.x and XGMAC
chip family. When a packet is sent through TCP protocol, the TCP stack ensures
that the SKB provided to the low level driver (stmmac in our case) matches
with the maximum frame len (IP header + TCP header + payload <= 1500 bytes
(for MTU set to 1500)). It means that if an application using TCP want to send
a packet which will have a length (after adding headers) > 1514 the packet
will be split in several TCP packets: The data payload is split and headers
(TCP/IP ..) are added. It is done by software.
When TSO is enabled, the TCP stack doesn't care about the maximum frame length
and provide SKB packet to stmmac as it is. The GMAC IP will have to perform
the segmentation by it self to match with maximum frame length.
This feature can be enabled in device tree through ``snps,tso`` entry.
Energy Efficient Ethernet
-------------------------
Energy Efficient Ethernet (EEE) enables IEEE 802.3 MAC sublayer along with a
family of Physical layer to operate in the Low Power Idle (LPI) mode. The EEE
mode supports the IEEE 802.3 MAC operation at 100Mbps, 1000Mbps and 1Gbps.
The LPI mode allows power saving by switching off parts of the communication
device functionality when there is no data to be transmitted & received.
The system on both the side of the link can disable some functionalities and
save power during the period of low-link utilization. The MAC controls whether
the system should enter or exit the LPI mode and communicate this to PHY.
As soon as the interface is opened, the driver verifies if the EEE can be
supported. This is done by looking at both the DMA HW capability register and
the PHY devices MCD registers.
To enter in TX LPI mode the driver needs to have a software timer that enable
and disable the LPI mode when there is nothing to be transmitted.
Precision Time Protocol (PTP)
-----------------------------
The driver supports the IEEE 1588-2002, Precision Time Protocol (PTP), which
enables precise synchronization of clocks in measurement and control systems
implemented with technologies such as network communication.
In addition to the basic timestamp features mentioned in IEEE 1588-2002
Timestamps, new GMAC cores support the advanced timestamp features.
IEEE 1588-2008 can be enabled when configuring the Kernel.
SGMII/RGMII Support
-------------------
New GMAC devices provide own way to manage RGMII/SGMII. This information is
available at run-time by looking at the HW capability register. This means
that the stmmac can manage auto-negotiation and link status w/o using the
PHYLIB stuff. In fact, the HW provides a subset of extended registers to
restart the ANE, verify Full/Half duplex mode and Speed. Thanks to these
registers, it is possible to look at the Auto-negotiated Link Parter Ability.
Physical
--------
The driver is compatible with Physical Abstraction Layer to be connected with
PHY and GPHY devices.
Platform Information
--------------------
Several information can be passed through the platform and device-tree.
::
struct plat_stmmacenet_data {
1) Bus identifier::
int bus_id;
2) PHY Physical Address. If set to -1 the driver will pick the first PHY it
finds::
int phy_addr;
3) PHY Device Interface::
int interface;
4) Specific platform fields for the MDIO bus::
struct stmmac_mdio_bus_data *mdio_bus_data;
5) Internal DMA parameters::
struct stmmac_dma_cfg *dma_cfg;
6) Fixed CSR Clock Range selection::
int clk_csr;
7) HW uses the GMAC core::
int has_gmac;
8) If set the MAC will use Enhanced Descriptors::
int enh_desc;
9) Core is able to perform TX Checksum and/or RX Checksum in HW::
int tx_coe;
int rx_coe;
11) Some HWs are not able to perform the csum in HW for over-sized frames due
to limited buffer sizes. Setting this flag the csum will be done in SW on
JUMBO frames::
int bugged_jumbo;
12) Core has the embedded power module::
int pmt;
13) Force DMA to use the Store and Forward mode or Threshold mode::
int force_sf_dma_mode;
int force_thresh_dma_mode;
15) Force to disable the RX Watchdog feature and switch to NAPI mode::
int riwt_off;
16) Limit the maximum operating speed and MTU::
int max_speed;
int maxmtu;
18) Number of Multicast/Unicast filters::
int multicast_filter_bins;
int unicast_filter_entries;
20) Limit the maximum TX and RX FIFO size::
int tx_fifo_size;
int rx_fifo_size;
21) Use the specified number of TX and RX Queues::
u32 rx_queues_to_use;
u32 tx_queues_to_use;
22) Use the specified TX and RX scheduling algorithm::
u8 rx_sched_algorithm;
u8 tx_sched_algorithm;
23) Internal TX and RX Queue parameters::
struct stmmac_rxq_cfg rx_queues_cfg[MTL_MAX_RX_QUEUES];
struct stmmac_txq_cfg tx_queues_cfg[MTL_MAX_TX_QUEUES];
24) This callback is used for modifying some syscfg registers (on ST SoCs)
according to the link speed negotiated by the physical layer::
void (*fix_mac_speed)(void *priv, unsigned int speed);
25) Callbacks used for calling a custom initialization; This is sometimes
necessary on some platforms (e.g. ST boxes) where the HW needs to have set
some PIO lines or system cfg registers. init/exit callbacks should not use
or modify platform data::
int (*init)(struct platform_device *pdev, void *priv);
void (*exit)(struct platform_device *pdev, void *priv);
26) Perform HW setup of the bus. For example, on some ST platforms this field
is used to configure the AMBA bridge to generate more efficient STBus traffic::
struct mac_device_info *(*setup)(void *priv);
void *bsp_priv;
27) Internal clocks and rates::
struct clk *stmmac_clk;
struct clk *pclk;
struct clk *clk_ptp_ref;
unsigned int clk_ptp_rate;
unsigned int clk_ref_rate;
s32 ptp_max_adj;
28) Main reset::
struct reset_control *stmmac_rst;
29) AXI Internal Parameters::
struct stmmac_axi *axi;
30) HW uses GMAC>4 cores::
int has_gmac4;
31) HW is sun8i based::
bool has_sun8i;
32) Enables TSO feature::
bool tso_en;
33) Enables Receive Side Scaling (RSS) feature::
int rss_en;
34) MAC Port selection::
int mac_port_sel_speed;
35) Enables TX LPI Clock Gating::
bool en_tx_lpi_clockgating;
36) HW uses XGMAC>2.10 cores::
int has_xgmac;
::
}
For MDIO bus data, we have:
::
struct stmmac_mdio_bus_data {
1) PHY mask passed when MDIO bus is registered::
unsigned int phy_mask;
2) List of IRQs, one per PHY::
int *irqs;
3) If IRQs is NULL, use this for probed PHY::
int probed_phy_irq;
4) Set to true if PHY needs reset::
bool needs_reset;
::
}
For DMA engine configuration, we have:
::
struct stmmac_dma_cfg {
1) Programmable Burst Length (TX and RX)::
int pbl;
2) If set, DMA TX / RX will use this value rather than pbl::
int txpbl;
int rxpbl;
3) Enable 8xPBL::
bool pblx8;
4) Enable Fixed or Mixed burst::
int fixed_burst;
int mixed_burst;
5) Enable Address Aligned Beats::
bool aal;
6) Enable Enhanced Addressing (> 32 bits)::
bool eame;
::
}
For DMA AXI parameters, we have:
::
struct stmmac_axi {
1) Enable AXI LPI::
bool axi_lpi_en;
bool axi_xit_frm;
2) Set AXI Write / Read maximum outstanding requests::
u32 axi_wr_osr_lmt;
u32 axi_rd_osr_lmt;
3) Set AXI 4KB bursts::
bool axi_kbbe;
4) Set AXI maximum burst length map::
u32 axi_blen[AXI_BLEN];
5) Set AXI Fixed burst / mixed burst::
bool axi_fb;
bool axi_mb;
6) Set AXI rebuild incrx mode::
bool axi_rb;
::
}
For the RX Queues configuration, we have:
::
struct stmmac_rxq_cfg {
1) Mode to use (DCB or AVB)::
u8 mode_to_use;
2) DMA channel to use::
u32 chan;
3) Packet routing, if applicable::
u8 pkt_route;
4) Use priority routing, and priority to route::
bool use_prio;
u32 prio;
::
}
For the TX Queues configuration, we have:
::
struct stmmac_txq_cfg {
1) Queue weight in scheduler::
u32 weight;
2) Mode to use (DCB or AVB)::
u8 mode_to_use;
3) Credit Base Shaper Parameters::
u32 send_slope;
u32 idle_slope;
u32 high_credit;
u32 low_credit;
4) Use priority scheduling, and priority::
bool use_prio;
u32 prio;
::
}
Device Tree Information
-----------------------
Please refer to the following document:
Documentation/devicetree/bindings/net/snps,dwmac.yaml
HW Capabilities
---------------
Note that, starting from new chips, where it is available the HW capability
register, many configurations are discovered at run-time for example to
understand if EEE, HW csum, PTP, enhanced descriptor etc are actually
available. As strategy adopted in this driver, the information from the HW
capability register can replace what has been passed from the platform.
Debug Information
=================
The driver exports many information i.e. internal statistics, debug
information, MAC and DMA registers etc.
These can be read in several ways depending on the type of the information
actually needed.
For example a user can be use the ethtool support to get statistics: e.g.
using: ``ethtool -S ethX`` (that shows the Management counters (MMC) if
supported) or sees the MAC/DMA registers: e.g. using: ``ethtool -d ethX``
Compiling the Kernel with ``CONFIG_DEBUG_FS`` the driver will export the
following debugfs entries:
- ``descriptors_status``: To show the DMA TX/RX descriptor rings
- ``dma_cap``: To show the HW Capabilities
Developer can also use the ``debug`` module parameter to get further debug
information (please see: NETIF Msg Level).
Support
=======
If an issue is identified with the released source code on a supported kernel
with a supported adapter, email the specific information related to the
issue to netdev@vger.kernel.org
linux-7.2.3/Documentation/networking/device_drivers/ethernet/ti/am65_nuss_cpsw_switchdev.rst
+143
View File
@@ -0,0 +1,143 @@
.. SPDX-License-Identifier: GPL-2.0
===================================================================
Texas Instruments K3 AM65 CPSW NUSS switchdev based ethernet driver
===================================================================
:Version: 1.0
Port renaming
=============
In order to rename via udev::
ip -d link show dev sw0p1 | grep switchid
SUBSYSTEM=="net", ACTION=="add", ATTR{phys_switch_id}==<switchid>, \
ATTR{phys_port_name}!="", NAME="sw0$attr{phys_port_name}"
Multi mac mode
==============
- The driver is operating in multi-mac mode by default, thus
working as N individual network interfaces.
Devlink configuration parameters
================================
See Documentation/networking/devlink/am65-nuss-cpsw-switch.rst
Enabling "switch"
=================
The Switch mode can be enabled by configuring devlink driver parameter
"switch_mode" to 1/true::
devlink dev param set platform/c000000.ethernet \
name switch_mode value true cmode runtime
This can be done regardless of the state of Port's netdev devices - UP/DOWN, but
Port's netdev devices have to be in UP before joining to the bridge to avoid
overwriting of bridge configuration as CPSW switch driver completely reloads its
configuration when first port changes its state to UP.
When both interfaces have joined the bridge - CPSW switch driver will enable
marking packets with offload_fwd_mark flag.
All configuration is implemented via switchdev API.
Bridge setup
============
::
devlink dev param set platform/c000000.ethernet \
name switch_mode value true cmode runtime
ip link add name br0 type bridge
ip link set dev br0 type bridge ageing_time 1000
ip link set dev sw0p1 up
ip link set dev sw0p2 up
ip link set dev sw0p1 master br0
ip link set dev sw0p2 master br0
[*] bridge vlan add dev br0 vid 1 pvid untagged self
[*] if vlan_filtering=1. where default_pvid=1
Note. Steps [*] are mandatory.
On/off STP
==========
::
ip link set dev BRDEV type bridge stp_state 1/0
VLAN configuration
==================
::
bridge vlan add dev br0 vid 1 pvid untagged self <---- add cpu port to VLAN 1
Note. This step is mandatory for bridge/default_pvid.
Add extra VLANs
===============
1. untagged::
bridge vlan add dev sw0p1 vid 100 pvid untagged master
bridge vlan add dev sw0p2 vid 100 pvid untagged master
bridge vlan add dev br0 vid 100 pvid untagged self <---- Add cpu port to VLAN100
2. tagged::
bridge vlan add dev sw0p1 vid 100 master
bridge vlan add dev sw0p2 vid 100 master
bridge vlan add dev br0 vid 100 pvid tagged self <---- Add cpu port to VLAN100
FDBs
----
FDBs are automatically added on the appropriate switch port upon detection
Manually adding FDBs::
bridge fdb add aa:bb:cc:dd:ee:ff dev sw0p1 master vlan 100
bridge fdb add aa:bb:cc:dd:ee:fe dev sw0p2 master <---- Add on all VLANs
MDBs
----
MDBs are automatically added on the appropriate switch port upon detection
Manually adding MDBs::
bridge mdb add dev br0 port sw0p1 grp 239.1.1.1 permanent vid 100
bridge mdb add dev br0 port sw0p1 grp 239.1.1.1 permanent <---- Add on all VLANs
Multicast flooding
==================
CPU port mcast_flooding is always on
Turning flooding on/off on switch ports:
bridge link set dev sw0p1 mcast_flood on/off
Access and Trunk port
=====================
::
bridge vlan add dev sw0p1 vid 100 pvid untagged master
bridge vlan add dev sw0p2 vid 100 master
bridge vlan add dev br0 vid 100 self
ip link add link br0 name br0.100 type vlan id 100
Note. Setting PVID on Bridge device itself works only for
default VLAN (default_pvid).
linux-7.2.3/Documentation/networking/device_drivers/ethernet/ti/cpsw.rst
+587
View File
@@ -0,0 +1,587 @@
.. SPDX-License-Identifier: GPL-2.0
======================================
Texas Instruments CPSW ethernet driver
======================================
Multiqueue & CBS & MQPRIO
=========================
The cpsw has 3 CBS shapers for each external ports. This document
describes MQPRIO and CBS Qdisc offload configuration for cpsw driver
based on examples. It potentially can be used in audio video bridging
(AVB) and time sensitive networking (TSN).
The following examples were tested on AM572x EVM and BBB boards.
Test setup
==========
Under consideration two examples with AM572x EVM running cpsw driver
in dual_emac mode.
Several prerequisites:
- TX queues must be rated starting from txq0 that has highest priority
- Traffic classes are used starting from 0, that has highest priority
- CBS shapers should be used with rated queues
- The bandwidth for CBS shapers has to be set a little bit more then
potential incoming rate, thus, rate of all incoming tx queues has
to be a little less
- Real rates can differ, due to discreetness
- Map skb-priority to txq is not enough, also skb-priority to l2 prio
map has to be created with ip or vconfig tool
- Any l2/socket prio (0 - 7) for classes can be used, but for
simplicity default values are used: 3 and 2
- only 2 classes tested: A and B, but checked and can work with more,
maximum allowed 4, but only for 3 rate can be set.
Test setup for examples
=======================
::
+-------------------------------+
|--+ |
| | Workstation0 |
|E | MAC 18:03:73:66:87:42 |
+-----------------------------+ +--|t | |
| | 1 | E | | |h |./tsn_listener -d \ |
| Target board: | 0 | t |--+ |0 | 18:03:73:66:87:42 -i eth0 \|
| AM572x EVM | 0 | h | | | -s 1500 |
| | 0 | 0 | |--+ |
| Only 2 classes: |Mb +---| +-------------------------------+
| class A, class B | |
| | +---| +-------------------------------+
| | 1 | E | |--+ |
| | 0 | t | | | Workstation1 |
| | 0 | h |--+ |E | MAC 20:cf:30:85:7d:fd |
| |Mb | 1 | +--|t | |
+-----------------------------+ |h |./tsn_listener -d \ |
|0 | 20:cf:30:85:7d:fd -i eth0 \|
| | -s 1500 |
|--+ |
+-------------------------------+
Example 1: One port tx AVB configuration scheme for target board
----------------------------------------------------------------
(prints and scheme for AM572x evm, applicable for single port boards)
- tc - traffic class
- txq - transmit queue
- p - priority
- f - fifo (cpsw fifo)
- S - shaper configured
::
+------------------------------------------------------------------+ u
| +---------------+ +---------------+ +------+ +------+ | s
| | | | | | | | | | e
| | App 1 | | App 2 | | Apps | | Apps | | r
| | Class A | | Class B | | Rest | | Rest | |
| | Eth0 | | Eth0 | | Eth0 | | Eth1 | | s
| | VLAN100 | | VLAN100 | | | | | | | | p
| | 40 Mb/s | | 20 Mb/s | | | | | | | | a
| | SO_PRIORITY=3 | | SO_PRIORITY=2 | | | | | | | | c
| | | | | | | | | | | | | | e
| +---|-----------+ +---|-----------+ +---|--+ +---|--+ |
+-----|------------------|------------------|--------|-------------+
+-+ +------------+ | |
| | +-----------------+ +--+
| | | |
+---|-------|-------------|-----------------------|----------------+
| +----+ +----+ +----+ +----+ +----+ |
| | p3 | | p2 | | p1 | | p0 | | p0 | | k
| \ / \ / \ / \ / \ / | e
| \ / \ / \ / \ / \ / | r
| \/ \/ \/ \/ \/ | n
| | | | | | e
| | | +-----+ | | l
| | | | | |
| +----+ +----+ +----+ +----+ | s
| |tc0 | |tc1 | |tc2 | |tc0 | | p
| \ / \ / \ / \ / | a
| \ / \ / \ / \ / | c
| \/ \/ \/ \/ | e
| | | +-----+ | |
| | | | | | |
| | | | | | |
| | | | | | |
| +----+ +----+ +----+ +----+ +----+ |
| |txq0| |txq1| |txq2| |txq3| |txq4| |
| \ / \ / \ / \ / \ / |
| \ / \ / \ / \ / \ / |
| \/ \/ \/ \/ \/ |
| +-|------|------|------|--+ +--|--------------+ |
| | | | | | | Eth0.100 | | Eth1 | |
+---|------|------|------|------------------------|----------------+
| | | | |
p p p p |
3 2 0-1, 4-7 <- L2 priority |
| | | | |
| | | | |
+---|------|------|------|------------------------|----------------+
| | | | | |----------+ |
| +----+ +----+ +----+ +----+ +----+ |
| |dma7| |dma6| |dma5| |dma4| |dma3| |
| \ / \ / \ / \ / \ / | c
| \S / \S / \ / \ / \ / | p
| \/ \/ \/ \/ \/ | s
| | | | +----- | | w
| | | | | | |
| | | | | | | d
| +----+ +----+ +----+p p+----+ | r
| | | | | | |o o| | | i
| | f3 | | f2 | | f0 |r r| f0 | | v
| |tc0 | |tc1 | |tc2 |t t|tc0 | | e
| \CBS / \CBS / \CBS /1 2\CBS / | r
| \S / \S / \ / \ / |
| \/ \/ \/ \/ |
+------------------------------------------------------------------+
1) ::
// Add 4 tx queues, for interface Eth0, and 1 tx queue for Eth1
$ ethtool -L eth0 rx 1 tx 5
rx unmodified, ignoring
2) ::
// Check if num of queues is set correctly:
$ ethtool -l eth0
Channel parameters for eth0:
Pre-set maximums:
RX: 8
TX: 8
Other: 0
Combined: 0
Current hardware settings:
RX: 1
TX: 5
Other: 0
Combined: 0
3) ::
// TX queues must be rated starting from 0, so set bws for tx0 and tx1
// Set rates 40 and 20 Mb/s appropriately.
// Pay attention, real speed can differ a bit due to discreetness.
// Leave last 2 tx queues not rated.
$ echo 40 > /sys/class/net/eth0/queues/tx-0/tx_maxrate
$ echo 20 > /sys/class/net/eth0/queues/tx-1/tx_maxrate
4) ::
// Check maximum rate of tx (cpdma) queues:
$ cat /sys/class/net/eth0/queues/tx-*/tx_maxrate
40
20
0
0
0
5) ::
// Map skb->priority to traffic class:
// 3pri -> tc0, 2pri -> tc1, (0,1,4-7)pri -> tc2
// Map traffic class to transmit queue:
// tc0 -> txq0, tc1 -> txq1, tc2 -> (txq2, txq3)
$ tc qdisc replace dev eth0 handle 100: parent root mqprio num_tc 3 \
map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 queues 1@0 1@1 2@2 hw 1
5a) ::
// As two interface sharing same set of tx queues, assign all traffic
// coming to interface Eth1 to separate queue in order to not mix it
// with traffic from interface Eth0, so use separate txq to send
// packets to Eth1, so all prio -> tc0 and tc0 -> txq4
// Here hw 0, so here still default configuration for eth1 in hw
$ tc qdisc replace dev eth1 handle 100: parent root mqprio num_tc 1 \
map 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 queues 1@4 hw 0
6) ::
// Check classes settings
$ tc -g class show dev eth0
+---(100:ffe2) mqprio
| +---(100:3) mqprio
| +---(100:4) mqprio
|
+---(100:ffe1) mqprio
| +---(100:2) mqprio
|
+---(100:ffe0) mqprio
+---(100:1) mqprio
$ tc -g class show dev eth1
+---(100:ffe0) mqprio
+---(100:5) mqprio
7) ::
// Set rate for class A - 41 Mbit (tc0, txq0) using CBS Qdisc
// Set it +1 Mb for reserve (important!)
// here only idle slope is important, others arg are ignored
// Pay attention, real speed can differ a bit due to discreetness
$ tc qdisc add dev eth0 parent 100:1 cbs locredit -1438 \
hicredit 62 sendslope -959000 idleslope 41000 offload 1
net eth0: set FIFO3 bw = 50
8) ::
// Set rate for class B - 21 Mbit (tc1, txq1) using CBS Qdisc:
// Set it +1 Mb for reserve (important!)
$ tc qdisc add dev eth0 parent 100:2 cbs locredit -1468 \
hicredit 65 sendslope -979000 idleslope 21000 offload 1
net eth0: set FIFO2 bw = 30
9) ::
// Create vlan 100 to map sk->priority to vlan qos
$ ip link add link eth0 name eth0.100 type vlan id 100
8021q: 802.1Q VLAN Support v1.8
8021q: adding VLAN 0 to HW filter on device eth0
8021q: adding VLAN 0 to HW filter on device eth1
net eth0: Adding vlanid 100 to vlan filter
10) ::
// Map skb->priority to L2 prio, 1 to 1
$ ip link set eth0.100 type vlan \
egress 0:0 1:1 2:2 3:3 4:4 5:5 6:6 7:7
11) ::
// Check egress map for vlan 100
$ cat /proc/net/vlan/eth0.100
[...]
INGRESS priority mappings: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0
EGRESS priority mappings: 0:0 1:1 2:2 3:3 4:4 5:5 6:6 7:7
12) ::
// Run your appropriate tools with socket option "SO_PRIORITY"
// to 3 for class A and/or to 2 for class B
// (I took at https://lore.kernel.org/r/20171017010128.22141-1-vinicius.gomes@intel.com/)
./tsn_talker -d 18:03:73:66:87:42 -i eth0.100 -p3 -s 1500&
./tsn_talker -d 18:03:73:66:87:42 -i eth0.100 -p2 -s 1500&
13) ::
// run your listener on workstation (should be in same vlan)
// (I took at https://lore.kernel.org/r/20171017010128.22141-1-vinicius.gomes@intel.com/)
./tsn_listener -d 18:03:73:66:87:42 -i enp5s0 -s 1500
Receiving data rate: 39012 kbps
Receiving data rate: 39012 kbps
Receiving data rate: 39012 kbps
Receiving data rate: 39012 kbps
Receiving data rate: 39012 kbps
Receiving data rate: 39012 kbps
Receiving data rate: 39012 kbps
Receiving data rate: 39012 kbps
Receiving data rate: 39012 kbps
Receiving data rate: 39012 kbps
Receiving data rate: 39012 kbps
Receiving data rate: 39012 kbps
Receiving data rate: 39000 kbps
14) ::
// Restore default configuration if needed
$ ip link del eth0.100
$ tc qdisc del dev eth1 root
$ tc qdisc del dev eth0 root
net eth0: Prev FIFO2 is shaped
net eth0: set FIFO3 bw = 0
net eth0: set FIFO2 bw = 0
$ ethtool -L eth0 rx 1 tx 1
Example 2: Two port tx AVB configuration scheme for target board
----------------------------------------------------------------
(prints and scheme for AM572x evm, for dual emac boards only)
::
+------------------------------------------------------------------+ u
| +----------+ +----------+ +------+ +----------+ +----------+ | s
| | | | | | | | | | | | e
| | App 1 | | App 2 | | Apps | | App 3 | | App 4 | | r
| | Class A | | Class B | | Rest | | Class B | | Class A | |
| | Eth0 | | Eth0 | | | | | Eth1 | | Eth1 | | s
| | VLAN100 | | VLAN100 | | | | | VLAN100 | | VLAN100 | | p
| | 40 Mb/s | | 20 Mb/s | | | | | 10 Mb/s | | 30 Mb/s | | a
| | SO_PRI=3 | | SO_PRI=2 | | | | | SO_PRI=3 | | SO_PRI=2 | | c
| | | | | | | | | | | | | | | | | e
| +---|------+ +---|------+ +---|--+ +---|------+ +---|------+ |
+-----|-------------|-------------|---------|-------------|--------+
+-+ +-------+ | +----------+ +----+
| | +-------+------+ | |
| | | | | |
+---|-------|-------------|--------------|-------------|-------|---+
| +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ |
| | p3 | | p2 | | p1 | | p0 | | p0 | | p1 | | p2 | | p3 | | k
| \ / \ / \ / \ / \ / \ / \ / \ / | e
| \ / \ / \ / \ / \ / \ / \ / \ / | r
| \/ \/ \/ \/ \/ \/ \/ \/ | n
| | | | | | | | e
| | | +----+ +----+ | | | l
| | | | | | | |
| +----+ +----+ +----+ +----+ +----+ +----+ | s
| |tc0 | |tc1 | |tc2 | |tc2 | |tc1 | |tc0 | | p
| \ / \ / \ / \ / \ / \ / | a
| \ / \ / \ / \ / \ / \ / | c
| \/ \/ \/ \/ \/ \/ | e
| | | +-----+ +-----+ | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | E E | | | | |
| +----+ +----+ +----+ +----+ t t +----+ +----+ +----+ +----+ |
| |txq0| |txq1| |txq4| |txq5| h h |txq6| |txq7| |txq3| |txq2| |
| \ / \ / \ / \ / 0 1 \ / \ / \ / \ / |
| \ / \ / \ / \ / . . \ / \ / \ / \ / |
| \/ \/ \/ \/ 1 1 \/ \/ \/ \/ |
| +-|------|------|------|--+ 0 0 +-|------|------|------|--+ |
| | | | | | | 0 0 | | | | | | |
+---|------|------|------|---------------|------|------|------|----+
| | | | | | | |
p p p p p p p p
3 2 0-1, 4-7 <-L2 pri-> 0-1, 4-7 2 3
| | | | | | | |
| | | | | | | |
+---|------|------|------|---------------|------|------|------|----+
| | | | | | | | | |
| +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ |
| |dma7| |dma6| |dma3| |dma2| |dma1| |dma0| |dma4| |dma5| |
| \ / \ / \ / \ / \ / \ / \ / \ / | c
| \S / \S / \ / \ / \ / \ / \S / \S / | p
| \/ \/ \/ \/ \/ \/ \/ \/ | s
| | | | +----- | | | | | w
| | | | | +----+ | | | |
| | | | | | | | | | d
| +----+ +----+ +----+p p+----+ +----+ +----+ | r
| | | | | | |o o| | | | | | | i
| | f3 | | f2 | | f0 |r CPSW r| f3 | | f2 | | f0 | | v
| |tc0 | |tc1 | |tc2 |t t|tc0 | |tc1 | |tc2 | | e
| \CBS / \CBS / \CBS /1 2\CBS / \CBS / \CBS / | r
| \S / \S / \ / \S / \S / \ / |
| \/ \/ \/ \/ \/ \/ |
+------------------------------------------------------------------+
========================================Eth==========================>
1) ::
// Add 8 tx queues, for interface Eth0, but they are common, so are accessed
// by two interfaces Eth0 and Eth1.
$ ethtool -L eth1 rx 1 tx 8
rx unmodified, ignoring
2) ::
// Check if num of queues is set correctly:
$ ethtool -l eth0
Channel parameters for eth0:
Pre-set maximums:
RX: 8
TX: 8
Other: 0
Combined: 0
Current hardware settings:
RX: 1
TX: 8
Other: 0
Combined: 0
3) ::
// TX queues must be rated starting from 0, so set bws for tx0 and tx1 for Eth0
// and for tx2 and tx3 for Eth1. That is, rates 40 and 20 Mb/s appropriately
// for Eth0 and 30 and 10 Mb/s for Eth1.
// Real speed can differ a bit due to discreetness
// Leave last 4 tx queues as not rated
$ echo 40 > /sys/class/net/eth0/queues/tx-0/tx_maxrate
$ echo 20 > /sys/class/net/eth0/queues/tx-1/tx_maxrate
$ echo 30 > /sys/class/net/eth1/queues/tx-2/tx_maxrate
$ echo 10 > /sys/class/net/eth1/queues/tx-3/tx_maxrate
4) ::
// Check maximum rate of tx (cpdma) queues:
$ cat /sys/class/net/eth0/queues/tx-*/tx_maxrate
40
20
30
10
0
0
0
0
5) ::
// Map skb->priority to traffic class for Eth0:
// 3pri -> tc0, 2pri -> tc1, (0,1,4-7)pri -> tc2
// Map traffic class to transmit queue:
// tc0 -> txq0, tc1 -> txq1, tc2 -> (txq4, txq5)
$ tc qdisc replace dev eth0 handle 100: parent root mqprio num_tc 3 \
map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 queues 1@0 1@1 2@4 hw 1
6) ::
// Check classes settings
$ tc -g class show dev eth0
+---(100:ffe2) mqprio
| +---(100:5) mqprio
| +---(100:6) mqprio
|
+---(100:ffe1) mqprio
| +---(100:2) mqprio
|
+---(100:ffe0) mqprio
+---(100:1) mqprio
7) ::
// Set rate for class A - 41 Mbit (tc0, txq0) using CBS Qdisc for Eth0
// here only idle slope is important, others ignored
// Real speed can differ a bit due to discreetness
$ tc qdisc add dev eth0 parent 100:1 cbs locredit -1470 \
hicredit 62 sendslope -959000 idleslope 41000 offload 1
net eth0: set FIFO3 bw = 50
8) ::
// Set rate for class B - 21 Mbit (tc1, txq1) using CBS Qdisc for Eth0
$ tc qdisc add dev eth0 parent 100:2 cbs locredit -1470 \
hicredit 65 sendslope -979000 idleslope 21000 offload 1
net eth0: set FIFO2 bw = 30
9) ::
// Create vlan 100 to map sk->priority to vlan qos for Eth0
$ ip link add link eth0 name eth0.100 type vlan id 100
net eth0: Adding vlanid 100 to vlan filter
10) ::
// Map skb->priority to L2 prio for Eth0.100, one to one
$ ip link set eth0.100 type vlan \
egress 0:0 1:1 2:2 3:3 4:4 5:5 6:6 7:7
11) ::
// Check egress map for vlan 100
$ cat /proc/net/vlan/eth0.100
[...]
INGRESS priority mappings: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0
EGRESS priority mappings: 0:0 1:1 2:2 3:3 4:4 5:5 6:6 7:7
12) ::
// Map skb->priority to traffic class for Eth1:
// 3pri -> tc0, 2pri -> tc1, (0,1,4-7)pri -> tc2
// Map traffic class to transmit queue:
// tc0 -> txq2, tc1 -> txq3, tc2 -> (txq6, txq7)
$ tc qdisc replace dev eth1 handle 100: parent root mqprio num_tc 3 \
map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 queues 1@2 1@3 2@6 hw 1
13) ::
// Check classes settings
$ tc -g class show dev eth1
+---(100:ffe2) mqprio
| +---(100:7) mqprio
| +---(100:8) mqprio
|
+---(100:ffe1) mqprio
| +---(100:4) mqprio
|
+---(100:ffe0) mqprio
+---(100:3) mqprio
14) ::
// Set rate for class A - 31 Mbit (tc0, txq2) using CBS Qdisc for Eth1
// here only idle slope is important, others ignored, but calculated
// for interface speed - 100Mb for eth1 port.
// Set it +1 Mb for reserve (important!)
$ tc qdisc add dev eth1 parent 100:3 cbs locredit -1035 \
hicredit 465 sendslope -69000 idleslope 31000 offload 1
net eth1: set FIFO3 bw = 31
15) ::
// Set rate for class B - 11 Mbit (tc1, txq3) using CBS Qdisc for Eth1
// Set it +1 Mb for reserve (important!)
$ tc qdisc add dev eth1 parent 100:4 cbs locredit -1335 \
hicredit 405 sendslope -89000 idleslope 11000 offload 1
net eth1: set FIFO2 bw = 11
16) ::
// Create vlan 100 to map sk->priority to vlan qos for Eth1
$ ip link add link eth1 name eth1.100 type vlan id 100
net eth1: Adding vlanid 100 to vlan filter
17) ::
// Map skb->priority to L2 prio for Eth1.100, one to one
$ ip link set eth1.100 type vlan \
egress 0:0 1:1 2:2 3:3 4:4 5:5 6:6 7:7
18) ::
// Check egress map for vlan 100
$ cat /proc/net/vlan/eth1.100
[...]
INGRESS priority mappings: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0
EGRESS priority mappings: 0:0 1:1 2:2 3:3 4:4 5:5 6:6 7:7
19) ::
// Run appropriate tools with socket option "SO_PRIORITY" to 3
// for class A and to 2 for class B. For both interfaces
./tsn_talker -d 18:03:73:66:87:42 -i eth0.100 -p2 -s 1500&
./tsn_talker -d 18:03:73:66:87:42 -i eth0.100 -p3 -s 1500&
./tsn_talker -d 20:cf:30:85:7d:fd -i eth1.100 -p2 -s 1500&
./tsn_talker -d 20:cf:30:85:7d:fd -i eth1.100 -p3 -s 1500&
20) ::
// run your listener on workstation (should be in same vlan)
// (I took at https://lore.kernel.org/r/20171017010128.22141-1-vinicius.gomes@intel.com/)
./tsn_listener -d 18:03:73:66:87:42 -i enp5s0 -s 1500
Receiving data rate: 39012 kbps
Receiving data rate: 39012 kbps
Receiving data rate: 39012 kbps
Receiving data rate: 39012 kbps
Receiving data rate: 39012 kbps
Receiving data rate: 39012 kbps
Receiving data rate: 39012 kbps
Receiving data rate: 39012 kbps
Receiving data rate: 39012 kbps
Receiving data rate: 39012 kbps
Receiving data rate: 39012 kbps
Receiving data rate: 39012 kbps
Receiving data rate: 39000 kbps
21) ::
// Restore default configuration if needed
$ ip link del eth1.100
$ ip link del eth0.100
$ tc qdisc del dev eth1 root
net eth1: Prev FIFO2 is shaped
net eth1: set FIFO3 bw = 0
net eth1: set FIFO2 bw = 0
$ tc qdisc del dev eth0 root
net eth0: Prev FIFO2 is shaped
net eth0: set FIFO3 bw = 0
net eth0: set FIFO2 bw = 0
$ ethtool -L eth0 rx 1 tx 1
linux-7.2.3/Documentation/networking/device_drivers/ethernet/ti/cpsw_switchdev.rst
+242
View File
@@ -0,0 +1,242 @@
.. SPDX-License-Identifier: GPL-2.0
======================================================
Texas Instruments CPSW switchdev based ethernet driver
======================================================
:Version: 2.0
Port renaming
=============
On older udev versions renaming of ethX to swXpY will not be automatically
supported
In order to rename via udev::
ip -d link show dev sw0p1 | grep switchid
SUBSYSTEM=="net", ACTION=="add", ATTR{phys_switch_id}==<switchid>, \
ATTR{phys_port_name}!="", NAME="sw0$attr{phys_port_name}"
Dual mac mode
=============
- The new (cpsw_new.c) driver is operating in dual-emac mode by default, thus
working as 2 individual network interfaces. Main differences from legacy CPSW
driver are:
- optimized promiscuous mode: The P0_UNI_FLOOD (both ports) is enabled in
addition to ALLMULTI (current port) instead of ALE_BYPASS.
So, Ports in promiscuous mode will keep possibility of mcast and vlan
filtering, which is provides significant benefits when ports are joined
to the same bridge, but without enabling "switch" mode, or to different
bridges.
- learning disabled on ports as it make not too much sense for
segregated ports - no forwarding in HW.
- enabled basic support for devlink.
::
devlink dev show
platform/48484000.switch
devlink dev param show
platform/48484000.switch:
name switch_mode type driver-specific
values:
cmode runtime value false
name ale_bypass type driver-specific
values:
cmode runtime value false
Devlink configuration parameters
================================
See Documentation/networking/devlink/ti-cpsw-switch.rst
Bridging in dual mac mode
=========================
The dual_mac mode requires two vids to be reserved for internal purposes,
which, by default, equal CPSW Port numbers. As result, bridge has to be
configured in vlan unaware mode or default_pvid has to be adjusted::
ip link add name br0 type bridge
ip link set dev br0 type bridge vlan_filtering 0
echo 0 > /sys/class/net/br0/bridge/default_pvid
ip link set dev sw0p1 master br0
ip link set dev sw0p2 master br0
or::
ip link add name br0 type bridge
ip link set dev br0 type bridge vlan_filtering 0
echo 100 > /sys/class/net/br0/bridge/default_pvid
ip link set dev br0 type bridge vlan_filtering 1
ip link set dev sw0p1 master br0
ip link set dev sw0p2 master br0
Enabling "switch"
=================
The Switch mode can be enabled by configuring devlink driver parameter
"switch_mode" to 1/true::
devlink dev param set platform/48484000.switch \
name switch_mode value 1 cmode runtime
This can be done regardless of the state of Port's netdev devices - UP/DOWN, but
Port's netdev devices have to be in UP before joining to the bridge to avoid
overwriting of bridge configuration as CPSW switch driver copletly reloads its
configuration when first Port changes its state to UP.
When both interfaces have joined the bridge - CPSW switch driver will enable
marking packets with offload_fwd_mark flag unless "ale_bypass=0"
All configuration is implemented via switchdev API.
Bridge setup
============
::
devlink dev param set platform/48484000.switch \
name switch_mode value 1 cmode runtime
ip link add name br0 type bridge
ip link set dev br0 type bridge ageing_time 1000
ip link set dev sw0p1 up
ip link set dev sw0p2 up
ip link set dev sw0p1 master br0
ip link set dev sw0p2 master br0
[*] bridge vlan add dev br0 vid 1 pvid untagged self
[*] if vlan_filtering=1. where default_pvid=1
Note. Steps [*] are mandatory.
On/off STP
==========
::
ip link set dev BRDEV type bridge stp_state 1/0
VLAN configuration
==================
::
bridge vlan add dev br0 vid 1 pvid untagged self <---- add cpu port to VLAN 1
Note. This step is mandatory for bridge/default_pvid.
Add extra VLANs
===============
1. untagged::
bridge vlan add dev sw0p1 vid 100 pvid untagged master
bridge vlan add dev sw0p2 vid 100 pvid untagged master
bridge vlan add dev br0 vid 100 pvid untagged self <---- Add cpu port to VLAN100
2. tagged::
bridge vlan add dev sw0p1 vid 100 master
bridge vlan add dev sw0p2 vid 100 master
bridge vlan add dev br0 vid 100 pvid tagged self <---- Add cpu port to VLAN100
FDBs
----
FDBs are automatically added on the appropriate switch port upon detection
Manually adding FDBs::
bridge fdb add aa:bb:cc:dd:ee:ff dev sw0p1 master vlan 100
bridge fdb add aa:bb:cc:dd:ee:fe dev sw0p2 master <---- Add on all VLANs
MDBs
----
MDBs are automatically added on the appropriate switch port upon detection
Manually adding MDBs::
bridge mdb add dev br0 port sw0p1 grp 239.1.1.1 permanent vid 100
bridge mdb add dev br0 port sw0p1 grp 239.1.1.1 permanent <---- Add on all VLANs
Multicast flooding
==================
CPU port mcast_flooding is always on
Turning flooding on/off on switch ports:
bridge link set dev sw0p1 mcast_flood on/off
Access and Trunk port
=====================
::
bridge vlan add dev sw0p1 vid 100 pvid untagged master
bridge vlan add dev sw0p2 vid 100 master
bridge vlan add dev br0 vid 100 self
ip link add link br0 name br0.100 type vlan id 100
Note. Setting PVID on Bridge device itself working only for
default VLAN (default_pvid).
NFS
===
The only way for NFS to work is by chrooting to a minimal environment when
switch configuration that will affect connectivity is needed.
Assuming you are booting NFS with eth1 interface(the script is hacky and
it's just there to prove NFS is doable).
setup.sh::
#!/bin/sh
mkdir proc
mount -t proc none /proc
ifconfig br0 > /dev/null
if [ $? -ne 0 ]; then
echo "Setting up bridge"
ip link add name br0 type bridge
ip link set dev br0 type bridge ageing_time 1000
ip link set dev br0 type bridge vlan_filtering 1
ip link set eth1 down
ip link set eth1 name sw0p1
ip link set dev sw0p1 up
ip link set dev sw0p2 up
ip link set dev sw0p2 master br0
ip link set dev sw0p1 master br0
bridge vlan add dev br0 vid 1 pvid untagged self
ifconfig sw0p1 0.0.0.0
udhchc -i br0
fi
umount /proc
run_nfs.sh:::
#!/bin/sh
mkdir /tmp/root/bin -p
mkdir /tmp/root/lib -p
cp -r /lib/ /tmp/root/
cp -r /bin/ /tmp/root/
cp /sbin/ip /tmp/root/bin
cp /sbin/bridge /tmp/root/bin
cp /sbin/ifconfig /tmp/root/bin
cp /sbin/udhcpc /tmp/root/bin
cp /path/to/setup.sh /tmp/root/bin
chroot /tmp/root/ busybox sh /bin/setup.sh
run ./run_nfs.sh
linux-7.2.3/Documentation/networking/device_drivers/ethernet/ti/icssg_prueth.rst
+56
View File
@@ -0,0 +1,56 @@
.. SPDX-License-Identifier: GPL-2.0
==============================================
Texas Instruments ICSSG PRUETH ethernet driver
==============================================
:Version: 1.0
ICSSG Firmware
==============
Every ICSSG core has two Programmable Real-Time Unit(PRUs), two auxiliary
Real-Time Transfer Unit (RTUs), and two Transmit Real-Time Transfer Units
(TX_PRUs). Each one of these runs its own firmware. The firmwares combnined are
referred as ICSSG Firmware.
Firmware Statistics
===================
The ICSSG firmware maintains certain statistics which are dumped by the driver
via ``ethtool -S <interface>``
These statistics are as follows,
- ``FW_RTU_PKT_DROP``: Diagnostic error counter which increments when RTU drops a locally injected packet due to port being disabled or rule violation.
- ``FW_Q0_OVERFLOW``: TX overflow counter for queue0
- ``FW_Q1_OVERFLOW``: TX overflow counter for queue1
- ``FW_Q2_OVERFLOW``: TX overflow counter for queue2
- ``FW_Q3_OVERFLOW``: TX overflow counter for queue3
- ``FW_Q4_OVERFLOW``: TX overflow counter for queue4
- ``FW_Q5_OVERFLOW``: TX overflow counter for queue5
- ``FW_Q6_OVERFLOW``: TX overflow counter for queue6
- ``FW_Q7_OVERFLOW``: TX overflow counter for queue7
- ``FW_DROPPED_PKT``: This counter is incremented when a packet is dropped at PRU because of rule violation.
- ``FW_RX_ERROR``: Incremented if there was a CRC error or Min/Max frame error at PRU
- ``FW_RX_DS_INVALID``: Incremented when RTU detects Data Status invalid condition
- ``FW_TX_DROPPED_PACKET``: Counter for packets dropped via TX Port
- ``FW_TX_TS_DROPPED_PACKET``: Counter for packets with TS flag dropped via TX Port
- ``FW_INF_PORT_DISABLED``: Incremented when RX frame is dropped due to port being disabled
- ``FW_INF_SAV``: Incremented when RX frame is dropped due to Source Address violation
- ``FW_INF_SA_DL``: Incremented when RX frame is dropped due to Source Address being in the denylist
- ``FW_INF_PORT_BLOCKED``: Incremented when RX frame is dropped due to port being blocked and frame being a special frame
- ``FW_INF_DROP_TAGGED`` : Incremented when RX frame is dropped for being tagged
- ``FW_INF_DROP_PRIOTAGGED``: Incremented when RX frame is dropped for being priority tagged
- ``FW_INF_DROP_NOTAG``: Incremented when RX frame is dropped for being untagged
- ``FW_INF_DROP_NOTMEMBER``: Incremented when RX frame is dropped for port not being member of VLAN
- ``FW_RX_EOF_SHORT_FRMERR``: Incremented if End Of Frame (EOF) task is scheduled without seeing RX_B1
- ``FW_RX_B0_DROP_EARLY_EOF``: Incremented when frame is dropped due to Early EOF
- ``FW_TX_JUMBO_FRM_CUTOFF``: Incremented when frame is cut off to prevent packet size > 2000 Bytes
- ``FW_RX_EXP_FRAG_Q_DROP``: Incremented when express frame is received in the same queue as the previous fragment
- ``FW_RX_FIFO_OVERRUN``: RX fifo overrun counter
- ``FW_CUT_THR_PKT``: Incremented when a packet is forwarded using Cut-Through forwarding method
- ``FW_HOST_RX_PKT_CNT``: Number of valid packets sent by Rx PRU to Host on PSI
- ``FW_HOST_TX_PKT_CNT``: Number of valid packets copied by RTU0 to Tx queues
- ``FW_HOST_EGRESS_Q_PRE_OVERFLOW``: Host Egress Q (Pre-emptible) Overflow Counter
- ``FW_HOST_EGRESS_Q_EXP_OVERFLOW``: Host Egress Q (Pre-emptible) Overflow Counter
linux-7.2.3/Documentation/networking/device_drivers/ethernet/ti/tlan.rst
+140
View File
@@ -0,0 +1,140 @@
.. SPDX-License-Identifier: GPL-2.0
=====================
TLAN driver for Linux
=====================
:Version: 1.14a
(C) 1997-1998 Caldera, Inc.
(C) 1998 James Banks
(C) 1999-2001 Torben Mathiasen <tmm@image.dk, torben.mathiasen@compaq.com>
For driver information/updates visit http://www.compaq.com
I. Supported Devices
====================
Only PCI devices will work with this driver.
Supported:
========= ========= ===========================================
Vendor ID Device ID Name
========= ========= ===========================================
0e11 ae32 Compaq Netelligent 10/100 TX PCI UTP
0e11 ae34 Compaq Netelligent 10 T PCI UTP
0e11 ae35 Compaq Integrated NetFlex 3/P
0e11 ae40 Compaq Netelligent Dual 10/100 TX PCI UTP
0e11 ae43 Compaq Netelligent Integrated 10/100 TX UTP
0e11 b011 Compaq Netelligent 10/100 TX Embedded UTP
0e11 b012 Compaq Netelligent 10 T/2 PCI UTP/Coax
0e11 b030 Compaq Netelligent 10/100 TX UTP
0e11 f130 Compaq NetFlex 3/P
0e11 f150 Compaq NetFlex 3/P
108d 0012 Olicom OC-2325
108d 0013 Olicom OC-2183
108d 0014 Olicom OC-2326
========= ========= ===========================================
Caveats:
I am not sure if 100BaseTX daughterboards (for those cards which
support such things) will work. I haven't had any solid evidence
either way.
However, if a card supports 100BaseTx without requiring an add
on daughterboard, it should work with 100BaseTx.
The "Netelligent 10 T/2 PCI UTP/Coax" (b012) device is untested,
but I do not expect any problems.
II. Driver Options
==================
1. You can append debug=x to the end of the insmod line to get
debug messages, where x is a bit field where the bits mean
the following:
==== =====================================
0x01 Turn on general debugging messages.
0x02 Turn on receive debugging messages.
0x04 Turn on transmit debugging messages.
0x08 Turn on list debugging messages.
==== =====================================
2. You can append aui=1 to the end of the insmod line to cause
the adapter to use the AUI interface instead of the 10 Base T
interface. This is also what to do if you want to use the BNC
connector on a TLAN based device. (Setting this option on a
device that does not have an AUI/BNC connector will probably
cause it to not function correctly.)
3. You can set duplex=1 to force half duplex, and duplex=2 to
force full duplex.
4. You can set speed=10 to force 10Mbs operation, and speed=100
to force 100Mbs operation. (I'm not sure what will happen
if a card which only supports 10Mbs is forced into 100Mbs
mode.)
5. You have to use speed=X duplex=Y together now. If you just
do "insmod tlan.o speed=100" the driver will do Auto-Neg.
To force a 10Mbps Half-Duplex link do "insmod tlan.o speed=10
duplex=1".
6. If the driver is built into the kernel, you can use the 3rd
and 4th parameters to set aui and debug respectively. For
example::
ether=0,0,0x1,0x7,eth0
This sets aui to 0x1 and debug to 0x7, assuming eth0 is a
supported TLAN device.
The bits in the third byte are assigned as follows:
==== ===============
0x01 aui
0x02 use half duplex
0x04 use full duplex
0x08 use 10BaseT
0x10 use 100BaseTx
==== ===============
You also need to set both speed and duplex settings when forcing
speeds with kernel-parameters.
ether=0,0,0x12,0,eth0 will force link to 100Mbps Half-Duplex.
7. If you have more than one tlan adapter in your system, you can
use the above options on a per adapter basis. To force a 100Mbit/HD
link with your eth1 adapter use::
insmod tlan speed=0,100 duplex=0,1
Now eth0 will use auto-neg and eth1 will be forced to 100Mbit/HD.
Note that the tlan driver supports a maximum of 8 adapters.
III. Things to try if you have problems
=======================================
1. Make sure your card's PCI id is among those listed in
section I, above.
2. Make sure routing is correct.
3. Try forcing different speed/duplex settings
There is also a tlan mailing list which you can join by sending "subscribe tlan"
in the body of an email to majordomo@vuser.vu.union.edu.
There is also a tlan website at http://www.compaq.com
linux-7.2.3/Documentation/networking/device_drivers/ethernet/wangxun/ngbe.rst
+14
View File
@@ -0,0 +1,14 @@
.. SPDX-License-Identifier: GPL-2.0
=============================================================
Linux Base Driver for WangXun(R) Gigabit PCI Express Adapters
=============================================================
WangXun Gigabit Linux driver.
Copyright (c) 2019 - 2022 Beijing WangXun Technology Co., Ltd.
Support
=======
If you have problems with the software or hardware, please contact our
customer support team via email at nic-support@net-swift.com or check our website
at https://www.net-swift.com
linux-7.2.3/Documentation/networking/device_drivers/ethernet/wangxun/ngbevf.rst
+16
View File
@@ -0,0 +1,16 @@
.. SPDX-License-Identifier: GPL-2.0+
==================================================================
Linux Base Virtual Function Driver for Wangxun(R) Gigabit Ethernet
==================================================================
WangXun Gigabit Virtual Function Linux driver.
Copyright(c) 2015 - 2025 Beijing WangXun Technology Co., Ltd.
Support
=======
For general information, go to the website at:
https://www.net-swift.com
If you got any problem, contact Wangxun support team via nic-support@net-swift.com
and Cc: netdev.
linux-7.2.3/Documentation/networking/device_drivers/ethernet/wangxun/txgbe.rst
+20
View File
@@ -0,0 +1,20 @@
.. SPDX-License-Identifier: GPL-2.0
================================================================
Linux Base Driver for WangXun(R) 10 Gigabit PCI Express Adapters
================================================================
WangXun 10 Gigabit Linux driver.
Copyright (c) 2015 - 2022 Beijing WangXun Technology Co., Ltd.
Contents
========
- Support
Support
=======
If you got any problem, contact Wangxun support team via nic-support@net-swift.com
and Cc: netdev.
linux-7.2.3/Documentation/networking/device_drivers/ethernet/wangxun/txgbevf.rst
+16
View File
@@ -0,0 +1,16 @@
.. SPDX-License-Identifier: GPL-2.0+
===========================================================================
Linux Base Virtual Function Driver for Wangxun(R) 10/25/40 Gigabit Ethernet
===========================================================================
WangXun 10/25/40 Gigabit Virtual Function Linux driver.
Copyright(c) 2015 - 2025 Beijing WangXun Technology Co., Ltd.
Support
=======
For general information, go to the website at:
https://www.net-swift.com
If you got any problem, contact Wangxun support team via nic-support@net-swift.com
and Cc: netdev.
linux-7.2.3/Documentation/networking/device_drivers/fddi/defza.rst
+63
View File
@@ -0,0 +1,63 @@
.. SPDX-License-Identifier: GPL-2.0
=====================================================
Notes on the DEC FDDIcontroller 700 (DEFZA-xx) driver
=====================================================
:Version: v.1.1.4
DEC FDDIcontroller 700 is DEC's first-generation TURBOchannel FDDI
network card, designed in 1990 specifically for the DECstation 5000
model 200 workstation. The board is a single attachment station and
it was manufactured in two variations, both of which are supported.
First is the SAS MMF DEFZA-AA option, the original design implementing
the standard MMF-PMD, however with a pair of ST connectors rather than
the usual MIC connector. The other one is the SAS ThinWire/STP DEFZA-CA
option, denoted 700-C, with the network medium selectable by a switch
between the DEC proprietary ThinWire-PMD using a BNC connector and the
standard STP-PMD using a DE-9F connector. This option can interface to
a DECconcentrator 500 device and, in the case of the STP-PMD, also other
FDDI equipment and was designed to make it easier to transition from
existing IEEE 802.3 10BASE2 Ethernet and IEEE 802.5 Token Ring networks
by providing means to reuse existing cabling.
This driver handles any number of cards installed in a single system.
They get fddi0, fddi1, etc. interface names assigned in the order of
increasing TURBOchannel slot numbers.
The board only supports DMA on the receive side. Transmission involves
the use of PIO. As a result under a heavy transmission load there will
be a significant impact on system performance.
The board supports a 64-entry CAM for matching destination addresses.
Two entries are preoccupied by the Directed Beacon and Ring Purger
multicast addresses and the rest is used as a multicast filter. An
all-multi mode is also supported for LLC frames and it is used if
requested explicitly or if the CAM overflows. The promiscuous mode
supports separate enables for LLC and SMT frames, but this driver
doesn't support changing them individually.
Known problems:
None.
To do:
5. MAC address change. The card does not support changing the Media
Access Controller's address registers but a similar effect can be
achieved by adding an alias to the CAM. There is no way to disable
matching against the original address though.
7. Queueing incoming/outgoing SMT frames in the driver if the SMT
receive/RMC transmit ring is full. (?)
8. Retrieving/reporting FDDI/SNMP stats.
Both success and failure reports are welcome.
Maciej W. Rozycki <macro@orcam.me.uk>
linux-7.2.3/Documentation/networking/device_drivers/fddi/index.rst
+12
View File
@@ -0,0 +1,12 @@
.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
Fiber Distributed Data Interface (FDDI) Device Drivers
======================================================
Contents:
.. toctree::
:maxdepth: 2
defza
skfp
linux-7.2.3/Documentation/networking/device_drivers/fddi/skfp.rst
+253
View File
@@ -0,0 +1,253 @@
.. SPDX-License-Identifier: GPL-2.0
.. include:: <isonum.txt>
========================
SysKonnect driver - SKFP
========================
|copy| Copyright 1998-2000 SysKonnect,
skfp.txt created 11-May-2000
Readme File for skfp.o v2.06
.. This file contains
(1) OVERVIEW
(2) SUPPORTED ADAPTERS
(3) GENERAL INFORMATION
(4) INSTALLATION
(5) INCLUSION OF THE ADAPTER IN SYSTEM START
(6) TROUBLESHOOTING
(7) FUNCTION OF THE ADAPTER LEDS
(8) HISTORY
1. Overview
===========
This README explains how to use the driver 'skfp' for Linux with your
network adapter.
Chapter 2: Contains a list of all network adapters that are supported by
this driver.
Chapter 3:
Gives some general information.
Chapter 4: Describes common problems and solutions.
Chapter 5: Shows the changed functionality of the adapter LEDs.
Chapter 6: History of development.
2. Supported adapters
=====================
The network driver 'skfp' supports the following network adapters:
SysKonnect adapters:
- SK-5521 (SK-NET FDDI-UP)
- SK-5522 (SK-NET FDDI-UP DAS)
- SK-5541 (SK-NET FDDI-FP)
- SK-5543 (SK-NET FDDI-LP)
- SK-5544 (SK-NET FDDI-LP DAS)
- SK-5821 (SK-NET FDDI-UP64)
- SK-5822 (SK-NET FDDI-UP64 DAS)
- SK-5841 (SK-NET FDDI-FP64)
- SK-5843 (SK-NET FDDI-LP64)
- SK-5844 (SK-NET FDDI-LP64 DAS)
Compaq adapters (not tested):
- Netelligent 100 FDDI DAS Fibre SC
- Netelligent 100 FDDI SAS Fibre SC
- Netelligent 100 FDDI DAS UTP
- Netelligent 100 FDDI SAS UTP
- Netelligent 100 FDDI SAS Fibre MIC
3. General Information
======================
From v2.01 on, the driver is integrated in the linux kernel sources.
Therefore, the installation is the same as for any other adapter
supported by the kernel.
Refer to the manual of your distribution about the installation
of network adapters.
Makes my life much easier :-)
4. Troubleshooting
==================
If you run into problems during installation, check those items:
Problem:
The FDDI adapter cannot be found by the driver.
Reason:
Look in /proc/pci for the following entry:
'FDDI network controller: SysKonnect SK-FDDI-PCI ...'
If this entry exists, then the FDDI adapter has been
found by the system and should be able to be used.
If this entry does not exist or if the file '/proc/pci'
is not there, then you may have a hardware problem or PCI
support may not be enabled in your kernel.
The adapter can be checked using the diagnostic program
which is available from the SysKonnect web site:
www.syskonnect.de
Some COMPAQ machines have a problem with PCI under
Linux. This is described in the 'PCI howto' document
(included in some distributions or available from the
www, e.g. at 'www.linux.org') and no workaround is available.
Problem:
You want to use your computer as a router between
multiple IP subnetworks (using multiple adapters), but
you cannot reach computers in other subnetworks.
Reason:
Either the router's kernel is not configured for IP
forwarding or there is a problem with the routing table
and gateway configuration in at least one of the
computers.
If your problem is not listed here, please contact our
technical support for help.
You can send email to: linux@syskonnect.de
When contacting our technical support,
please ensure that the following information is available:
- System Manufacturer and Model
- Boards in your system
- Distribution
- Kernel version
5. Function of the Adapter LEDs
===============================
The functionality of the LED's on the FDDI network adapters was
changed in SMT version v2.82. With this new SMT version, the yellow
LED works as a ring operational indicator. An active yellow LED
indicates that the ring is down. The green LED on the adapter now
works as a link indicator where an active GREEN LED indicates that
the respective port has a physical connection.
With versions of SMT prior to v2.82 a ring up was indicated if the
yellow LED was off while the green LED(s) showed the connection
status of the adapter. During a ring down the green LED was off and
the yellow LED was on.
All implementations indicate that a driver is not loaded if
all LEDs are off.
6. History
==========
v2.06 (20000511) (In-Kernel version)
New features:
- 64 bit support
- new pci dma interface
- in kernel 2.3.99
v2.05 (20000217) (In-Kernel version)
New features:
- Changes for 2.3.45 kernel
v2.04 (20000207) (Standalone version)
New features:
- Added rx/tx byte counter
v2.03 (20000111) (Standalone version)
Problems fixed:
- Fixed printk statements from v2.02
v2.02 (991215) (Standalone version)
Problems fixed:
- Removed unnecessary output
- Fixed path for "printver.sh" in makefile
v2.01 (991122) (In-Kernel version)
New features:
- Integration in Linux kernel sources
- Support for memory mapped I/O.
v2.00 (991112)
New features:
- Full source released under GPL
v1.05 (991023)
Problems fixed:
- Compilation with kernel version 2.2.13 failed
v1.04 (990427)
Changes:
- New SMT module included, changing LED functionality
Problems fixed:
- Synchronization on SMP machines was buggy
v1.03 (990325)
Problems fixed:
- Interrupt routing on SMP machines could be incorrect
v1.02 (990310)
New features:
- Support for kernel versions 2.2.x added
- Kernel patch instead of private duplicate of kernel functions
v1.01 (980812)
Problems fixed:
Connection hangup with telnet
Slow telnet connection
v1.00 beta 01 (980507)
New features:
None.
Problems fixed:
None.
Known limitations:
- tar archive instead of standard package format (rpm).
- FDDI statistic is empty.
- not tested with 2.1.xx kernels
- integration in kernel not tested
- not tested simultaneously with FDDI adapters from other vendors.
- only X86 processors supported.
- SBA (Synchronous Bandwidth Allocator) parameters can
not be configured.
- does not work on some COMPAQ machines. See the PCI howto
document for details about this problem.
- data corruption with kernel versions below 2.0.33.
linux-7.2.3/Documentation/networking/device_drivers/index.rst
+17
View File
@@ -0,0 +1,17 @@
.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
Hardware Device Drivers
=======================
Contents:
.. toctree::
:maxdepth: 2
atm/index
can/index
cellular/index
ethernet/index
fddi/index
wifi/index
wwan/index
linux-7.2.3/Documentation/networking/device_drivers/wifi/index.rst
+12
View File
@@ -0,0 +1,12 @@
.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
Wi-Fi Device Drivers
====================
Contents:
.. toctree::
:maxdepth: 2
intel/ipw2100
intel/ipw2200
linux-7.2.3/Documentation/networking/device_drivers/wifi/intel/ipw2100.rst
+323
View File
@@ -0,0 +1,323 @@
.. SPDX-License-Identifier: GPL-2.0
.. include:: <isonum.txt>
===========================================
Intel(R) PRO/Wireless 2100 Driver for Linux
===========================================
Support for:
- Intel(R) PRO/Wireless 2100 Network Connection
Copyright |copy| 2003-2006, Intel Corporation
README.ipw2100
:Version: git-1.1.5
:Date: January 25, 2006
.. Index
0. IMPORTANT INFORMATION BEFORE USING THIS DRIVER
1. Introduction
2. Release git-1.1.5 Current Features
3. Command Line Parameters
4. Sysfs Helper Files
5. Radio Kill Switch
6. Dynamic Firmware
7. Power Management
8. Support
9. License
0. IMPORTANT INFORMATION BEFORE USING THIS DRIVER
=================================================
Important Notice FOR ALL USERS OR DISTRIBUTORS!!!!
Intel wireless LAN adapters are engineered, manufactured, tested, and
quality checked to ensure that they meet all necessary local and
governmental regulatory agency requirements for the regions that they
are designated and/or marked to ship into. Since wireless LANs are
generally unlicensed devices that share spectrum with radars,
satellites, and other licensed and unlicensed devices, it is sometimes
necessary to dynamically detect, avoid, and limit usage to avoid
interference with these devices. In many instances Intel is required to
provide test data to prove regional and local compliance to regional and
governmental regulations before certification or approval to use the
product is granted. Intel's wireless LAN's EEPROM, firmware, and
software driver are designed to carefully control parameters that affect
radio operation and to ensure electromagnetic compliance (EMC). These
parameters include, without limitation, RF power, spectrum usage,
channel scanning, and human exposure.
For these reasons Intel cannot permit any manipulation by third parties
of the software provided in binary format with the wireless WLAN
adapters (e.g., the EEPROM and firmware). Furthermore, if you use any
patches, utilities, or code with the Intel wireless LAN adapters that
have been manipulated by an unauthorized party (i.e., patches,
utilities, or code (including open source code modifications) which have
not been validated by Intel), (i) you will be solely responsible for
ensuring the regulatory compliance of the products, (ii) Intel will bear
no liability, under any theory of liability for any issues associated
with the modified products, including without limitation, claims under
the warranty and/or issues arising from regulatory non-compliance, and
(iii) Intel will not provide or be required to assist in providing
support to any third parties for such modified products.
Note: Many regulatory agencies consider Wireless LAN adapters to be
modules, and accordingly, condition system-level regulatory approval
upon receipt and review of test data documenting that the antennas and
system configuration do not cause the EMC and radio operation to be
non-compliant.
The drivers available for download from SourceForge are provided as a
part of a development project. Conformance to local regulatory
requirements is the responsibility of the individual developer. As
such, if you are interested in deploying or shipping a driver as part of
solution intended to be used for purposes other than development, please
obtain a tested driver from Intel Customer Support at:
https://www.intel.com/support/wireless/sb/CS-006408.htm
1. Introduction
===============
This document provides a brief overview of the features supported by the
IPW2100 driver project. The main project website, where the latest
development version of the driver can be found, is:
http://ipw2100.sourceforge.net
There you can find the not only the latest releases, but also information about
potential fixes and patches, as well as links to the development mailing list
for the driver project.
2. Release git-1.1.5 Current Supported Features
===============================================
- Managed (BSS) and Ad-Hoc (IBSS)
- WEP (shared key and open)
- Wireless Tools support
- 802.1x (tested with XSupplicant 1.0.1)
Enabled (but not supported) features:
- Monitor/RFMon mode
- WPA/WPA2
The distinction between officially supported and enabled is a reflection
on the amount of validation and interoperability testing that has been
performed on a given feature.
3. Command Line Parameters
==========================
If the driver is built as a module, the following optional parameters are used
by entering them on the command line with the modprobe command using this
syntax::
modprobe ipw2100 [<option>=<VAL1><,VAL2>...]
For example, to disable the radio on driver loading, enter:
modprobe ipw2100 disable=1
The ipw2100 driver supports the following module parameters:
========= ============== ============ ==============================
Name Value Example Meaning
========= ============== ============ ==============================
debug 0x0-0xffffffff debug=1024 Debug level set to 1024
mode 0,1,2 mode=1 AdHoc
channel int channel=3 Only valid in AdHoc or Monitor
associate boolean associate=0 Do NOT auto associate
disable boolean disable=1 Do not power the HW
========= ============== ============ ==============================
4. Sysfs Helper Files
=====================
There are several ways to control the behavior of the driver. Many of the
general capabilities are exposed through the Wireless Tools (iwconfig). There
are a few capabilities that are exposed through entries in the Linux Sysfs.
**Driver Level**
For the driver level files, look in /sys/bus/pci/drivers/ipw2100/
debug_level
This controls the same global as the 'debug' module parameter. For
information on the various debugging levels available, run the 'dvals'
script found in the driver source directory.
.. note::
'debug_level' is only enabled if CONFIG_IPW2100_DEBUG is turn on.
**Device Level**
For the device level files look in::
/sys/bus/pci/drivers/ipw2100/{PCI-ID}/
For example::
/sys/bus/pci/drivers/ipw2100/0000:02:01.0
For the device level files, see /sys/bus/pci/drivers/ipw2100:
rf_kill
read
== =========================================
0 RF kill not enabled (radio on)
1 SW based RF kill active (radio off)
2 HW based RF kill active (radio off)
3 Both HW and SW RF kill active (radio off)
== =========================================
write
== ==================================================
0 If SW based RF kill active, turn the radio back on
1 If radio is on, activate SW based RF kill
== ==================================================
.. note::
If you enable the SW based RF kill and then toggle the HW
based RF kill from ON -> OFF -> ON, the radio will NOT come back on
5. Radio Kill Switch
====================
Most laptops provide the ability for the user to physically disable the radio.
Some vendors have implemented this as a physical switch that requires no
software to turn the radio off and on. On other laptops, however, the switch
is controlled through a button being pressed and a software driver then making
calls to turn the radio off and on. This is referred to as a "software based
RF kill switch"
See the Sysfs helper file 'rf_kill' for determining the state of the RF switch
on your system.
6. Dynamic Firmware
===================
As the firmware is licensed under a restricted use license, it can not be
included within the kernel sources. To enable the IPW2100 you will need a
firmware image to load into the wireless NIC's processors.
You can obtain these images from <http://ipw2100.sf.net/firmware.php>.
See INSTALL for instructions on installing the firmware.
7. Power Management
===================
The IPW2100 supports the configuration of the Power Save Protocol
through a private wireless extension interface. The IPW2100 supports
the following different modes:
=== ===========================================================
off No power management. Radio is always on.
on Automatic power management
1-5 Different levels of power management. The higher the
number the greater the power savings, but with an impact to
packet latencies.
=== ===========================================================
Power management works by powering down the radio after a certain
interval of time has passed where no packets are passed through the
radio. Once powered down, the radio remains in that state for a given
period of time. For higher power savings, the interval between last
packet processed to sleep is shorter and the sleep period is longer.
When the radio is asleep, the access point sending data to the station
must buffer packets at the AP until the station wakes up and requests
any buffered packets. If you have an AP that does not correctly support
the PSP protocol you may experience packet loss or very poor performance
while power management is enabled. If this is the case, you will need
to try and find a firmware update for your AP, or disable power
management (via ``iwconfig eth1 power off``)
To configure the power level on the IPW2100 you use a combination of
iwconfig and iwpriv. iwconfig is used to turn power management on, off,
and set it to auto.
========================= ====================================
iwconfig eth1 power off Disables radio power down
iwconfig eth1 power on Enables radio power management to
last set level (defaults to AUTO)
iwpriv eth1 set_power 0 Sets power level to AUTO and enables
power management if not previously
enabled.
iwpriv eth1 set_power 1-5 Set the power level as specified,
enabling power management if not
previously enabled.
========================= ====================================
You can view the current power level setting via::
iwpriv eth1 get_power
It will return the current period or timeout that is configured as a string
in the form of xxxx/yyyy (z) where xxxx is the timeout interval (amount of
time after packet processing), yyyy is the period to sleep (amount of time to
wait before powering the radio and querying the access point for buffered
packets), and z is the 'power level'. If power management is turned off the
xxxx/yyyy will be replaced with 'off' -- the level reported will be the active
level if `iwconfig eth1 power on` is invoked.
8. Support
==========
For general development information and support,
go to:
http://ipw2100.sf.net/
The ipw2100 1.1.0 driver and firmware can be downloaded from:
http://support.intel.com
For installation support on the ipw2100 1.1.0 driver on Linux kernels
2.6.8 or greater, email support is available from:
http://supportmail.intel.com
9. License
==========
Copyright |copy| 2003 - 2006 Intel Corporation. All rights reserved.
This program is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License (version 2) as
published by the Free Software Foundation.
This program is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
more details.
You should have received a copy of the GNU General Public License along with
this program; if not, write to the Free Software Foundation, Inc., 59
Temple Place - Suite 330, Boston, MA 02111-1307, USA.
The full GNU General Public License is included in this distribution in the
file called LICENSE.
License Contact Information:
James P. Ketrenos <ipw2100-admin@linux.intel.com>
Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
linux-7.2.3/Documentation/networking/device_drivers/wifi/intel/ipw2200.rst
+526
View File
@@ -0,0 +1,526 @@
.. SPDX-License-Identifier: GPL-2.0
.. include:: <isonum.txt>
==============================================
Intel(R) PRO/Wireless 2915ABG Driver for Linux
==============================================
Support for:
- Intel(R) PRO/Wireless 2200BG Network Connection
- Intel(R) PRO/Wireless 2915ABG Network Connection
Note: The Intel(R) PRO/Wireless 2915ABG Driver for Linux and Intel(R)
PRO/Wireless 2200BG Driver for Linux is a unified driver that works on
both hardware adapters listed above. In this document the Intel(R)
PRO/Wireless 2915ABG Driver for Linux will be used to reference the
unified driver.
Copyright |copy| 2004-2006, Intel Corporation
README.ipw2200
:Version: 1.1.2
:Date: March 30, 2006
.. Index
0. IMPORTANT INFORMATION BEFORE USING THIS DRIVER
1. Introduction
1.1. Overview of features
1.2. Module parameters
1.3. Wireless Extension Private Methods
1.4. Sysfs Helper Files
1.5. Supported channels
2. Ad-Hoc Networking
3. Interacting with Wireless Tools
3.1. iwconfig mode
3.2. iwconfig sens
4. About the Version Numbers
5. Firmware installation
6. Support
7. License
0. IMPORTANT INFORMATION BEFORE USING THIS DRIVER
=================================================
Important Notice FOR ALL USERS OR DISTRIBUTORS!!!!
Intel wireless LAN adapters are engineered, manufactured, tested, and
quality checked to ensure that they meet all necessary local and
governmental regulatory agency requirements for the regions that they
are designated and/or marked to ship into. Since wireless LANs are
generally unlicensed devices that share spectrum with radars,
satellites, and other licensed and unlicensed devices, it is sometimes
necessary to dynamically detect, avoid, and limit usage to avoid
interference with these devices. In many instances Intel is required to
provide test data to prove regional and local compliance to regional and
governmental regulations before certification or approval to use the
product is granted. Intel's wireless LAN's EEPROM, firmware, and
software driver are designed to carefully control parameters that affect
radio operation and to ensure electromagnetic compliance (EMC). These
parameters include, without limitation, RF power, spectrum usage,
channel scanning, and human exposure.
For these reasons Intel cannot permit any manipulation by third parties
of the software provided in binary format with the wireless WLAN
adapters (e.g., the EEPROM and firmware). Furthermore, if you use any
patches, utilities, or code with the Intel wireless LAN adapters that
have been manipulated by an unauthorized party (i.e., patches,
utilities, or code (including open source code modifications) which have
not been validated by Intel), (i) you will be solely responsible for
ensuring the regulatory compliance of the products, (ii) Intel will bear
no liability, under any theory of liability for any issues associated
with the modified products, including without limitation, claims under
the warranty and/or issues arising from regulatory non-compliance, and
(iii) Intel will not provide or be required to assist in providing
support to any third parties for such modified products.
Note: Many regulatory agencies consider Wireless LAN adapters to be
modules, and accordingly, condition system-level regulatory approval
upon receipt and review of test data documenting that the antennas and
system configuration do not cause the EMC and radio operation to be
non-compliant.
The drivers available for download from SourceForge are provided as a
part of a development project. Conformance to local regulatory
requirements is the responsibility of the individual developer. As
such, if you are interested in deploying or shipping a driver as part of
solution intended to be used for purposes other than development, please
obtain a tested driver from Intel Customer Support at:
http://support.intel.com
1. Introduction
===============
The following sections attempt to provide a brief introduction to using
the Intel(R) PRO/Wireless 2915ABG Driver for Linux.
This document is not meant to be a comprehensive manual on
understanding or using wireless technologies, but should be sufficient
to get you moving without wires on Linux.
For information on building and installing the driver, see the INSTALL
file.
1.1. Overview of Features
-------------------------
The current release (1.1.2) supports the following features:
+ BSS mode (Infrastructure, Managed)
+ IBSS mode (Ad-Hoc)
+ WEP (OPEN and SHARED KEY mode)
+ 802.1x EAP via wpa_supplicant and xsupplicant
+ Wireless Extension support
+ Full B and G rate support (2200 and 2915)
+ Full A rate support (2915 only)
+ Transmit power control
+ S state support (ACPI suspend/resume)
The following features are currently enabled, but not officially
supported:
+ WPA
+ long/short preamble support
+ Monitor mode (aka RFMon)
The distinction between officially supported and enabled is a reflection
on the amount of validation and interoperability testing that has been
performed on a given feature.
1.2. Command Line Parameters
----------------------------
Like many modules used in the Linux kernel, the Intel(R) PRO/Wireless
2915ABG Driver for Linux allows configuration options to be provided
as module parameters. The most common way to specify a module parameter
is via the command line.
The general form is::
% modprobe ipw2200 parameter=value
Where the supported parameter are:
associate
Set to 0 to disable the auto scan-and-associate functionality of the
driver. If disabled, the driver will not attempt to scan
for and associate to a network until it has been configured with
one or more properties for the target network, for example configuring
the network SSID. Default is 0 (do not auto-associate)
Example: % modprobe ipw2200 associate=0
auto_create
Set to 0 to disable the auto creation of an Ad-Hoc network
matching the channel and network name parameters provided.
Default is 1.
channel
channel number for association. The normal method for setting
the channel would be to use the standard wireless tools
(i.e. `iwconfig eth1 channel 10`), but it is useful sometimes
to set this while debugging. Channel 0 means 'ANY'
debug
If using a debug build, this is used to control the amount of debug
info is logged. See the 'dvals' and 'load' script for more info on
how to use this (the dvals and load scripts are provided as part
of the ipw2200 development snapshot releases available from the
SourceForge project at http://ipw2200.sf.net)
led
Can be used to turn on experimental LED code.
0 = Off, 1 = On. Default is 1.
mode
Can be used to set the default mode of the adapter.
0 = Managed, 1 = Ad-Hoc, 2 = Monitor
1.3. Wireless Extension Private Methods
---------------------------------------
As an interface designed to handle generic hardware, there are certain
capabilities not exposed through the normal Wireless Tool interface. As
such, a provision is provided for a driver to declare custom, or
private, methods. The Intel(R) PRO/Wireless 2915ABG Driver for Linux
defines several of these to configure various settings.
The general form of using the private wireless methods is::
% iwpriv $IFNAME method parameters
Where $IFNAME is the interface name the device is registered with
(typically eth1, customized via one of the various network interface
name managers, such as ifrename)
The supported private methods are:
get_mode
Can be used to report out which IEEE mode the driver is
configured to support. Example:
% iwpriv eth1 get_mode
eth1 get_mode:802.11bg (6)
set_mode
Can be used to configure which IEEE mode the driver will
support.
Usage::
% iwpriv eth1 set_mode {mode}
Where {mode} is a number in the range 1-7:
== =====================
1 802.11a (2915 only)
2 802.11b
3 802.11ab (2915 only)
4 802.11g
5 802.11ag (2915 only)
6 802.11bg
7 802.11abg (2915 only)
== =====================
get_preamble
Can be used to report configuration of preamble length.
set_preamble
Can be used to set the configuration of preamble length:
Usage::
% iwpriv eth1 set_preamble {mode}
Where {mode} is one of:
== ========================================
1 Long preamble only
0 Auto (long or short based on connection)
== ========================================
1.4. Sysfs Helper Files
-----------------------
The Linux kernel provides a pseudo file system that can be used to
access various components of the operating system. The Intel(R)
PRO/Wireless 2915ABG Driver for Linux exposes several configuration
parameters through this mechanism.
An entry in the sysfs can support reading and/or writing. You can
typically query the contents of a sysfs entry through the use of cat,
and can set the contents via echo. For example::
% cat /sys/bus/pci/drivers/ipw2200/debug_level
Will report the current debug level of the driver's logging subsystem
(only available if CONFIG_IPW2200_DEBUG was configured when the driver
was built).
You can set the debug level via::
% echo $VALUE > /sys/bus/pci/drivers/ipw2200/debug_level
Where $VALUE would be a number in the case of this sysfs entry. The
input to sysfs files does not have to be a number. For example, the
firmware loader used by hotplug utilizes sysfs entries for transferring
the firmware image from user space into the driver.
The Intel(R) PRO/Wireless 2915ABG Driver for Linux exposes sysfs entries
at two levels -- driver level, which apply to all instances of the driver
(in the event that there are more than one device installed) and device
level, which applies only to the single specific instance.
1.4.1 Driver Level Sysfs Helper Files
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
For the driver level files, look in /sys/bus/pci/drivers/ipw2200/
debug_level
This controls the same global as the 'debug' module parameter
1.4.2 Device Level Sysfs Helper Files
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
For the device level files, look in::
/sys/bus/pci/drivers/ipw2200/{PCI-ID}/
For example:::
/sys/bus/pci/drivers/ipw2200/0000:02:01.0
For the device level files, see /sys/bus/pci/drivers/ipw2200:
rf_kill
read -
== =========================================
0 RF kill not enabled (radio on)
1 SW based RF kill active (radio off)
2 HW based RF kill active (radio off)
3 Both HW and SW RF kill active (radio off)
== =========================================
write -
== ==================================================
0 If SW based RF kill active, turn the radio back on
1 If radio is on, activate SW based RF kill
== ==================================================
.. note::
If you enable the SW based RF kill and then toggle the HW
based RF kill from ON -> OFF -> ON, the radio will NOT come back on
ucode
read-only access to the ucode version number
led
read -
== =================
0 LED code disabled
1 LED code enabled
== =================
write -
== ================
0 Disable LED code
1 Enable LED code
== ================
.. note::
The LED code has been reported to hang some systems when
running ifconfig and is therefore disabled by default.
1.5. Supported channels
-----------------------
Upon loading the Intel(R) PRO/Wireless 2915ABG Driver for Linux, a
message stating the detected geography code and the number of 802.11
channels supported by the card will be displayed in the log.
The geography code corresponds to a regulatory domain as shown in the
table below.
+------+----------------------------+--------------------+
| | | Supported channels |
| Code | Geography +----------+---------+
| | | 802.11bg | 802.11a |
+======+============================+==========+=========+
| --- | Restricted | 11 | 0 |
+------+----------------------------+----------+---------+
| ZZF | Custom US/Canada | 11 | 8 |
+------+----------------------------+----------+---------+
| ZZD | Rest of World | 13 | 0 |
+------+----------------------------+----------+---------+
| ZZA | Custom USA & Europe & High | 11 | 13 |
+------+----------------------------+----------+---------+
| ZZB | Custom NA & Europe | 11 | 13 |
+------+----------------------------+----------+---------+
| ZZC | Custom Japan | 11 | 4 |
+------+----------------------------+----------+---------+
| ZZM | Custom | 11 | 0 |
+------+----------------------------+----------+---------+
| ZZE | Europe | 13 | 19 |
+------+----------------------------+----------+---------+
| ZZJ | Custom Japan | 14 | 4 |
+------+----------------------------+----------+---------+
| ZZR | Rest of World | 14 | 0 |
+------+----------------------------+----------+---------+
| ZZH | High Band | 13 | 4 |
+------+----------------------------+----------+---------+
| ZZG | Custom Europe | 13 | 4 |
+------+----------------------------+----------+---------+
| ZZK | Europe | 13 | 24 |
+------+----------------------------+----------+---------+
| ZZL | Europe | 11 | 13 |
+------+----------------------------+----------+---------+
2. Ad-Hoc Networking
=====================
When using a device in an Ad-Hoc network, it is useful to understand the
sequence and requirements for the driver to be able to create, join, or
merge networks.
The following attempts to provide enough information so that you can
have a consistent experience while using the driver as a member of an
Ad-Hoc network.
2.1. Joining an Ad-Hoc Network
------------------------------
The easiest way to get onto an Ad-Hoc network is to join one that
already exists.
2.2. Creating an Ad-Hoc Network
-------------------------------
An Ad-Hoc networks is created using the syntax of the Wireless tool.
For Example:
iwconfig eth1 mode ad-hoc essid testing channel 2
2.3. Merging Ad-Hoc Networks
----------------------------
3. Interaction with Wireless Tools
==================================
3.1 iwconfig mode
-----------------
When configuring the mode of the adapter, all run-time configured parameters
are reset to the value used when the module was loaded. This includes
channels, rates, ESSID, etc.
3.2 iwconfig sens
-----------------
The 'iwconfig ethX sens XX' command will not set the signal sensitivity
threshold, as described in iwconfig documentation, but rather the number
of consecutive missed beacons that will trigger handover, i.e. roaming
to another access point. At the same time, it will set the disassociation
threshold to 3 times the given value.
4. About the Version Numbers
=============================
Due to the nature of open source development projects, there are
frequently changes being incorporated that have not gone through
a complete validation process. These changes are incorporated into
development snapshot releases.
Releases are numbered with a three level scheme:
major.minor.development
Any version where the 'development' portion is 0 (for example
1.0.0, 1.1.0, etc.) indicates a stable version that will be made
available for kernel inclusion.
Any version where the 'development' portion is not a 0 (for
example 1.0.1, 1.1.5, etc.) indicates a development version that is
being made available for testing and cutting edge users. The stability
and functionality of the development releases are not know. We make
efforts to try and keep all snapshots reasonably stable, but due to the
frequency of their release, and the desire to get those releases
available as quickly as possible, unknown anomalies should be expected.
The major version number will be incremented when significant changes
are made to the driver. Currently, there are no major changes planned.
5. Firmware installation
========================
The driver requires a firmware image, download it and extract the
files under /lib/firmware (or wherever your hotplug's firmware.agent
will look for firmware files)
The firmware can be downloaded from the following URL:
http://ipw2200.sf.net/
6. Support
==========
For direct support of the 1.0.0 version, you can contact
http://supportmail.intel.com, or you can use the open source project
support.
For general information and support, go to:
http://ipw2200.sf.net/
7. License
==========
Copyright |copy| 2003 - 2006 Intel Corporation. All rights reserved.
This program is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License version 2 as
published by the Free Software Foundation.
This program is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
more details.
You should have received a copy of the GNU General Public License along with
this program; if not, write to the Free Software Foundation, Inc., 59
Temple Place - Suite 330, Boston, MA 02111-1307, USA.
The full GNU General Public License is included in this distribution in the
file called LICENSE.
Contact Information:
James P. Ketrenos <ipw2100-admin@linux.intel.com>
Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
linux-7.2.3/Documentation/networking/device_drivers/wwan/index.rst
+12
View File
@@ -0,0 +1,12 @@
.. SPDX-License-Identifier: GPL-2.0-only
WWAN Device Drivers
===================
Contents:
.. toctree::
:maxdepth: 2
iosm
t7xx
linux-7.2.3/Documentation/networking/device_drivers/wwan/iosm.rst
+96
View File
@@ -0,0 +1,96 @@
.. SPDX-License-Identifier: GPL-2.0-only
.. Copyright (C) 2020-21 Intel Corporation
.. _iosm_driver_doc:
===========================================
IOSM Driver for Intel M.2 PCIe based Modems
===========================================
The IOSM (IPC over Shared Memory) driver is a WWAN PCIe host driver developed
for linux or chrome platform for data exchange over PCIe interface between
Host platform & Intel M.2 Modem. The driver exposes interface conforming to the
MBIM protocol [1]. Any front end application ( eg: Modem Manager) could easily
manage the MBIM interface to enable data communication towards WWAN.
Basic usage
===========
MBIM functions are inactive when unmanaged. The IOSM driver only provides a
userspace interface MBIM "WWAN PORT" representing MBIM control channel and does
not play any role in managing the functionality. It is the job of a userspace
application to detect port enumeration and enable MBIM functionality.
Examples of few such userspace application are:
- mbimcli (included with the libmbim [2] library), and
- Modem Manager [3]
Management Applications to carry out below required actions for establishing
MBIM IP session:
- open the MBIM control channel
- configure network connection settings
- connect to network
- configure IP network interface
Management application development
==================================
The driver and userspace interfaces are described below. The MBIM protocol is
described in [1] Mobile Broadband Interface Model v1.0 Errata-1.
MBIM control channel userspace ABI
----------------------------------
/dev/wwan0mbim0 character device
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The driver exposes an MBIM interface to the MBIM function by implementing
MBIM WWAN Port. The userspace end of the control channel pipe is a
/dev/wwan0mbim0 character device. Application shall use this interface for
MBIM protocol communication.
Fragmentation
~~~~~~~~~~~~~
The userspace application is responsible for all control message fragmentation
and defragmentation as per MBIM specification.
/dev/wwan0mbim0 write()
~~~~~~~~~~~~~~~~~~~~~~~
The MBIM control messages from the management application must not exceed the
negotiated control message size.
/dev/wwan0mbim0 read()
~~~~~~~~~~~~~~~~~~~~~~
The management application must accept control messages of up the negotiated
control message size.
MBIM data channel userspace ABI
-------------------------------
wwan0-X network device
~~~~~~~~~~~~~~~~~~~~~~
The IOSM driver exposes IP link interface "wwan0-X" of type "wwan" for IP
traffic. Iproute network utility is used for creating "wwan0-X" network
interface and for associating it with MBIM IP session. The Driver supports
up to 8 IP sessions for simultaneous IP communication.
The userspace management application is responsible for creating new IP link
prior to establishing MBIM IP session where the SessionId is greater than 0.
For example, creating new IP link for a MBIM IP session with SessionId 1:
ip link add dev wwan0-1 parentdev-name wwan0 type wwan linkid 1
The driver will automatically map the "wwan0-1" network device to MBIM IP
session 1.
References
==========
[1] "MBIM (Mobile Broadband Interface Model) Errata-1"
- https://www.usb.org/document-library/
[2] libmbim - "a glib-based library for talking to WWAN modems and
devices which speak the Mobile Interface Broadband Model (MBIM)
protocol"
- http://www.freedesktop.org/wiki/Software/libmbim/
[3] Modem Manager - "a DBus-activated daemon which controls mobile
broadband (2G/3G/4G) devices and connections"
- http://www.freedesktop.org/wiki/Software/ModemManager/
linux-7.2.3/Documentation/networking/device_drivers/wwan/t7xx.rst
+214
View File
@@ -0,0 +1,214 @@
.. SPDX-License-Identifier: GPL-2.0-only
.. Copyright (C) 2020-21 Intel Corporation
.. _t7xx_driver_doc:
============================================
t7xx driver for MTK PCIe based T700 5G modem
============================================
The t7xx driver is a WWAN PCIe host driver developed for linux or Chrome OS
platforms for data exchange over PCIe interface between Host platform &
MediaTek's T700 5G modem.
The driver exposes an interface conforming to the MBIM protocol [1]. Any front
end application (e.g. Modem Manager) could easily manage the MBIM interface to
enable data communication towards WWAN. The driver also provides an interface
to interact with the MediaTek's modem via AT commands.
Basic usage
===========
MBIM & AT functions are inactive when unmanaged. The t7xx driver provides
WWAN port userspace interfaces representing MBIM & AT control channels and does
not play any role in managing their functionality. It is the job of a userspace
application to detect port enumeration and enable MBIM & AT functionalities.
Examples of few such userspace applications are:
- mbimcli (included with the libmbim [2] library), and
- Modem Manager [3]
Management Applications to carry out below required actions for establishing
MBIM IP session:
- open the MBIM control channel
- configure network connection settings
- connect to network
- configure IP network interface
Management Applications to carry out below required actions for send an AT
command and receive response:
- open the AT control channel using a UART tool or a special user tool
Sysfs
=====
The driver provides sysfs interfaces to userspace.
t7xx_mode
---------
The sysfs interface provides userspace with access to the device mode, this
interface supports read and write operations.
Device mode:
- ``unknown`` represents that device in unknown status
- ``ready`` represents that device in ready status
- ``reset`` represents that device in reset status
- ``fastboot_switching`` represents that device in fastboot switching status
- ``fastboot_download`` represents that device in fastboot download status
- ``fastboot_dump`` represents that device in fastboot dump status
Read from userspace to get the current device mode.
::
$ cat /sys/bus/pci/devices/${bdf}/t7xx_mode
Write from userspace to set the device mode.
::
$ echo fastboot_switching > /sys/bus/pci/devices/${bdf}/t7xx_mode
t7xx_debug_ports
----------------
The sysfs interface provides userspace with access to enable/disable the debug
ports, this interface supports read and write operations.
Debug port status:
- ``1`` represents enable debug ports
- ``0`` represents disable debug ports
Currently supported debug ports (ADB/MIPC).
Read from userspace to get the current debug ports status.
::
$ cat /sys/bus/pci/devices/${bdf}/t7xx_debug_ports
Write from userspace to set the debug ports status.
::
$ echo 1 > /sys/bus/pci/devices/${bdf}/t7xx_debug_ports
Management application development
==================================
The driver and userspace interfaces are described below. The MBIM protocol is
described in [1] Mobile Broadband Interface Model v1.0 Errata-1.
MBIM control channel userspace ABI
----------------------------------
/dev/wwan0mbim0 character device
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The driver exposes an MBIM interface to the MBIM function by implementing
MBIM WWAN Port. The userspace end of the control channel pipe is a
/dev/wwan0mbim0 character device. Application shall use this interface for
MBIM protocol communication.
Fragmentation
~~~~~~~~~~~~~
The userspace application is responsible for all control message fragmentation
and defragmentation as per MBIM specification.
/dev/wwan0mbim0 write()
~~~~~~~~~~~~~~~~~~~~~~~
The MBIM control messages from the management application must not exceed the
negotiated control message size.
/dev/wwan0mbim0 read()
~~~~~~~~~~~~~~~~~~~~~~
The management application must accept control messages of up the negotiated
control message size.
MBIM data channel userspace ABI
-------------------------------
wwan0-X network device
~~~~~~~~~~~~~~~~~~~~~~
The t7xx driver exposes IP link interface "wwan0-X" of type "wwan" for IP
traffic. Iproute network utility is used for creating "wwan0-X" network
interface and for associating it with MBIM IP session.
The userspace management application is responsible for creating new IP link
prior to establishing MBIM IP session where the SessionId is greater than 0.
For example, creating new IP link for a MBIM IP session with SessionId 1:
ip link add dev wwan0-1 parentdev wwan0 type wwan linkid 1
The driver will automatically map the "wwan0-1" network device to MBIM IP
session 1.
AT port userspace ABI
----------------------------------
/dev/wwan0at0 character device
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The driver exposes an AT port by implementing AT WWAN Port.
The userspace end of the control port is a /dev/wwan0at0 character
device. Application shall use this interface to issue AT commands.
fastboot port userspace ABI
---------------------------
/dev/wwan0fastboot0 character device
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The driver exposes a fastboot protocol interface by implementing
fastboot WWAN Port. The userspace end of the fastboot channel pipe is a
/dev/wwan0fastboot0 character device. Application shall use this interface for
fastboot protocol communication.
Please note that driver needs to be reloaded to export /dev/wwan0fastboot0
port, because device needs a cold reset after enter ``fastboot_switching``
mode.
ADB port userspace ABI
----------------------
/dev/wwan0adb0 character device
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The driver exposes a ADB protocol interface by implementing ADB WWAN Port.
The userspace end of the ADB channel pipe is a /dev/wwan0adb0 character device.
Application shall use this interface for ADB protocol communication.
MIPC port userspace ABI
-----------------------
/dev/wwan0mipc0 character device
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The driver exposes a diagnostic interface by implementing MIPC (Modem
Information Process Center) WWAN Port. The userspace end of the MIPC channel
pipe is a /dev/wwan0mipc0 character device.
Application shall use this interface for MTK modem diagnostic communication.
The MediaTek's T700 modem supports the 3GPP TS 27.007 [4] specification.
References
==========
[1] *MBIM (Mobile Broadband Interface Model) Errata-1*
- https://www.usb.org/document-library/
[2] *libmbim "a glib-based library for talking to WWAN modems and devices which
speak the Mobile Interface Broadband Model (MBIM) protocol"*
- http://www.freedesktop.org/wiki/Software/libmbim/
[3] *Modem Manager "a DBus-activated daemon which controls mobile broadband
(2G/3G/4G/5G) devices and connections"*
- http://www.freedesktop.org/wiki/Software/ModemManager/
[4] *Specification # 27.007 - 3GPP*
- https://www.3gpp.org/DynaReport/27007.htm
[5] *fastboot "a mechanism for communicating with bootloaders"*
- https://android.googlesource.com/platform/system/core/+/refs/heads/main/fastboot/README.md
[6] *ADB (Android Debug Bridge) "a mechanism to keep track of Android devices
and emulators instances connected to or running on a given host developer
machine with ADB protocol"*
- https://android.googlesource.com/platform/packages/modules/adb/+/refs/heads/main/README.md