提交 817e9290 编写于 作者: D David S. Miller

Merge branch '10GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue

Jeff Kirsher says:

====================
Intel Wired LAN Doc Updates 2018-10-18

This series contains documentation fixes and updates for Intel wired
LAN drivers.

The following was done:
 - Updated incorrect URLs
 - removed document references which did not apply to the current
   in-kernel drivers
 - added documentation for fm10k driver
 - added missing documentation on existing or new features
 - added SPDX headers to all the documentation files

Lastly, the documentation was converted over to the RST (reStructured
Text) format, so that 'make htmldocs' produces pretty html driver
documentation for our drivers.
====================
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
...@@ -70,12 +70,6 @@ driver.txt ...@@ -70,12 +70,6 @@ driver.txt
- Softnet driver issues. - Softnet driver issues.
ena.txt ena.txt
- info on Amazon's Elastic Network Adapter (ENA) - info on Amazon's Elastic Network Adapter (ENA)
e100.txt
- info on Intel's EtherExpress PRO/100 line of 10/100 boards
e1000.txt
- info on Intel's E1000 line of gigabit ethernet boards
e1000e.txt
- README for the Intel Gigabit Ethernet Driver (e1000e).
eql.txt eql.txt
- serial IP load balancing - serial IP load balancing
fib_trie.txt fib_trie.txt
...@@ -94,16 +88,8 @@ generic_netlink.txt ...@@ -94,16 +88,8 @@ generic_netlink.txt
- info on Generic Netlink - info on Generic Netlink
gianfar.txt gianfar.txt
- Gianfar Ethernet Driver. - Gianfar Ethernet Driver.
i40e.txt
- README for the Intel Ethernet Controller XL710 Driver (i40e).
iavf.txt
- README for the Intel Ethernet Adaptive Virtual Function Driver (iavf).
ieee802154.txt ieee802154.txt
- Linux IEEE 802.15.4 implementation, API and drivers - Linux IEEE 802.15.4 implementation, API and drivers
igb.txt
- README for the Intel Gigabit Ethernet Driver (igb).
igbvf.txt
- README for the Intel Gigabit Ethernet Driver (igbvf).
ip-sysctl.txt ip-sysctl.txt
- /proc/sys/net/ipv4/* variables - /proc/sys/net/ipv4/* variables
ip_dynaddr.txt ip_dynaddr.txt
...@@ -120,12 +106,6 @@ ipvs-sysctl.txt ...@@ -120,12 +106,6 @@ ipvs-sysctl.txt
- Per-inode explanation of the /proc/sys/net/ipv4/vs interface. - Per-inode explanation of the /proc/sys/net/ipv4/vs interface.
irda.txt irda.txt
- where to get IrDA (infrared) utilities and info for Linux. - where to get IrDA (infrared) utilities and info for Linux.
ixgb.txt
- README for the Intel 10 Gigabit Ethernet Driver (ixgb).
ixgbe.txt
- README for the Intel 10 Gigabit Ethernet Driver (ixgbe).
ixgbevf.txt
- README for the Intel Virtual Function (VF) Driver (ixgbevf).
l2tp.txt l2tp.txt
- User guide to the L2TP tunnel protocol. - User guide to the L2TP tunnel protocol.
lapb-module.txt lapb-module.txt
......
============================================================== .. SPDX-License-Identifier: GPL-2.0+
Linux* Base Driver for the Intel(R) PRO/100 Family of Adapters Linux* Base Driver for the Intel(R) PRO/100 Family of Adapters
============================================================== ==============================================================
......
=========================================================== .. SPDX-License-Identifier: GPL-2.0+
Linux* Base Driver for Intel(R) Ethernet Network Connection Linux* Base Driver for Intel(R) Ethernet Network Connection
=========================================================== ===========================================================
......
.. 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/
or the Intel Wired Networking project hosted by Sourceforge at:
https://sourceforge.net/projects/e1000
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 e1000-devel@lists.sf.net.
Linux* Driver for Intel(R) Ethernet Network Connection
======================================================
Intel Gigabit Linux driver.
Copyright(c) 1999 - 2013 Intel Corporation.
Contents
========
- Identifying Your Adapter
- Command Line Parameters
- Additional Configurations
- Support
Identifying Your Adapter
========================
The e1000e driver supports all PCI Express Intel(R) Gigabit Network
Connections, except those that are 82575, 82576 and 82580-based*.
* NOTE: The Intel(R) PRO/1000 P Dual Port Server Adapter is supported by
the e1000 driver, not the e1000e driver due to the 82546 part being used
behind a PCI Express bridge.
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 InterruptThrottleRate,
RxIntDelay, TxIntDelay, RxAbsIntDelay, and TxAbsIntDelay
parameters, see the application note at:
http://www.intel.com/design/network/applnots/ap450.htm
InterruptThrottleRate
---------------------
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.
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.
NOTE: When e1000e 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 e1000e 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.
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. 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.
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. 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.
Copybreak
---------
Valid Range: 0-xxxxxxx (0=off)
Default Value: 256
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/e1000e/parameters/copybreak
SmartPowerDownEnable
--------------------
Valid Range: 0-1
Default Value: 0 (disabled)
Allows PHY to turn off in lower power states. The user can set 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 (0=legacy, 1=MSI, 2=MSI-X)
Default Value: 2
Allows changing the interrupt mode at module load time, without requiring a
recompile. If the driver load fails to enable a specific interrupt mode, the
driver will try other interrupt modes, from least to most compatible. The
interrupt order is MSI-X, MSI, Legacy. If specifying MSI (IntMode=1)
interrupts, only MSI and Legacy will be attempted.
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
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.
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.
Notes:
- The maximum MTU setting for Jumbo Frames is 9216. This value coincides
with the maximum Jumbo Frames size of 9234 bytes.
- Using Jumbo frames at 10 or 100 Mbps is not supported and may result in
poor performance or loss of link.
- Some adapters limit Jumbo Frames sized packets to a maximum of
4096 bytes and some adapters do not support Jumbo Frames.
- 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. We
strongly recommend downloading the latest version of ethtool at:
https://kernel.org/pub/software/network/ethtool/
NOTE: When validating enable/disable tests on some parts (82578, for example)
you need to add a few seconds between tests when working with ethtool.
Speed and Duplex
----------------
Speed and Duplex are configured through the ethtool* utility. For
instructions, refer to the ethtool man page.
Enabling Wake on LAN* (WoL)
---------------------------
WoL is configured 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 e1000e driver must be
loaded when shutting down or rebooting the system.
In most cases Wake On LAN is only supported on port A for multiple port
adapters. To verify if a port supports Wake on Lan run ethtool eth<X>.
Support
=======
For general information, go to the Intel support website at:
www.intel.com/support/
or the Intel Wired Networking project hosted by Sourceforge at:
http://sourceforge.net/projects/e1000
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 e1000-devel@lists.sf.net
.. 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:
http://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/
or the Intel Wired Networking project hosted by Sourceforge at:
https://sourceforge.net/projects/e1000
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 e1000-devel@lists.sf.net.
此差异已折叠。
Linux Base Driver for the Intel(R) Ethernet Controller XL710 Family
===================================================================
Intel i40e Linux driver.
Copyright(c) 2013 Intel Corporation.
Contents
========
- Identifying Your Adapter
- Additional Configurations
- Performance Tuning
- Known Issues
- Support
Identifying Your Adapter
========================
The driver in this release is compatible with the Intel Ethernet
Controller XL710 Family.
For more information on how to identify your adapter, go to the Adapter &
Driver ID Guide at:
http://support.intel.com/support/network/sb/CS-012904.htm
Enabling the driver
===================
The driver is enabled via the standard kernel configuration system,
using the make command:
make config/oldconfig/menuconfig/etc.
The driver is located in the menu structure at:
-> Device Drivers
-> Network device support (NETDEVICES [=y])
-> Ethernet driver support
-> Intel devices
-> Intel(R) Ethernet Controller XL710 Family
Additional Configurations
=========================
Generic Receive Offload (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.
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.
The latest release of ethtool can be found from
https://www.kernel.org/pub/software/network/ethtool
Flow Director n-ntuple traffic filters (FDir)
---------------------------------------------
The driver utilizes the ethtool interface for configuring ntuple filters,
via "ethtool -N <device> <filter>".
The sctp4, ip4, udp4, and tcp4 flow types are supported with the standard
fields including src-ip, dst-ip, src-port and dst-port. The driver only
supports fully enabling or fully masking the fields, so use of the mask
fields for partial matches is not supported.
Additionally, the driver supports using the action to specify filters for a
Virtual Function. You can specify the action as a 64bit 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 ...
Would indicate to direct traffic for Virtual Function 7 (8 minus 1) on queue
2 of that VF.
The driver also supports using the user-defined field to specify 2 bytes of
arbitrary data to match within the packet payload in addition to the regular
fields. The data is specified in the lower 32bits of the user-def field in
the following way:
+----------------------------+---------------------------+
| 31 28 24 20 16 | 15 12 8 4 0|
+----------------------------+---------------------------+
| offset into packet payload | 2 bytes of flexible data |
+----------------------------+---------------------------+
As an example,
... user-def 0x4FFFF ....
means to match the value 0xFFFF 4 bytes into the packet payload. Note that
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 8bytes into the
TCP/IPv4 payload.
For ICMP, the hardware parses the ICMP header as 4 bytes of header and 4
bytes of payload, so if you want to match an ICMP frames payload you may need
to add 4 to the offset in order to match the data.
Furthermore, the offset can only be up to a value of 64, as the hardware
will only read up to 64 bytes of data from the payload. It must also be even
as the flexible data is 2 bytes long and must be aligned to byte 0 of the
packet payload.
When programming filters, the hardware is limited to using a single input
set for each flow type. This means that it is an error to program two
different filters with the same type that don't match on the same fields.
Thus the second of the following two commands will fail:
ethtool -N <device> flow-type tcp4 src-ip 192.168.0.7 action 5
ethtool -N <device> flow-type tcp4 dst-ip 192.168.15.18 action 1
This is because the first filter will be accepted and reprogram the input
set for TCPv4 filters, but the second filter will be unable to reprogram the
input set until all the conflicting TCPv4 filters are first removed.
Note that 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.
Data Center Bridging (DCB)
--------------------------
DCB configuration is not currently supported.
FCoE
----
The driver supports Fiber Channel over Ethernet (FCoE) and Data Center
Bridging (DCB) functionality. Configuring DCB and FCoE is outside the scope
of this driver doc. Refer to http://www.open-fcoe.org/ for FCoE project
information and http://www.open-lldp.org/ or email list
e1000-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):
Spoof event(s) detected on VF (n)
Where n=the VF that attempted to do the spoofing.
Performance Tuning
==================
An excellent article on performance tuning can be found at:
http://www.redhat.com/promo/summit/2008/downloads/pdf/Thursday/Mark_Wagner.pdf
Known Issues
============
Support
=======
For general information, go to the Intel support website at:
http://support.intel.com
or the Intel Wired Networking project hosted by Sourceforge at:
http://e1000.sourceforge.net
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 e1000-devel@lists.sourceforge.net and copy
netdev@vger.kernel.org.
.. 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
========
- Identifying Your Adapter
- Additional Configurations
- Known Issues/Troubleshooting
- Support
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:
http://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.
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
============================
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.
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
or the Intel Wired Networking project hosted by Sourceforge at:
https://sourceforge.net/projects/e1000
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 e1000-devel@lists.sf.net
Linux* Base Driver for Intel(R) Network Connection
==================================================
Intel Ethernet Adaptive Virtual Function Linux driver.
Copyright(c) 2013-2018 Intel Corporation.
Contents
========
- Identifying Your Adapter
- Known Issues/Troubleshooting
- Support
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.
Supported Hardware
==================
Intel XL710 X710 Virtual Function
Intel X722 Virtual Function
Intel Ethernet Adaptive Virtual Function
Identifying Your Adapter
========================
For more information on how to identify your adapter, go to the
Adapter & Driver ID Guide at:
https://www.intel.com/content/www/us/en/support/articles/000005584/network-and-i-o/ethernet-products.html
Known Issues/Troubleshooting
============================
Support
=======
For general information, go to the Intel support website at:
http://support.intel.com
or the Intel Wired Networking project hosted by Sourceforge at:
http://sourceforge.net/projects/e1000
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 e1000-devel@lists.sf.net
Intel(R) Ethernet Connection E800 Series Linux Driver .. SPDX-License-Identifier: GPL-2.0+
Linux* Base Driver for the Intel(R) Ethernet Connection E800 Series
=================================================================== ===================================================================
Intel ice Linux driver. Intel ice Linux driver.
...@@ -6,19 +8,19 @@ Copyright(c) 2018 Intel Corporation. ...@@ -6,19 +8,19 @@ Copyright(c) 2018 Intel Corporation.
Contents Contents
======== ========
- Enabling the driver - Enabling the driver
- Support - Support
The driver in this release supports Intel's E800 Series of products. For The driver in this release supports Intel's E800 Series of products. For
more information, visit Intel's support page at http://support.intel.com. more information, visit Intel's support page at https://support.intel.com.
Enabling the driver Enabling the driver
=================== ===================
The driver is enabled via the standard kernel configuration system, The driver is enabled via the standard kernel configuration system,
using the make command: using the make command::
Make oldconfig/silentoldconfig/menuconfig/etc. make oldconfig/silentoldconfig/menuconfig/etc.
The driver is located in the menu structure at: The driver is located in the menu structure at:
...@@ -30,10 +32,14 @@ The driver is located in the menu structure at: ...@@ -30,10 +32,14 @@ The driver is located in the menu structure at:
Support Support
======= =======
For general information, go to the Intel support website at: For general information, go to the Intel support website at:
http://support.intel.com https://www.intel.com/support/
or the Intel Wired Networking project hosted by Sourceforge at:
https://sourceforge.net/projects/e1000
If an issue is identified with the released source code, please email If an issue is identified with the released source code on a supported kernel
the maintainer listed in the MAINTAINERS file. with a supported adapter, email the specific information related to the issue
to e1000-devel@lists.sf.net.
.. 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:
http://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.
Support
=======
For general information, go to the Intel support website at:
https://www.intel.com/support/
or the Intel Wired Networking project hosted by Sourceforge at:
https://sourceforge.net/projects/e1000
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 e1000-devel@lists.sf.net.
Linux* Base Driver for Intel(R) Ethernet Network Connection
===========================================================
Intel Gigabit Linux driver.
Copyright(c) 1999 - 2013 Intel Corporation.
Contents
========
- Identifying Your Adapter
- Additional Configurations
- Support
Identifying Your Adapter
========================
This driver supports all 82575, 82576 and 82580-based Intel (R) gigabit network
connections.
For specific 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
Command Line Parameters
=======================
The default value for each parameter is generally the recommended setting,
unless otherwise noted.
max_vfs
-------
Valid Range: 0-7
Default Value: 0
This parameter adds support for SR-IOV. It causes the driver to spawn up to
max_vfs worth of virtual function.
Additional Configurations
=========================
Jumbo Frames
------------
Jumbo Frames support is enabled by changing the MTU to a value larger than
the default of 1500. Use the ip command to increase the MTU size.
For example:
ip link set dev eth<x> mtu 9000
This setting is not saved across reboots.
Notes:
- The maximum MTU setting for Jumbo Frames is 9216. This value coincides
with the maximum Jumbo Frames size of 9234 bytes.
- 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
version of ethtool can be found at:
https://www.kernel.org/pub/software/network/ethtool/
Enabling Wake on LAN* (WoL)
---------------------------
WoL is configured 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 igb driver must be
loaded when shutting down or rebooting the system.
Wake On LAN is only supported on port A of multi-port adapters.
Wake On LAN is not supported for the 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.
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.
Support
=======
For general information, go to the Intel support website at:
www.intel.com/support/
or the Intel Wired Networking project hosted by Sourceforge at:
http://sourceforge.net/projects/e1000
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 e1000-devel@lists.sf.net
.. 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:
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. 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/
or the Intel Wired Networking project hosted by Sourceforge at:
https://sourceforge.net/projects/e1000
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 e1000-devel@lists.sf.net.
Linux* Base Driver for Intel(R) Ethernet Network Connection
===========================================================
Intel Gigabit Linux driver.
Copyright(c) 1999 - 2013 Intel Corporation.
Contents
========
- Identifying Your Adapter
- Additional Configurations
- Support
This file describes the igbvf Linux* Base Driver for Intel Network Connection.
The igbvf driver supports 82576-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 igbvf driver requires the igb driver, version 2.0 or later. The igbvf
driver supports virtual functions generated by the igb driver with a max_vfs
value of 1 or greater. For more information on the max_vfs parameter refer
to the README included with the igb driver.
The guest OS loading the igbvf 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 driver. For questions related to hardware requirements, refer to the
documentation supplied with your Intel Gigabit adapter. All hardware
requirements listed apply to use with Linux.
Instructions on updating ethtool can be found in the section "Additional
Configurations" later in this document.
VLANs: There is a limit of a total of 32 shared VLANs to 1 or more VFs.
Identifying Your Adapter
========================
The igbvf driver supports 82576-based virtual function devices that can only
be activated on kernels that support SR-IOV.
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://downloadcenter.intel.com/scripts-df-external/Support_Intel.aspx
Additional Configurations
=========================
ethtool
-------
The driver utilizes the ethtool interface for driver configuration and
diagnostics, as well as displaying statistical information. The ethtool
version 3.0 or later is required for this functionality, although we
strongly recommend downloading the latest version at:
https://www.kernel.org/pub/software/network/ethtool/
Support
=======
For general information, go to the Intel support website at:
http://support.intel.com
or the Intel Wired Networking project hosted by Sourceforge at:
http://sourceforge.net/projects/e1000
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 e1000-devel@lists.sf.net
...@@ -14,6 +14,16 @@ Contents: ...@@ -14,6 +14,16 @@ Contents:
dpaa2/index dpaa2/index
e100 e100
e1000 e1000
e1000e
fm10k
igb
igbvf
ixgb
ixgbe
ixgbevf
i40e
iavf
ice
kapi kapi
z8530book z8530book
msg_zerocopy msg_zerocopy
......
此差异已折叠。
Linux* Base Driver for the Intel(R) Ethernet 10 Gigabit PCI Express Family of
Adapters
=============================================================================
Intel 10 Gigabit Linux driver.
Copyright(c) 1999 - 2013 Intel Corporation.
Contents
========
- Identifying Your Adapter
- Additional Configurations
- Performance Tuning
- Known Issues
- Support
Identifying Your Adapter
========================
The driver in this release is compatible with 82598, 82599 and X540-based
Intel Network Connections.
For more information on how to identify your adapter, go to the Adapter &
Driver ID Guide at:
http://support.intel.com/support/network/sb/CS-012904.htm
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.
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.
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-703SDDZ-IN1
Intel DUAL RATE 1G/10G SFP+ SR (bailed) AFBR-703SDZ-IN2
LR Modules
Intel DUAL RATE 1G/10G SFP+ LR (bailed) FTLX1471D3BCV-IT
Intel DUAL RATE 1G/10G SFP+ LR (bailed) AFCT-701SDDZ-IN1
Intel DUAL RATE 1G/10G SFP+ LR (bailed) AFCT-701SDZ-IN2
The following is a list of 3rd party 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
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
Finistar 1000BASE-T SFP FCLF8522P2BTL
Avago 1000BASE-T SFP ABCU-5710RZ
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 device is down
-------------------------------------------
"ip link set down" turns off the laser for 82599-based SFP+ fiber adapters.
"ip link set up" turns on the laser.
82598-BASED ADAPTERS
NOTES for 82598-Based Adapters:
- Intel(R) Network Adapters that support removable optical modules only support
their original module type (i.e., 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 3rd party 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.
Flow Control
------------
Ethernet Flow Control (IEEE 802.3x) can be configured with ethtool to enable
receiving and transmitting pause frames for ixgbe. When TX is enabled, PAUSE
frames are generated when the receive packet buffer crosses a predefined
threshold. When rx is enabled, the transmit unit will halt for the time delay
specified when a PAUSE frame is received.
Flow Control is enabled by default. If you want to disable a flow control
capable link partner, use ethtool:
ethtool -A eth? autoneg off RX off TX off
NOTE: For 82598 backplane cards entering 1 gig mode, flow control default
behavior is changed to off. Flow control in 1 gig mode on these devices can
lead to Tx hangs.
Intel(R) Ethernet Flow Director
-------------------------------
Supports advanced filters that direct receive packets by 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.
Flow director is enabled only if the kernel is multiple TX queue capable.
An included script (set_irq_affinity.sh) automates setting the IRQ to CPU
affinity.
You can verify that the driver is using Flow Director by looking at the counter
in ethtool: fdir_miss and fdir_match.
Other ethtool Commands:
To enable Flow Director
ethtool -K ethX ntuple on
To add a filter
Use -U switch. e.g., ethtool -U ethX flow-type tcp4 src-ip 10.0.128.23
action 1
To see the list of filters currently present:
ethtool -u ethX
Perfect Filter: Perfect filter 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.
If the queue is defined as -1, filter will drop matching packets.
To account for filter matches and misses, there are two stats in ethtool:
fdir_match and fdir_miss. In addition, rx_queue_N_packets shows the number of
packets processed by the Nth queue.
NOTE: Receive Packet Steering (RPS) and Receive Flow Steering (RFS) are not
compatible with Flow Director. IF Flow Director is enabled, these will be
disabled.
The following three parameters impact Flow Director.
FdirMode
--------
Valid Range: 0-2 (0=off, 1=ATR, 2=Perfect filter mode)
Default Value: 1
Flow Director filtering modes.
FdirPballoc
-----------
Valid Range: 0-2 (0=64k, 1=128k, 2=256k)
Default Value: 0
Flow Director allocated packet buffer size.
AtrSampleRate
--------------
Valid Range: 1-100
Default Value: 20
Software ATR Tx packet sample rate. For example, when set to 20, every 20th
packet, looks to see if the packet will create a new flow.
Node
----
Valid Range: 0-n
Default Value: 1 (off)
0 - n: where n is the number of NUMA nodes (i.e. 0 - 3) currently online in
your system
1: turns this option off
The Node parameter will allow you to pick which NUMA node you want to have
the adapter allocate memory on.
max_vfs
-------
Valid Range: 1-63
Default Value: 0
If the value is greater than 0 it will also force the VMDq parameter to be 1
or more.
This parameter adds support for SR-IOV. It causes the driver to spawn up to
max_vfs worth of virtual function.
Additional Configurations
=========================
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 16110. Use the ip command to
increase the MTU size. For example:
ip link set dev ethx mtu 9000
The maximum MTU setting for Jumbo Frames is 9710. This value coincides
with the maximum Jumbo Frames size of 9728.
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, aka 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 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.
To enable DCB support in ixgbe, you must enable the DCB netlink layer to
allow the userspace tools (see below) to communicate with the driver.
This can be found in the kernel configuration here:
-> Networking support
-> Networking options
-> Data Center Bridging support
Once this is selected, DCB support must be selected for ixgbe. This can
be found here:
-> Device Drivers
-> Network device support (NETDEVICES [=y])
-> Ethernet (10000 Mbit) (NETDEV_10000 [=y])
-> Intel(R) 10GbE PCI Express adapters support
-> Data Center Bridging (DCB) Support
After these options are selected, you must rebuild your kernel and your
modules.
In order to use DCB, userspace tools must be downloaded and installed.
The dcbd tools can be found at:
http://e1000.sf.net
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.
The latest release of ethtool can be found from
https://www.kernel.org/pub/software/network/ethtool/
FCoE
----
This release of the ixgbe driver contains new code to enable users to use
Fiber Channel over Ethernet (FCoE) and Data Center Bridging (DCB)
functionality that is supported by the 82598-based hardware. This code has
no default effect on the regular driver operation, and configuring DCB and
FCoE is outside the scope of this driver README. Refer to
http://www.open-fcoe.org/ for FCoE project information and contact
e1000-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):
Spoof event(s) detected on VF (n)
Where n=the VF that attempted to do the spoofing.
Performance Tuning
==================
An excellent article on performance tuning can be found at:
http://www.redhat.com/promo/summit/2008/downloads/pdf/Thursday/Mark_Wagner.pdf
Known Issues
============
Enabling SR-IOV in a 32-bit or 64-bit Microsoft* Windows* Server 2008/R2
Guest OS using Intel (R) 82576-based GbE or Intel (R) 82599-based 10GbE
controller under 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 using
Intel 82576-based and 82599-based controllers.
While direct assignment of a PCIe device or an SR-IOV Virtual Function (VF)
to a Linux-based VM running 2.6.32 or later kernel works fine, there is a
known issue with Microsoft Windows Server 2008 VM that results in a "yellow
bang" error. This problem is within the KVM VMM itself, not the Intel driver,
or the SR-IOV logic of the VMM, but rather that KVM emulates an older CPU
model for the guests, and this older CPU model does not support MSI-X
interrupts, which is a requirement for Intel SR-IOV.
If you wish to use the Intel 82576 or 82599-based controllers in SR-IOV mode
with KVM and a Microsoft Windows Server 2008 guest try the following
workaround. The workaround is to tell KVM to emulate a different model of CPU
when using qemu to create the KVM guest:
"-cpu qemu64,model=13"
Support
=======
For general information, go to the Intel support website at:
http://support.intel.com
or the Intel Wired Networking project hosted by Sourceforge at:
http://e1000.sourceforge.net
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 e1000-devel@lists.sf.net
.. 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/
or the Intel Wired Networking project hosted by Sourceforge at:
https://sourceforge.net/projects/e1000
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 e1000-devel@lists.sf.net.
Linux* Base Driver for Intel(R) Ethernet Network Connection
===========================================================
Intel Gigabit Linux driver.
Copyright(c) 1999 - 2013 Intel Corporation.
Contents
========
- Identifying Your Adapter
- Known Issues/Troubleshooting
- Support
This file describes the ixgbevf Linux* Base Driver for Intel Network
Connection.
The ixgbevf driver supports 82599-based virtual function devices that can only
be activated on kernels with CONFIG_PCI_IOV enabled.
The ixgbevf driver supports virtual functions generated by the ixgbe driver
with a max_vfs value of 1 or greater.
The guest OS loading the ixgbevf driver must support MSI-X interrupts.
VLANs: There is a limit of a total of 32 shared VLANs to 1 or more VFs.
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
Known Issues/Troubleshooting
============================
Support
=======
For general information, go to the Intel support website at:
http://support.intel.com
or the Intel Wired Networking project hosted by Sourceforge at:
http://sourceforge.net/projects/e1000
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 e1000-devel@lists.sf.net
...@@ -7351,15 +7351,16 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git ...@@ -7351,15 +7351,16 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git
S: Supported S: Supported
F: Documentation/networking/e100.rst F: Documentation/networking/e100.rst
F: Documentation/networking/e1000.rst F: Documentation/networking/e1000.rst
F: Documentation/networking/e1000e.txt F: Documentation/networking/e1000e.rst
F: Documentation/networking/igb.txt F: Documentation/networking/fm10k.rst
F: Documentation/networking/igbvf.txt F: Documentation/networking/igb.rst
F: Documentation/networking/ixgb.txt F: Documentation/networking/igbvf.rst
F: Documentation/networking/ixgbe.txt F: Documentation/networking/ixgb.rst
F: Documentation/networking/ixgbevf.txt F: Documentation/networking/ixgbe.rst
F: Documentation/networking/i40e.txt F: Documentation/networking/ixgbevf.rst
F: Documentation/networking/iavf.txt F: Documentation/networking/i40e.rst
F: Documentation/networking/ice.txt F: Documentation/networking/iavf.rst
F: Documentation/networking/ice.rst
F: drivers/net/ethernet/intel/ F: drivers/net/ethernet/intel/
F: drivers/net/ethernet/intel/*/ F: drivers/net/ethernet/intel/*/
F: include/linux/avf/virtchnl.h F: include/linux/avf/virtchnl.h
......
...@@ -68,6 +68,9 @@ config E1000E ...@@ -68,6 +68,9 @@ config E1000E
<http://support.intel.com> <http://support.intel.com>
More specific information on configuring the driver is in
<file:Documentation/networking/e1000e.rst>.
To compile this driver as a module, choose M here. The module To compile this driver as a module, choose M here. The module
will be called e1000e. will be called e1000e.
...@@ -94,7 +97,7 @@ config IGB ...@@ -94,7 +97,7 @@ config IGB
<http://support.intel.com> <http://support.intel.com>
More specific information on configuring the driver is in More specific information on configuring the driver is in
<file:Documentation/networking/e1000.rst>. <file:Documentation/networking/igb.rst>.
To compile this driver as a module, choose M here. The module To compile this driver as a module, choose M here. The module
will be called igb. will be called igb.
...@@ -130,7 +133,7 @@ config IGBVF ...@@ -130,7 +133,7 @@ config IGBVF
<http://support.intel.com> <http://support.intel.com>
More specific information on configuring the driver is in More specific information on configuring the driver is in
<file:Documentation/networking/e1000.rst>. <file:Documentation/networking/igbvf.rst>.
To compile this driver as a module, choose M here. The module To compile this driver as a module, choose M here. The module
will be called igbvf. will be called igbvf.
...@@ -147,7 +150,7 @@ config IXGB ...@@ -147,7 +150,7 @@ config IXGB
<http://support.intel.com> <http://support.intel.com>
More specific information on configuring the driver is in More specific information on configuring the driver is in
<file:Documentation/networking/ixgb.txt>. <file:Documentation/networking/ixgb.rst>.
To compile this driver as a module, choose M here. The module To compile this driver as a module, choose M here. The module
will be called ixgb. will be called ixgb.
...@@ -164,6 +167,9 @@ config IXGBE ...@@ -164,6 +167,9 @@ config IXGBE
<http://support.intel.com> <http://support.intel.com>
More specific information on configuring the driver is in
<file:Documentation/networking/ixgbe.rst>.
To compile this driver as a module, choose M here. The module To compile this driver as a module, choose M here. The module
will be called ixgbe. will be called ixgbe.
...@@ -205,7 +211,7 @@ config IXGBEVF ...@@ -205,7 +211,7 @@ config IXGBEVF
<http://support.intel.com> <http://support.intel.com>
More specific information on configuring the driver is in More specific information on configuring the driver is in
<file:Documentation/networking/ixgbevf.txt>. <file:Documentation/networking/ixgbevf.rst>.
To compile this driver as a module, choose M here. The module To compile this driver as a module, choose M here. The module
will be called ixgbevf. MSI-X interrupt support is required will be called ixgbevf. MSI-X interrupt support is required
...@@ -222,6 +228,9 @@ config I40E ...@@ -222,6 +228,9 @@ config I40E
<http://support.intel.com> <http://support.intel.com>
More specific information on configuring the driver is in
<file:Documentation/networking/i40e.rst>.
To compile this driver as a module, choose M here. The module To compile this driver as a module, choose M here. The module
will be called i40e. will be called i40e.
...@@ -254,6 +263,9 @@ config I40EVF ...@@ -254,6 +263,9 @@ config I40EVF
This driver was formerly named i40evf. This driver was formerly named i40evf.
More specific information on configuring the driver is in
<file:Documentation/networking/iavf.rst>.
To compile this driver as a module, choose M here. The module To compile this driver as a module, choose M here. The module
will be called iavf. MSI-X interrupt support is required will be called iavf. MSI-X interrupt support is required
for this driver to work correctly. for this driver to work correctly.
...@@ -269,6 +281,9 @@ config ICE ...@@ -269,6 +281,9 @@ config ICE
<http://support.intel.com> <http://support.intel.com>
More specific information on configuring the driver is in
<file:Documentation/networking/ice.rst>.
To compile this driver as a module, choose M here. The module To compile this driver as a module, choose M here. The module
will be called ice. will be called ice.
...@@ -284,6 +299,9 @@ config FM10K ...@@ -284,6 +299,9 @@ config FM10K
<http://support.intel.com> <http://support.intel.com>
More specific information on configuring the driver is in
<file:Documentation/networking/fm10k.rst>.
To compile this driver as a module, choose M here. The module To compile this driver as a module, choose M here. The module
will be called fm10k. MSI-X interrupt support is required will be called fm10k. MSI-X interrupt support is required
......
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册