code:
.. SPDX-License-Identifier: GPL-2.0+

==========================================================
Linux Base Driver for Intel(R) Ethernet Network Connection
==========================================================

Intel Gigabit Linux driver.
Copyright(c) 1999 - 2013 Intel Corporation.

Contents
========

- Identifying Your Adapter
- Command Line Parameters
- Speed and Duplex Configuration
- Additional Configurations
- Support

Identifying Your Adapter
========================

For more information on how to identify your adapter, go to the Adapter &
Driver ID Guide at:

    http://support.intel.com/support/go/network/adapter/idguide.htm

For the latest Intel network drivers for Linux, refer to the following
website.  In the search field, enter your adapter name or type, or use the
networking link on the left to search for your adapter:

    http://support.intel.com/support/go/network/adapter/home.htm

Command Line Parameters
=======================

The default value for each parameter is generally the recommended setting,
unless otherwise noted.

NOTES:
	For more information about the AutoNeg, Duplex, and Speed
        parameters, see the "Speed and Duplex Configuration" section in
        this document.

        For more information about the InterruptThrottleRate,
        RxIntDelay, TxIntDelay, RxAbsIntDelay, and TxAbsIntDelay
        parameters, see the application note at:
        http://www.intel.com/design/network/applnots/ap450.htm

AutoNeg
-------

(Supported only on adapters with copper connections)

:Valid Range:   0x01-0x0F, 0x20-0x2F
:Default Value: 0x2F

This parameter is a bit-mask that specifies the speed and duplex settings
advertised by the adapter.  When this parameter is used, the Speed and
Duplex parameters must not be specified.

NOTE:
       Refer to the Speed and Duplex section of this readme for more
       information on the AutoNeg parameter.

Duplex
------

(Supported only on adapters with copper connections)

:Valid Range:   0-2 (0=auto-negotiate, 1=half, 2=full)
:Default Value: 0

This defines the direction in which data is allowed to flow.  Can be
either one or two-directional.  If both Duplex and the link partner are
set to auto-negotiate, the board auto-detects the correct duplex.  If the
link partner is forced (either full or half), Duplex defaults to half-
duplex.

FlowControl
-----------

:Valid Range:   0-3 (0=none, 1=Rx only, 2=Tx only, 3=Rx&Tx)
:Default Value: Reads flow control settings from the EEPROM

This parameter controls the automatic generation(Tx) and response(Rx)
to Ethernet PAUSE frames.

InterruptThrottleRate
---------------------

(not supported on Intel(R) 82542, 82543 or 82544-based adapters)

:Valid Range:
   0,1,3,4,100-100000 (0=off, 1=dynamic, 3=dynamic conservative,
   4=simplified balancing)
:Default Value: 3

The driver can limit the amount of interrupts per second that the adapter
will generate for incoming packets. It does this by writing a value to the
adapter that is based on the maximum amount of interrupts that the adapter
will generate per second.

Setting InterruptThrottleRate to a value greater or equal to 100
will program the adapter to send out a maximum of that many interrupts
per second, even if more packets have come in. This reduces interrupt
load on the system and can lower CPU utilization under heavy load,
but will increase latency as packets are not processed as quickly.

The default behaviour of the driver previously assumed a static
InterruptThrottleRate value of 8000, providing a good fallback value for
all traffic types,but lacking in small packet performance and latency.
The hardware can handle many more small packets per second however, and
for this reason an adaptive interrupt moderation algorithm was implemented.

Since 7.3.x, the driver has two adaptive modes (setting 1 or 3) in which
it dynamically adjusts the InterruptThrottleRate value based on the traffic
that it receives. After determining the type of incoming traffic in the last
timeframe, it will adjust the InterruptThrottleRate to an appropriate value
for that traffic.

The algorithm classifies the incoming traffic every interval into
classes.  Once the class is determined, the InterruptThrottleRate value is
adjusted to suit that traffic type the best. There are three classes defined:
"Bulk traffic", for large amounts of packets of normal size; "Low latency",
for small amounts of traffic and/or a significant percentage of small
packets; and "Lowest latency", for almost completely small packets or
minimal traffic.

In dynamic conservative mode, the InterruptThrottleRate value is set to 4000
for traffic that falls in class "Bulk traffic". If traffic falls in the "Low
latency" or "Lowest latency" class, the InterruptThrottleRate is increased
stepwise to 20000. This default mode is suitable for most applications.

For situations where low latency is vital such as cluster or
grid computing, the algorithm can reduce latency even more when
InterruptThrottleRate is set to mode 1. In this mode, which operates
the same as mode 3, the InterruptThrottleRate will be increased stepwise to
70000 for traffic in class "Lowest latency".

In simplified mode the interrupt rate is based on the ratio of TX and
RX traffic.  If the bytes per second rate is approximately equal, the
interrupt rate will drop as low as 2000 interrupts per second.  If the
traffic is mostly transmit or mostly receive, the interrupt rate could
be as high as 8000.

Setting InterruptThrottleRate to 0 turns off any interrupt moderation
and may improve small packet latency, but is generally not suitable
for bulk throughput traffic.

NOTE:
       InterruptThrottleRate takes precedence over the TxAbsIntDelay and
       RxAbsIntDelay parameters.  In other words, minimizing the receive
       and/or transmit absolute delays does not force the controller to
       generate more interrupts than what the Interrupt Throttle Rate
       allows.

CAUTION:
          If you are using the Intel(R) PRO/1000 CT Network Connection
          (controller 82547), setting InterruptThrottleRate to a value
          greater than 75,000, may hang (stop transmitting) adapters
          under certain network conditions.  If this occurs a NETDEV
          WATCHDOG message is logged in the system event log.  In
          addition, the controller is automatically reset, restoring
          the network connection.  To eliminate the potential for the
          hang, ensure that InterruptThrottleRate is set no greater
          than 75,000 and is not set to 0.

NOTE:
       When e1000 is loaded with default settings and multiple adapters
       are in use simultaneously, the CPU utilization may increase non-
       linearly.  In order to limit the CPU utilization without impacting
       the overall throughput, we recommend that you load the driver as
       follows::

           modprobe e1000 InterruptThrottleRate=3000,3000,3000

       This sets the InterruptThrottleRate to 3000 interrupts/sec for
       the first, second, and third instances of the driver.  The range
       of 2000 to 3000 interrupts per second works on a majority of
       systems and is a good starting point, but the optimal value will
       be platform-specific.  If CPU utilization is not a concern, use
       RX_POLLING (NAPI) and default driver settings.

RxDescriptors
-------------

:Valid Range:
 - 48-256 for 82542 and 82543-based adapters
 - 48-4096 for all other supported adapters
:Default Value: 256

This value specifies the number of receive buffer descriptors allocated
by the driver.  Increasing this value allows the driver to buffer more
incoming packets, at the expense of increased system memory utilization.

Each descriptor is 16 bytes.  A receive buffer is also allocated for each
descriptor and can be either 2048, 4096, 8192, or 16384 bytes, depending
on the MTU setting. The maximum MTU size is 16110.

NOTE:
       MTU designates the frame size.  It only needs to be set for Jumbo
       Frames.  Depending on the available system resources, the request
       for a higher number of receive descriptors may be denied.  In this
       case, use a lower number.

RxIntDelay
----------

:Valid Range:   0-65535 (0=off)
:Default Value: 0

This value delays the generation of receive interrupts in units of 1.024
microseconds.  Receive interrupt reduction can improve CPU efficiency if
properly tuned for specific network traffic.  Increasing this value adds
extra latency to frame reception and can end up decreasing the throughput
of TCP traffic.  If the system is reporting dropped receives, this value
may be set too high, causing the driver to run out of available receive
descriptors.

CAUTION:
          When setting RxIntDelay to a value other than 0, adapters may
          hang (stop transmitting) under certain network conditions.  If
          this occurs a NETDEV WATCHDOG message is logged in the system
          event log.  In addition, the controller is automatically reset,
          restoring the network connection.  To eliminate the potential
          for the hang ensure that RxIntDelay is set to 0.

RxAbsIntDelay
-------------

(This parameter is supported only on 82540, 82545 and later adapters.)

:Valid Range:   0-65535 (0=off)
:Default Value: 128

This value, in units of 1.024 microseconds, limits the delay in which a
receive interrupt is generated.  Useful only if RxIntDelay is non-zero,
this value ensures that an interrupt is generated after the initial
packet is received within the set amount of time.  Proper tuning,
along with RxIntDelay, may improve traffic throughput in specific network
conditions.

Speed
-----

(This parameter is supported only on adapters with copper connections.)

:Valid Settings: 0, 10, 100, 1000
:Default Value:  0 (auto-negotiate at all supported speeds)

Speed forces the line speed to the specified value in megabits per second
(Mbps).  If this parameter is not specified or is set to 0 and the link
partner is set to auto-negotiate, the board will auto-detect the correct
speed.  Duplex should also be set when Speed is set to either 10 or 100.

TxDescriptors
-------------

:Valid Range:
  - 48-256 for 82542 and 82543-based adapters
  - 48-4096 for all other supported adapters
:Default Value: 256

This value is the number of transmit descriptors allocated by the driver.
Increasing this value allows the driver to queue more transmits.  Each
descriptor is 16 bytes.

NOTE:
       Depending on the available system resources, the request for a
       higher number of transmit descriptors may be denied.  In this case,
       use a lower number.

TxIntDelay
----------

:Valid Range:   0-65535 (0=off)
:Default Value: 8

This value delays the generation of transmit interrupts in units of
1.024 microseconds.  Transmit interrupt reduction can improve CPU
efficiency if properly tuned for specific network traffic.  If the
system is reporting dropped transmits, this value may be set too high
causing the driver to run out of available transmit descriptors.

TxAbsIntDelay
-------------

(This parameter is supported only on 82540, 82545 and later adapters.)

:Valid Range:   0-65535 (0=off)
:Default Value: 32

This value, in units of 1.024 microseconds, limits the delay in which a
transmit interrupt is generated.  Useful only if TxIntDelay is non-zero,
this value ensures that an interrupt is generated after the initial
packet is sent on the wire within the set amount of time.  Proper tuning,
along with TxIntDelay, may improve traffic throughput in specific
network conditions.

XsumRX
------

(This parameter is NOT supported on the 82542-based adapter.)

:Valid Range:   0-1
:Default Value: 1

A value of '1' indicates that the driver should enable IP checksum
offload for received packets (both UDP and TCP) to the adapter hardware.

Copybreak
---------

:Valid Range:   0-xxxxxxx (0=off)
:Default Value: 256
:Usage: modprobe e1000.ko copybreak=128

Driver copies all packets below or equaling this size to a fresh RX
buffer before handing it up the stack.

This parameter is different than other parameters, in that it is a
single (not 1,1,1 etc.) parameter applied to all driver instances and
it is also available during runtime at
/sys/module/e1000/parameters/copybreak

SmartPowerDownEnable
--------------------

:Valid Range: 0-1
:Default Value:  0 (disabled)

Allows PHY to turn off in lower power states. The user can turn off
this parameter in supported chipsets.

Speed and Duplex Configuration
==============================

Three keywords are used to control the speed and duplex configuration.
These keywords are Speed, Duplex, and AutoNeg.

If the board uses a fiber interface, these keywords are ignored, and the
fiber interface board only links at 1000 Mbps full-duplex.

For copper-based boards, the keywords interact as follows:

- The default operation is auto-negotiate.  The board advertises all
  supported speed and duplex combinations, and it links at the highest
  common speed and duplex mode IF the link partner is set to auto-negotiate.

- If Speed = 1000, limited auto-negotiation is enabled and only 1000 Mbps
  is advertised (The 1000BaseT spec requires auto-negotiation.)

- If Speed = 10 or 100, then both Speed and Duplex should be set.  Auto-
  negotiation is disabled, and the AutoNeg parameter is ignored.  Partner
  SHOULD also be forced.

The AutoNeg parameter is used when more control is required over the
auto-negotiation process.  It should be used when you wish to control which
speed and duplex combinations are advertised during the auto-negotiation
process.

The parameter may be specified as either a decimal or hexadecimal value as
determined by the bitmap below.

============== ====== ====== ======= ======= ====== ====== ======= ======
Bit position   7      6      5       4       3      2      1       0
Decimal Value  128    64     32      16      8      4      2       1
Hex value      80     40     20      10      8      4      2       1
Speed (Mbps)   N/A    N/A    1000    N/A     100    100    10      10
Duplex                       Full            Full   Half   Full    Half
============== ====== ====== ======= ======= ====== ====== ======= ======

Some examples of using AutoNeg::

  modprobe e1000 AutoNeg=0x01 (Restricts autonegotiation to 10 Half)
  modprobe e1000 AutoNeg=1 (Same as above)
  modprobe e1000 AutoNeg=0x02 (Restricts autonegotiation to 10 Full)
  modprobe e1000 AutoNeg=0x03 (Restricts autonegotiation to 10 Half or 10 Full)
  modprobe e1000 AutoNeg=0x04 (Restricts autonegotiation to 100 Half)
  modprobe e1000 AutoNeg=0x05 (Restricts autonegotiation to 10 Half or 100
  Half)
  modprobe e1000 AutoNeg=0x020 (Restricts autonegotiation to 1000 Full)
  modprobe e1000 AutoNeg=32 (Same as above)

Note that when this parameter is used, Speed and Duplex must not be specified.

If the link partner is forced to a specific speed and duplex, then this
parameter should not be used.  Instead, use the Speed and Duplex parameters
previously mentioned to force the adapter to the same speed and duplex.

Additional Configurations
=========================

Jumbo Frames
------------

  Jumbo Frames support is enabled by changing the MTU to a value larger than
  the default of 1500.  Use the ifconfig command to increase the MTU size.
  For example::

       ifconfig eth<x> mtu 9000 up

  This setting is not saved across reboots.  It can be made permanent if
  you add::

       MTU=9000

  to the file /etc/sysconfig/network-scripts/ifcfg-eth<x>.  This example
  applies to the Red Hat distributions; other distributions may store this
  setting in a different location.

Notes:
  Degradation in throughput performance may be observed in some Jumbo frames
  environments. If this is observed, increasing the application's socket buffer
  size and/or increasing the /proc/sys/net/ipv4/tcp_*mem entry values may help.
  See the specific application manual and /usr/src/linux*/Documentation/
  networking/ip-sysctl.txt for more details.

  - The maximum MTU setting for Jumbo Frames is 16110.  This value coincides
    with the maximum Jumbo Frames size of 16128.

  - Using Jumbo frames at 10 or 100 Mbps is not supported and may result in
    poor performance or loss of link.

  - Adapters based on the Intel(R) 82542 and 82573V/E controller do not
    support Jumbo Frames. These correspond to the following product names::

     Intel(R) PRO/1000 Gigabit Server Adapter
     Intel(R) PRO/1000 PM Network Connection

ethtool
-------

  The driver utilizes the ethtool interface for driver configuration and
  diagnostics, as well as displaying statistical information.  The ethtool
  version 1.6 or later is required for this functionality.

  The latest release of ethtool can be found from
  https://www.kernel.org/pub/software/network/ethtool/

Enabling Wake on LAN (WoL)
--------------------------

  WoL is configured through the ethtool utility.

  WoL will be enabled on the system during the next shut down or reboot.
  For this driver version, in order to enable WoL, the e1000 driver must be
  loaded when shutting down or rebooting the system.

Support
=======

For general information, go to the Intel support website at:

    http://support.intel.com

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


code:
.. 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.

repo_name: angery/linux


code:
.. SPDX-License-Identifier: GPL-2.0+

=============================================================
Linux Base Driver for Intel(R) Ethernet Multi-host Controller
=============================================================

August 20, 2018
Copyright(c) 2015-2018 Intel Corporation.

Contents
========
- Identifying Your Adapter
- Additional Configurations
- Performance Tuning
- Known Issues
- Support

Identifying Your Adapter
========================
The driver in this release is compatible with devices based on the Intel(R)
Ethernet Multi-host Controller.

For information on how to identify your adapter, and for the latest Intel
network drivers, refer to the Intel Support website:
https://www.intel.com/support

Flow Control
------------
The Intel(R) Ethernet Switch Host Interface Driver does not support Flow
Control. It will not send pause frames. This may result in dropped frames.

Virtual Functions (VFs)
-----------------------
Use sysfs to enable VFs.
Valid Range: 0-64

For example::

    echo $num_vf_enabled > /sys/class/net/$dev/device/sriov_numvfs //enable VFs
    echo 0 > /sys/class/net/$dev/device/sriov_numvfs //disable VFs

NOTE: Neither the device nor the driver control how VFs are mapped into config
space. Bus layout will vary by operating system. On operating systems that
support it, you can check sysfs to find the mapping.

NOTE: When SR-IOV mode is enabled, hardware VLAN filtering and VLAN tag
stripping/insertion will remain enabled. Please remove the old VLAN filter
before the new VLAN filter is added. For example::

    ip link set eth0 vf 0 vlan 100	// set vlan 100 for VF 0
    ip link set eth0 vf 0 vlan 0	// Delete vlan 100
    ip link set eth0 vf 0 vlan 200	// set a new vlan 200 for VF 0

Additional Features and Configurations
======================================

Jumbo Frames
------------
Jumbo Frames support is enabled by changing the Maximum Transmission Unit (MTU)
to a value larger than the default value of 1500.

Use the ifconfig command to increase the MTU size. For example, enter the
following where <x> is the interface number::

    ifconfig eth<x> mtu 9000 up

Alternatively, you can use the ip command as follows::

    ip link set mtu 9000 dev eth<x>
    ip link set up dev eth<x>

This setting is not saved across reboots. The setting change can be made
permanent by adding 'MTU=9000' to the file:

- For RHEL: /etc/sysconfig/network-scripts/ifcfg-eth<x>
- For SLES: /etc/sysconfig/network/<config_file>

NOTE: The maximum MTU setting for Jumbo Frames is 15342. This value coincides
with the maximum Jumbo Frames size of 15364 bytes.

NOTE: This driver will attempt to use multiple page sized buffers to receive
each jumbo packet. This should help to avoid buffer starvation issues when
allocating receive packets.

Generic Receive Offload, aka GRO
--------------------------------
The driver supports the in-kernel software implementation of GRO. GRO has
shown that by coalescing Rx traffic into larger chunks of data, CPU
utilization can be significantly reduced when under large Rx load. GRO is an
evolution of the previously-used LRO interface. GRO is able to coalesce
other protocols besides TCP. It's also safe to use with configurations that
are problematic for LRO, namely bridging and iSCSI.

Supported ethtool Commands and Options for Filtering
----------------------------------------------------
-n --show-nfc
  Retrieves the receive network flow classification configurations.

rx-flow-hash tcp4|udp4|ah4|esp4|sctp4|tcp6|udp6|ah6|esp6|sctp6
  Retrieves the hash options for the specified network traffic type.

-N --config-nfc
  Configures the receive network flow classification.

rx-flow-hash tcp4|udp4|ah4|esp4|sctp4|tcp6|udp6|ah6|esp6|sctp6 m|v|t|s|d|f|n|r
  Configures the hash options for the specified network traffic type.

- udp4: UDP over IPv4
- udp6: UDP over IPv6
- f Hash on bytes 0 and 1 of the Layer 4 header of the rx packet.
- n Hash on bytes 2 and 3 of the Layer 4 header of the rx packet.

Known Issues/Troubleshooting
============================

Enabling SR-IOV in a 64-bit Microsoft Windows Server 2012/R2 guest OS under Linux KVM
-------------------------------------------------------------------------------------
KVM Hypervisor/VMM supports direct assignment of a PCIe device to a VM. This
includes traditional PCIe devices, as well as SR-IOV-capable devices based on
the Intel Ethernet Controller XL710.

Support
=======
For general information, go to the Intel support website at:

https://www.intel.com/support/

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.


code:
.. SPDX-License-Identifier: GPL-2.0+

=================================================================
Linux Base Driver for the Intel(R) Ethernet Controller 700 Series
=================================================================

Intel 40 Gigabit Linux driver.
Copyright(c) 1999-2018 Intel Corporation.

Contents
========

- Overview
- Identifying Your Adapter
- Intel(R) Ethernet Flow Director
- Additional Configurations
- Known Issues
- Support

Driver information can be obtained using ethtool, lspci, and ifconfig.
Instructions on updating ethtool can be found in the section Additional
Configurations later in this document.

For questions related to hardware requirements, refer to the documentation
supplied with your Intel adapter. All hardware requirements listed apply to use
with Linux.

Identifying Your Adapter
========================
The driver is compatible with devices based on the following:

 * Intel(R) Ethernet Controller X710
 * Intel(R) Ethernet Controller XL710
 * Intel(R) Ethernet Network Connection X722
 * Intel(R) Ethernet Controller XXV710

For the best performance, make sure the latest NVM/FW is installed on your
device.

For information on how to identify your adapter, and for the latest NVM/FW
images and Intel network drivers, refer to the Intel Support website:
https://www.intel.com/support

SFP+ and QSFP+ Devices
----------------------
For information about supported media, refer to this document:
https://www.intel.com/content/dam/www/public/us/en/documents/release-notes/xl710-ethernet-controller-feature-matrix.pdf

NOTE: Some adapters based on the Intel(R) Ethernet Controller 700 Series only
support Intel Ethernet Optics modules. On these adapters, other modules are not
supported and will not function.  In all cases Intel recommends using Intel
Ethernet Optics; other modules may function but are not validated by Intel.
Contact Intel for supported media types.

NOTE: For connections based on Intel(R) Ethernet Controller 700 Series, support
is dependent on your system board. Please see your vendor for details.

NOTE: In systems that do not have adequate airflow to cool the adapter and
optical modules, you must use high temperature optical modules.

Virtual Functions (VFs)
-----------------------
Use sysfs to enable VFs. For example::

  #echo $num_vf_enabled > /sys/class/net/$dev/device/sriov_numvfs #enable VFs
  #echo 0 > /sys/class/net/$dev/device/sriov_numvfs #disable VFs

For example, the following instructions will configure PF eth0 and the first VF
on VLAN 10::

  $ ip link set dev eth0 vf 0 vlan 10

VLAN Tag Packet Steering
------------------------
Allows you to send all packets with a specific VLAN tag to a particular SR-IOV
virtual function (VF). Further, this feature allows you to designate a
particular VF as trusted, and allows that trusted VF to request selective
promiscuous mode on the Physical Function (PF).

To set a VF as trusted or untrusted, enter the following command in the
Hypervisor::

  # ip link set dev eth0 vf 1 trust [on|off]

Once the VF is designated as trusted, use the following commands in the VM to
set the VF to promiscuous mode.

::

  For promiscuous all:
  #ip link set eth2 promisc on
  Where eth2 is a VF interface in the VM

  For promiscuous Multicast:
  #ip link set eth2 allmulticast on
  Where eth2 is a VF interface in the VM

NOTE: By default, the ethtool priv-flag vf-true-promisc-support is set to
"off",meaning that promiscuous mode for the VF will be limited. To set the
promiscuous mode for the VF to true promiscuous and allow the VF to see all
ingress traffic, use the following command::

  #ethtool -set-priv-flags p261p1 vf-true-promisc-support on

The vf-true-promisc-support priv-flag does not enable promiscuous mode; rather,
it designates which type of promiscuous mode (limited or true) you will get
when you enable promiscuous mode using the ip link commands above. Note that
this is a global setting that affects the entire device. However,the
vf-true-promisc-support priv-flag is only exposed to the first PF of the
device. The PF remains in limited promiscuous mode (unless it is in MFP mode)
regardless of the vf-true-promisc-support setting.

Now add a VLAN interface on the VF interface::

  #ip link add link eth2 name eth2.100 type vlan id 100

Note that the order in which you set the VF to promiscuous mode and add the
VLAN interface does not matter (you can do either first). The end result in
this example is that the VF will get all traffic that is tagged with VLAN 100.

Intel(R) Ethernet Flow Director
-------------------------------
The Intel Ethernet Flow Director performs the following tasks:

- Directs receive packets according to their flows to different queues.
- Enables tight control on routing a flow in the platform.
- Matches flows and CPU cores for flow affinity.
- Supports multiple parameters for flexible flow classification and load
  balancing (in SFP mode only).

NOTE: The Linux i40e driver supports the following flow types: IPv4, TCPv4, and
UDPv4. For a given flow type, it supports valid combinations of IP addresses
(source or destination) and UDP/TCP ports (source and destination). For
example, you can supply only a source IP address, a source IP address and a
destination port, or any combination of one or more of these four parameters.

NOTE: The Linux i40e driver allows you to filter traffic based on a
user-defined flexible two-byte pattern and offset by using the ethtool user-def
and mask fields. Only L3 and L4 flow types are supported for user-defined
flexible filters. For a given flow type, you must clear all Intel Ethernet Flow
Director filters before changing the input set (for that flow type).

To enable or disable the Intel Ethernet Flow Director::

  # ethtool -K ethX ntuple <on|off>

When disabling ntuple filters, all the user programmed filters are flushed from
the driver cache and hardware. All needed filters must be re-added when ntuple
is re-enabled.

To add a filter that directs packet to queue 2, use -U or -N switch::

  # ethtool -N ethX flow-type tcp4 src-ip 192.168.10.1 dst-ip \
  192.168.10.2 src-port 2000 dst-port 2001 action 2 [loc 1]

To set a filter using only the source and destination IP address::

  # ethtool -N ethX flow-type tcp4 src-ip 192.168.10.1 dst-ip \
  192.168.10.2 action 2 [loc 1]

To see the list of filters currently present::

  # ethtool <-u|-n> ethX

Application Targeted Routing (ATR) Perfect Filters
--------------------------------------------------
ATR is enabled by default when the kernel is in multiple transmit queue mode.
An ATR Intel Ethernet Flow Director filter rule is added when a TCP-IP flow
starts and is deleted when the flow ends. When a TCP-IP Intel Ethernet Flow
Director rule is added from ethtool (Sideband filter), ATR is turned off by the
driver. To re-enable ATR, the sideband can be disabled with the ethtool -K
option. For example::

  ethtool -K [adapter] ntuple [off|on]

If sideband is re-enabled after ATR is re-enabled, ATR remains enabled until a
TCP-IP flow is added. When all TCP-IP sideband rules are deleted, ATR is
automatically re-enabled.

Packets that match the ATR rules are counted in fdir_atr_match stats in
ethtool, which also can be used to verify whether ATR rules still exist.

Sideband Perfect Filters
------------------------
Sideband Perfect Filters are used to direct traffic that matches specified
characteristics. They are enabled through ethtool's ntuple interface. To add a
new filter use the following command::

  ethtool -U <device> flow-type <type> src-ip <ip> dst-ip <ip> src-port <port> \
  dst-port <port> action <queue>

Where:
  <device> - the ethernet device to program
  <type> - can be ip4, tcp4, udp4, or sctp4
  <ip> - the ip address to match on
  <port> - the port number to match on
  <queue> - the queue to direct traffic towards (-1 discards matching traffic)

Use the following command to display all of the active filters::

  ethtool -u <device>

Use the following command to delete a filter::

  ethtool -U <device> delete <N>

Where <N> is the filter id displayed when printing all the active filters, and
may also have been specified using "loc <N>" when adding the filter.

The following example matches TCP traffic sent from 192.168.0.1, port 5300,
directed to 192.168.0.5, port 80, and sends it to queue 7::

  ethtool -U enp130s0 flow-type tcp4 src-ip 192.168.0.1 dst-ip 192.168.0.5 \
  src-port 5300 dst-port 80 action 7

For each flow-type, the programmed filters must all have the same matching
input set. For example, issuing the following two commands is acceptable::

  ethtool -U enp130s0 flow-type ip4 src-ip 192.168.0.1 src-port 5300 action 7
  ethtool -U enp130s0 flow-type ip4 src-ip 192.168.0.5 src-port 55 action 10

Issuing the next two commands, however, is not acceptable, since the first
specifies src-ip and the second specifies dst-ip::

  ethtool -U enp130s0 flow-type ip4 src-ip 192.168.0.1 src-port 5300 action 7
  ethtool -U enp130s0 flow-type ip4 dst-ip 192.168.0.5 src-port 55 action 10

The second command will fail with an error. You may program multiple filters
with the same fields, using different values, but, on one device, you may not
program two tcp4 filters with different matching fields.

Matching on a sub-portion of a field is not supported by the i40e driver, thus
partial mask fields are not supported.

The driver also supports matching user-defined data within the packet payload.
This flexible data is specified using the "user-def" field of the ethtool
command in the following way:

+----------------------------+--------------------------+
| 31    28    24    20    16 | 15    12    8    4    0  |
+----------------------------+--------------------------+
| offset into packet payload | 2 bytes of flexible data |
+----------------------------+--------------------------+

For example,

::

  ... user-def 0x4FFFF ...

tells the filter to look 4 bytes into the payload and match that value against
0xFFFF. The offset is based on the beginning of the payload, and not the
beginning of the packet. Thus

::

  flow-type tcp4 ... user-def 0x8BEAF ...

would match TCP/IPv4 packets which have the value 0xBEAF 8 bytes into the
TCP/IPv4 payload.

Note that ICMP headers are parsed as 4 bytes of header and 4 bytes of payload.
Thus to match the first byte of the payload, you must actually add 4 bytes to
the offset. Also note that ip4 filters match both ICMP frames as well as raw
(unknown) ip4 frames, where the payload will be the L3 payload of the IP4 frame.

The maximum offset is 64. The hardware will only read up to 64 bytes of data
from the payload. The offset must be even because the flexible data is 2 bytes
long and must be aligned to byte 0 of the packet payload.

The user-defined flexible offset is also considered part of the input set and
cannot be programmed separately for multiple filters of the same type. However,
the flexible data is not part of the input set and multiple filters may use the
same offset but match against different data.

To create filters that direct traffic to a specific Virtual Function, use the
"action" parameter. Specify the action as a 64 bit value, where the lower 32
bits represents the queue number, while the next 8 bits represent which VF.
Note that 0 is the PF, so the VF identifier is offset by 1. For example::

  ... action 0x800000002 ...

specifies to direct traffic to Virtual Function 7 (8 minus 1) into queue 2 of
that VF.

Note that these filters will not break internal routing rules, and will not
route traffic that otherwise would not have been sent to the specified Virtual
Function.

Setting the link-down-on-close Private Flag
-------------------------------------------
When the link-down-on-close private flag is set to "on", the port's link will
go down when the interface is brought down using the ifconfig ethX down command.

Use ethtool to view and set link-down-on-close, as follows::

  ethtool --show-priv-flags ethX
  ethtool --set-priv-flags ethX link-down-on-close [on|off]

Viewing Link Messages
---------------------
Link messages will not be displayed to the console if the distribution is
restricting system messages. In order to see network driver link messages on
your console, set dmesg to eight by entering the following::

  dmesg -n 8

NOTE: This setting is not saved across reboots.

Jumbo Frames
------------
Jumbo Frames support is enabled by changing the Maximum Transmission Unit (MTU)
to a value larger than the default value of 1500.

Use the ifconfig command to increase the MTU size. For example, enter the
following where <x> is the interface number::

  ifconfig eth<x> mtu 9000 up

Alternatively, you can use the ip command as follows::

  ip link set mtu 9000 dev eth<x>
  ip link set up dev eth<x>

This setting is not saved across reboots. The setting change can be made
permanent by adding 'MTU=9000' to the file::

  /etc/sysconfig/network-scripts/ifcfg-eth<x> // for RHEL
  /etc/sysconfig/network/<config_file> // for SLES

NOTE: The maximum MTU setting for Jumbo Frames is 9702. This value coincides
with the maximum Jumbo Frames size of 9728 bytes.

NOTE: This driver will attempt to use multiple page sized buffers to receive
each jumbo packet. This should help to avoid buffer starvation issues when
allocating receive packets.

ethtool
-------
The driver utilizes the ethtool interface for driver configuration and
diagnostics, as well as displaying statistical information. The latest ethtool
version is required for this functionality. Download it at:
https://www.kernel.org/pub/software/network/ethtool/

Supported ethtool Commands and Options for Filtering
----------------------------------------------------
-n --show-nfc
  Retrieves the receive network flow classification configurations.

rx-flow-hash tcp4|udp4|ah4|esp4|sctp4|tcp6|udp6|ah6|esp6|sctp6
  Retrieves the hash options for the specified network traffic type.

-N --config-nfc
  Configures the receive network flow classification.

rx-flow-hash tcp4|udp4|ah4|esp4|sctp4|tcp6|udp6|ah6|esp6|sctp6 m|v|t|s|d|f|n|r...
  Configures the hash options for the specified network traffic type.

udp4 UDP over IPv4
udp6 UDP over IPv6

f Hash on bytes 0 and 1 of the Layer 4 header of the Rx packet.
n Hash on bytes 2 and 3 of the Layer 4 header of the Rx packet.

Speed and Duplex Configuration
------------------------------
In addressing speed and duplex configuration issues, you need to distinguish
between copper-based adapters and fiber-based adapters.

In the default mode, an Intel(R) Ethernet Network Adapter using copper
connections will attempt to auto-negotiate with its link partner to determine
the best setting. If the adapter cannot establish link with the link partner
using auto-negotiation, you may need to manually configure the adapter and link
partner to identical settings to establish link and pass packets. This should
only be needed when attempting to link with an older switch that does not
support auto-negotiation or one that has been forced to a specific speed or
duplex mode. Your link partner must match the setting you choose. 1 Gbps speeds
and higher cannot be forced. Use the autonegotiation advertising setting to
manually set devices for 1 Gbps and higher.

NOTE: You cannot set the speed for devices based on the Intel(R) Ethernet
Network Adapter XXV710 based devices.

Speed, duplex, and autonegotiation advertising are configured through the
ethtool utility.

Caution: Only experienced network administrators should force speed and duplex
or change autonegotiation advertising manually. The settings at the switch must
always match the adapter settings. Adapter performance may suffer or your
adapter may not operate if you configure the adapter differently from your
switch.

An Intel(R) Ethernet Network Adapter using fiber-based connections, however,
will not attempt to auto-negotiate with its link partner since those adapters
operate only in full duplex and only at their native speed.

NAPI
----
NAPI (Rx polling mode) is supported in the i40e driver.
For more information on NAPI, see
https://wiki.linuxfoundation.org/networking/napi

Flow Control
------------
Ethernet Flow Control (IEEE 802.3x) can be configured with ethtool to enable
receiving and transmitting pause frames for i40e. When transmit is enabled,
pause frames are generated when the receive packet buffer crosses a predefined
threshold. When receive is enabled, the transmit unit will halt for the time
delay specified when a pause frame is received.

NOTE: You must have a flow control capable link partner.

Flow Control is on by default.

Use ethtool to change the flow control settings.

To enable or disable Rx or Tx Flow Control::

  ethtool -A eth? rx <on|off> tx <on|off>

Note: This command only enables or disables Flow Control if auto-negotiation is
disabled. If auto-negotiation is enabled, this command changes the parameters
used for auto-negotiation with the link partner.

To enable or disable auto-negotiation::

  ethtool -s eth? autoneg <on|off>

Note: Flow Control auto-negotiation is part of link auto-negotiation. Depending
on your device, you may not be able to change the auto-negotiation setting.

RSS Hash Flow
-------------
Allows you to set the hash bytes per flow type and any combination of one or
more options for Receive Side Scaling (RSS) hash byte configuration.

::

  # ethtool -N <dev> rx-flow-hash <type> <option>

Where <type> is:
  tcp4	signifying TCP over IPv4
  udp4	signifying UDP over IPv4
  tcp6	signifying TCP over IPv6
  udp6	signifying UDP over IPv6
And <option> is one or more of:
  s	Hash on the IP source address of the Rx packet.
  d	Hash on the IP destination address of the Rx packet.
  f	Hash on bytes 0 and 1 of the Layer 4 header of the Rx packet.
  n	Hash on bytes 2 and 3 of the Layer 4 header of the Rx packet.

MAC and VLAN anti-spoofing feature
----------------------------------
When a malicious driver attempts to send a spoofed packet, it is dropped by the
hardware and not transmitted.
NOTE: This feature can be disabled for a specific Virtual Function (VF)::

  ip link set <pf dev> vf <vf id> spoofchk {off|on}

IEEE 1588 Precision Time Protocol (PTP) Hardware Clock (PHC)
------------------------------------------------------------
Precision Time Protocol (PTP) is used to synchronize clocks in a computer
network. PTP support varies among Intel devices that support this driver. Use
"ethtool -T <netdev name>" to get a definitive list of PTP capabilities
supported by the device.

IEEE 802.1ad (QinQ) Support
---------------------------
The IEEE 802.1ad standard, informally known as QinQ, allows for multiple VLAN
IDs within a single Ethernet frame. VLAN IDs are sometimes referred to as
"tags," and multiple VLAN IDs are thus referred to as a "tag stack." Tag stacks
allow L2 tunneling and the ability to segregate traffic within a particular
VLAN ID, among other uses.

The following are examples of how to configure 802.1ad (QinQ)::

  ip link add link eth0 eth0.24 type vlan proto 802.1ad id 24
  ip link add link eth0.24 eth0.24.371 type vlan proto 802.1Q id 371

Where "24" and "371" are example VLAN IDs.

NOTES:
  Receive checksum offloads, cloud filters, and VLAN acceleration are not
  supported for 802.1ad (QinQ) packets.

VXLAN and GENEVE Overlay HW Offloading
--------------------------------------
Virtual Extensible LAN (VXLAN) allows you to extend an L2 network over an L3
network, which may be useful in a virtualized or cloud environment. Some
Intel(R) Ethernet Network devices perform VXLAN processing, offloading it from
the operating system. This reduces CPU utilization.

VXLAN offloading is controlled by the Tx and Rx checksum offload options
provided by ethtool. That is, if Tx checksum offload is enabled, and the
adapter has the capability, VXLAN offloading is also enabled.

Support for VXLAN and GENEVE HW offloading is dependent on kernel support of
the HW offloading features.

Multiple Functions per Port
---------------------------
Some adapters based on the Intel Ethernet Controller X710/XL710 support
multiple functions on a single physical port. Configure these functions through
the System Setup/BIOS.

Minimum TX Bandwidth is the guaranteed minimum data transmission bandwidth, as
a percentage of the full physical port link speed, that the partition will
receive. The bandwidth the partition is awarded will never fall below the level
you specify.

The range for the minimum bandwidth values is:
1 to ((100 minus # of partitions on the physical port) plus 1)
For example, if a physical port has 4 partitions, the range would be:
1 to ((100 - 4) + 1 = 97)

The Maximum Bandwidth percentage represents the maximum transmit bandwidth
allocated to the partition as a percentage of the full physical port link
speed. The accepted range of values is 1-100. The value is used as a limiter,
should you chose that any one particular function not be able to consume 100%
of a port's bandwidth (should it be available). The sum of all the values for
Maximum Bandwidth is not restricted, because no more than 100% of a port's
bandwidth can ever be used.

NOTE: X710/XXV710 devices fail to enable Max VFs (64) when Multiple Functions
per Port (MFP) and SR-IOV are enabled. An error from i40e is logged that says
"add vsi failed for VF N, aq_err 16". To workaround the issue, enable less than
64 virtual functions (VFs).

Data Center Bridging (DCB)
--------------------------
DCB is a configuration Quality of Service implementation in hardware. It uses
the VLAN priority tag (802.1p) to filter traffic. That means that there are 8
different priorities that traffic can be filtered into. It also enables
priority flow control (802.1Qbb) which can limit or eliminate the number of
dropped packets during network stress. Bandwidth can be allocated to each of
these priorities, which is enforced at the hardware level (802.1Qaz).

Adapter firmware implements LLDP and DCBX protocol agents as per 802.1AB and
802.1Qaz respectively. The firmware based DCBX agent runs in willing mode only
and can accept settings from a DCBX capable peer. Software configuration of
DCBX parameters via dcbtool/lldptool are not supported.

NOTE: Firmware LLDP can be disabled by setting the private flag disable-fw-lldp.

The i40e driver implements the DCB netlink interface layer to allow user-space
to communicate with the driver and query DCB configuration for the port.

NOTE:
The kernel assumes that TC0 is available, and will disable Priority Flow
Control (PFC) on the device if TC0 is not available. To fix this, ensure TC0 is
enabled when setting up DCB on your switch.

Interrupt Rate Limiting
-----------------------
:Valid Range: 0-235 (0=no limit)

The Intel(R) Ethernet Controller XL710 family supports an interrupt rate
limiting mechanism. The user can control, via ethtool, the number of
microseconds between interrupts.

Syntax::

  # ethtool -C ethX rx-usecs-high N

The range of 0-235 microseconds provides an effective range of 4,310 to 250,000
interrupts per second. The value of rx-usecs-high can be set independently of
rx-usecs and tx-usecs in the same ethtool command, and is also independent of
the adaptive interrupt moderation algorithm. The underlying hardware supports
granularity in 4-microsecond intervals, so adjacent values may result in the
same interrupt rate.

One possible use case is the following::

  # ethtool -C ethX adaptive-rx off adaptive-tx off rx-usecs-high 20 rx-usecs \
    5 tx-usecs 5

The above command would disable adaptive interrupt moderation, and allow a
maximum of 5 microseconds before indicating a receive or transmit was complete.
However, instead of resulting in as many as 200,000 interrupts per second, it
limits total interrupts per second to 50,000 via the rx-usecs-high parameter.

Performance Optimization
========================
Driver defaults are meant to fit a wide variety of workloads, but if further
optimization is required we recommend experimenting with the following settings.

NOTE: For better performance when processing small (64B) frame sizes, try
enabling Hyper threading in the BIOS in order to increase the number of logical
cores in the system and subsequently increase the number of queues available to
the adapter.

Virtualized Environments
------------------------
1. Disable XPS on both ends by using the included virt_perf_default script
or by running the following command as root::

  for file in `ls /sys/class/net/<ethX>/queues/tx-*/xps_cpus`;
  do echo 0 > $file; done

2. Using the appropriate mechanism (vcpupin) in the vm, pin the cpu's to
individual lcpu's, making sure to use a set of cpu's included in the
device's local_cpulist: /sys/class/net/<ethX>/device/local_cpulist.

3. Configure as many Rx/Tx queues in the VM as available. Do not rely on
the default setting of 1.

Non-virtualized Environments
----------------------------
Pin the adapter's IRQs to specific cores by disabling the irqbalance service
and using the included set_irq_affinity script. Please see the script's help
text for further options.

- The following settings will distribute the IRQs across all the cores evenly::

  # scripts/set_irq_affinity -x all <interface1> , [ <interface2>, ... ]

- The following settings will distribute the IRQs across all the cores that are
  local to the adapter (same NUMA node)::

  # scripts/set_irq_affinity -x local <interface1> ,[ <interface2>, ... ]

For very CPU intensive workloads, we recommend pinning the IRQs to all cores.

For IP Forwarding: Disable Adaptive ITR and lower Rx and Tx interrupts per
queue using ethtool.

- Setting rx-usecs and tx-usecs to 125 will limit interrupts to about 8000
  interrupts per second per queue.

::

  # ethtool -C <interface> adaptive-rx off adaptive-tx off rx-usecs 125 \
    tx-usecs 125

For lower CPU utilization: Disable Adaptive ITR and lower Rx and Tx interrupts
per queue using ethtool.

- Setting rx-usecs and tx-usecs to 250 will limit interrupts to about 4000
  interrupts per second per queue.

::

  # ethtool -C <interface> adaptive-rx off adaptive-tx off rx-usecs 250 \
    tx-usecs 250

For lower latency: Disable Adaptive ITR and ITR by setting Rx and Tx to 0 using
ethtool.

::

  # ethtool -C <interface> adaptive-rx off adaptive-tx off rx-usecs 0 \
    tx-usecs 0

Application Device Queues (ADq)
-------------------------------
Application Device Queues (ADq) allows you to dedicate one or more queues to a
specific application. This can reduce latency for the specified application,
and allow Tx traffic to be rate limited per application. Follow the steps below
to set ADq.

1. Create traffic classes (TCs). Maximum of 8 TCs can be created per interface.
The shaper bw_rlimit parameter is optional.

Example: Sets up two tcs, tc0 and tc1, with 16 queues each and max tx rate set
to 1Gbit for tc0 and 3Gbit for tc1.

::

  # tc qdisc add dev <interface> root mqprio num_tc 2 map 0 0 0 0 1 1 1 1
  queues 16@0 16@16 hw 1 mode channel shaper bw_rlimit min_rate 1Gbit 2Gbit
  max_rate 1Gbit 3Gbit

map: priority mapping for up to 16 priorities to tcs (e.g. map 0 0 0 0 1 1 1 1
sets priorities 0-3 to use tc0 and 4-7 to use tc1)

queues: for each tc, <num queues>@<offset> (e.g. queues 16@0 16@16 assigns
16 queues to tc0 at offset 0 and 16 queues to tc1 at offset 16. Max total
number of queues for all tcs is 64 or number of cores, whichever is lower.)

hw 1 mode channel: ‘channel’ with ‘hw’ set to 1 is a new new hardware
offload mode in mqprio that makes full use of the mqprio options, the
TCs, the queue configurations, and the QoS parameters.

shaper bw_rlimit: for each tc, sets minimum and maximum bandwidth rates.
Totals must be equal or less than port speed.

For example: min_rate 1Gbit 3Gbit: Verify bandwidth limit using network
monitoring tools such as `ifstat` or `sar -n DEV [interval] [number of samples]`

2. Enable HW TC offload on interface::

    # ethtool -K <interface> hw-tc-offload on

3. Apply TCs to ingress (RX) flow of interface::

    # tc qdisc add dev <interface> ingress

NOTES:
 - Run all tc commands from the iproute2 <pathtoiproute2>/tc/ directory.
 - ADq is not compatible with cloud filters.
 - Setting up channels via ethtool (ethtool -L) is not supported when the
   TCs are configured using mqprio.
 - You must have iproute2 latest version
 - NVM version 6.01 or later is required.
 - ADq cannot be enabled when any the following features are enabled: Data
   Center Bridging (DCB), Multiple Functions per Port (MFP), or Sideband
   Filters.
 - If another driver (for example, DPDK) has set cloud filters, you cannot
   enable ADq.
 - Tunnel filters are not supported in ADq. If encapsulated packets do
   arrive in non-tunnel mode, filtering will be done on the inner headers.
   For example, for VXLAN traffic in non-tunnel mode, PCTYPE is identified
   as a VXLAN encapsulated packet, outer headers are ignored. Therefore,
   inner headers are matched.
 - If a TC filter on a PF matches traffic over a VF (on the PF), that
   traffic will be routed to the appropriate queue of the PF, and will
   not be passed on the VF. Such traffic will end up getting dropped higher
   up in the TCP/IP stack as it does not match PF address data.
 - If traffic matches multiple TC filters that point to different TCs,
   that traffic will be duplicated and sent to all matching TC queues.
   The hardware switch mirrors the packet to a VSI list when multiple
   filters are matched.

Known Issues/Troubleshooting
============================

NOTE: 1 Gb devices based on the Intel(R) Ethernet Network Connection X722 do
not support the following features:

  * Data Center Bridging (DCB)
  * QOS
  * VMQ
  * SR-IOV
  * Task Encapsulation offload (VXLAN, NVGRE)
  * Energy Efficient Ethernet (EEE)
  * Auto-media detect

Unexpected Issues when the device driver and DPDK share a device
----------------------------------------------------------------
Unexpected issues may result when an i40e device is in multi driver mode and
the kernel driver and DPDK driver are sharing the device. This is because
access to the global NIC resources is not synchronized between multiple
drivers. Any change to the global NIC configuration (writing to a global
register, setting global configuration by AQ, or changing switch modes) will
affect all ports and drivers on the device. Loading DPDK with the
"multi-driver" module parameter may mitigate some of the issues.

TC0 must be enabled when setting up DCB on a switch
---------------------------------------------------
The kernel assumes that TC0 is available, and will disable Priority Flow
Control (PFC) on the device if TC0 is not available. To fix this, ensure TC0 is
enabled when setting up DCB on your switch.

Support
=======
For general information, go to the Intel support website at:

https://www.intel.com/support/

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.


code:
.. SPDX-License-Identifier: GPL-2.0+

=================================================================
Linux Base Driver for Intel(R) Ethernet Adaptive Virtual Function
=================================================================

Intel Ethernet Adaptive Virtual Function Linux driver.
Copyright(c) 2013-2018 Intel Corporation.

Contents
========

- Overview
- Identifying Your Adapter
- Additional Configurations
- Known Issues/Troubleshooting
- Support

Overview
========

This file describes the iavf Linux Base Driver. This driver was formerly
called i40evf.

The iavf driver supports the below mentioned virtual function devices and
can only be activated on kernels running the i40e or newer Physical Function
(PF) driver compiled with CONFIG_PCI_IOV.  The iavf driver requires
CONFIG_PCI_MSI to be enabled.

The guest OS loading the iavf driver must support MSI-X interrupts.

Identifying Your Adapter
========================

The driver in this kernel is compatible with devices based on the following:
 * Intel(R) XL710 X710 Virtual Function
 * Intel(R) X722 Virtual Function
 * Intel(R) XXV710 Virtual Function
 * Intel(R) Ethernet Adaptive Virtual Function

For the best performance, make sure the latest NVM/FW is installed on your
device.

For information on how to identify your adapter, and for the latest NVM/FW
images and Intel network drivers, refer to the Intel Support website:
https://www.intel.com/support

Additional Features and Configurations
======================================

Viewing Link Messages
---------------------
Link messages will not be displayed to the console if the distribution is
restricting system messages. In order to see network driver link messages on
your console, set dmesg to eight by entering the following::

    # dmesg -n 8

NOTE:
  This setting is not saved across reboots.

ethtool
-------
The driver utilizes the ethtool interface for driver configuration and
diagnostics, as well as displaying statistical information. The latest ethtool
version is required for this functionality. Download it at:
https://www.kernel.org/pub/software/network/ethtool/

Setting VLAN Tag Stripping
--------------------------
If you have applications that require Virtual Functions (VFs) to receive
packets with VLAN tags, you can disable VLAN tag stripping for the VF. The
Physical Function (PF) processes requests issued from the VF to enable or
disable VLAN tag stripping. Note that if the PF has assigned a VLAN to a VF,
then requests from that VF to set VLAN tag stripping will be ignored.

To enable/disable VLAN tag stripping for a VF, issue the following command
from inside the VM in which you are running the VF::

    # ethtool -K <if_name> rxvlan on/off

or alternatively::

    # ethtool --offload <if_name> rxvlan on/off

Adaptive Virtual Function
-------------------------
Adaptive Virtual Function (AVF) allows the virtual function driver, or VF, to
adapt to changing feature sets of the physical function driver (PF) with which
it is associated. This allows system administrators to update a PF without
having to update all the VFs associated with it. All AVFs have a single common
device ID and branding string.

AVFs have a minimum set of features known as "base mode," but may provide
additional features depending on what features are available in the PF with
which the AVF is associated. The following are base mode features:

- 4 Queue Pairs (QP) and associated Configuration Status Registers (CSRs)
  for Tx/Rx
- i40e descriptors and ring format
- Descriptor write-back completion
- 1 control queue, with i40e descriptors, CSRs and ring format
- 5 MSI-X interrupt vectors and corresponding i40e CSRs
- 1 Interrupt Throttle Rate (ITR) index
- 1 Virtual Station Interface (VSI) per VF
- 1 Traffic Class (TC), TC0
- Receive Side Scaling (RSS) with 64 entry indirection table and key,
  configured through the PF
- 1 unicast MAC address reserved per VF
- 16 MAC address filters for each VF
- Stateless offloads - non-tunneled checksums
- AVF device ID
- HW mailbox is used for VF to PF communications (including on Windows)

IEEE 802.1ad (QinQ) Support
---------------------------
The IEEE 802.1ad standard, informally known as QinQ, allows for multiple VLAN
IDs within a single Ethernet frame. VLAN IDs are sometimes referred to as
"tags," and multiple VLAN IDs are thus referred to as a "tag stack." Tag stacks
allow L2 tunneling and the ability to segregate traffic within a particular
VLAN ID, among other uses.

The following are examples of how to configure 802.1ad (QinQ)::

    # ip link add link eth0 eth0.24 type vlan proto 802.1ad id 24
    # ip link add link eth0.24 eth0.24.371 type vlan proto 802.1Q id 371

Where "24" and "371" are example VLAN IDs.

NOTES:
  Receive checksum offloads, cloud filters, and VLAN acceleration are not
  supported for 802.1ad (QinQ) packets.

Application Device Queues (ADq)
-------------------------------
Application Device Queues (ADq) allows you to dedicate one or more queues to a
specific application. This can reduce latency for the specified application,
and allow Tx traffic to be rate limited per application. Follow the steps below
to set ADq.

Requirements:

- The sch_mqprio, act_mirred and cls_flower modules must be loaded
- The latest version of iproute2
- If another driver (for example, DPDK) has set cloud filters, you cannot
  enable ADQ
- Depending on the underlying PF device, ADQ cannot be enabled when the
  following features are enabled:

  + Data Center Bridging (DCB)
  + Multiple Functions per Port (MFP)
  + Sideband Filters

1. Create traffic classes (TCs). Maximum of 8 TCs can be created per interface.
The shaper bw_rlimit parameter is optional.

Example: Sets up two tcs, tc0 and tc1, with 16 queues each and max tx rate set
to 1Gbit for tc0 and 3Gbit for tc1.

::

    tc qdisc add dev <interface> root mqprio num_tc 2 map 0 0 0 0 1 1 1 1
    queues 16@0 16@16 hw 1 mode channel shaper bw_rlimit min_rate 1Gbit 2Gbit
    max_rate 1Gbit 3Gbit

map: priority mapping for up to 16 priorities to tcs (e.g. map 0 0 0 0 1 1 1 1
sets priorities 0-3 to use tc0 and 4-7 to use tc1)

queues: for each tc, <num queues>@<offset> (e.g. queues 16@0 16@16 assigns
16 queues to tc0 at offset 0 and 16 queues to tc1 at offset 16. Max total
number of queues for all tcs is 64 or number of cores, whichever is lower.)

hw 1 mode channel: ‘channel’ with ‘hw’ set to 1 is a new new hardware
offload mode in mqprio that makes full use of the mqprio options, the
TCs, the queue configurations, and the QoS parameters.

shaper bw_rlimit: for each tc, sets minimum and maximum bandwidth rates.
Totals must be equal or less than port speed.

For example: min_rate 1Gbit 3Gbit: Verify bandwidth limit using network
monitoring tools such as ``ifstat`` or ``sar -n DEV [interval] [number of samples]``

NOTE:
  Setting up channels via ethtool (ethtool -L) is not supported when the
  TCs are configured using mqprio.

2. Enable HW TC offload on interface::

    # ethtool -K <interface> hw-tc-offload on

3. Apply TCs to ingress (RX) flow of interface::

    # tc qdisc add dev <interface> ingress

NOTES:
 - Run all tc commands from the iproute2 <pathtoiproute2>/tc/ directory
 - ADq is not compatible with cloud filters
 - Setting up channels via ethtool (ethtool -L) is not supported when the TCs
   are configured using mqprio
 - You must have iproute2 latest version
 - NVM version 6.01 or later is required
 - ADq cannot be enabled when any the following features are enabled: Data
   Center Bridging (DCB), Multiple Functions per Port (MFP), or Sideband Filters
 - If another driver (for example, DPDK) has set cloud filters, you cannot
   enable ADq
 - Tunnel filters are not supported in ADq. If encapsulated packets do arrive
   in non-tunnel mode, filtering will be done on the inner headers.  For example,
   for VXLAN traffic in non-tunnel mode, PCTYPE is identified as a VXLAN
   encapsulated packet, outer headers are ignored. Therefore, inner headers are
   matched.
 - If a TC filter on a PF matches traffic over a VF (on the PF), that traffic
   will be routed to the appropriate queue of the PF, and will not be passed on
   the VF. Such traffic will end up getting dropped higher up in the TCP/IP
   stack as it does not match PF address data.
 - If traffic matches multiple TC filters that point to different TCs, that
   traffic will be duplicated and sent to all matching TC queues.  The hardware
   switch mirrors the packet to a VSI list when multiple filters are matched.

Known Issues/Troubleshooting
============================

Bonding fails with VFs bound to an Intel(R) Ethernet Controller 700 series device
---------------------------------------------------------------------------------
If you bind Virtual Functions (VFs) to an Intel(R) Ethernet Controller 700
series based device, the VF slaves may fail when they become the active slave.
If the MAC address of the VF is set by the PF (Physical Function) of the
device, when you add a slave, or change the active-backup slave, Linux bonding
tries to sync the backup slave's MAC address to the same MAC address as the
active slave. Linux bonding will fail at this point. This issue will not occur
if the VF's MAC address is not set by the PF.

Traffic Is Not Being Passed Between VM and Client
-------------------------------------------------
You may not be able to pass traffic between a client system and a
Virtual Machine (VM) running on a separate host if the Virtual Function
(VF, or Virtual NIC) is not in trusted mode and spoof checking is enabled
on the VF. Note that this situation can occur in any combination of client,
host, and guest operating system. For information on how to set the VF to
trusted mode, refer to the section "VLAN Tag Packet Steering" in this
readme document. For information on setting spoof checking, refer to the
section "MAC and VLAN anti-spoofing feature" in this readme document.

Do not unload port driver if VF with active VM is bound to it
-------------------------------------------------------------
Do not unload a port's driver if a Virtual Function (VF) with an active Virtual
Machine (VM) is bound to it. Doing so will cause the port to appear to hang.
Once the VM shuts down, or otherwise releases the VF, the command will complete.

Using four traffic classes fails
--------------------------------
Do not try to reserve more than three traffic classes in the iavf driver. Doing
so will fail to set any traffic classes and will cause the driver to write
errors to stdout. Use a maximum of three queues to avoid this issue.

Multiple log error messages on iavf driver removal
--------------------------------------------------
If you have several VFs and you remove the iavf driver, several instances of
the following log errors are written to the log::

    Unable to send opcode 2 to PF, err I40E_ERR_QUEUE_EMPTY, aq_err ok
    Unable to send the message to VF 2 aq_err 12
    ARQ Overflow Error detected

Virtual machine does not get link
---------------------------------
If the virtual machine has more than one virtual port assigned to it, and those
virtual ports are bound to different physical ports, you may not get link on
all of the virtual ports. The following command may work around the issue::

    # ethtool -r <PF>

Where <PF> is the PF interface in the host, for example: p5p1. You may need to
run the command more than once to get link on all virtual ports.

MAC address of Virtual Function changes unexpectedly
----------------------------------------------------
If a Virtual Function's MAC address is not assigned in the host, then the VF
(virtual function) driver will use a random MAC address. This random MAC
address may change each time the VF driver is reloaded. You can assign a static
MAC address in the host machine. This static MAC address will survive
a VF driver reload.

Driver Buffer Overflow Fix
--------------------------
The fix to resolve CVE-2016-8105, referenced in Intel SA-00069
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00069.html
is included in this and future versions of the driver.

Multiple Interfaces on Same Ethernet Broadcast Network
------------------------------------------------------
Due to the default ARP behavior on Linux, it is not possible to have one system
on two IP networks in the same Ethernet broadcast domain (non-partitioned
switch) behave as expected. All Ethernet interfaces will respond to IP traffic
for any IP address assigned to the system. This results in unbalanced receive
traffic.

If you have multiple interfaces in a server, either turn on ARP filtering by
entering::

    # echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter

NOTE:
  This setting is not saved across reboots. The configuration change can be
  made permanent by adding the following line to the file /etc/sysctl.conf::

    net.ipv4.conf.all.arp_filter = 1

Another alternative is to install the interfaces in separate broadcast domains
(either in different switches or in a switch partitioned to VLANs).

Rx Page Allocation Errors
-------------------------
'Page allocation failure. order:0' errors may occur under stress.
This is caused by the way the Linux kernel reports this stressed condition.

Support
=======
For general information, go to the Intel support website at:

https://support.intel.com

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