Documentation/networking/i40e.txt

   1 Linux Base Driver for the Intel(R) Ethernet Controller XL710 Family
   2 ===================================================================
   3
   4 Intel i40e Linux driver.
   5 Copyright(c) 2013 Intel Corporation.
   6
   7 Contents
   8 ========
   9
  10 - Identifying Your Adapter
  11 - Additional Configurations
  12 - Performance Tuning
  13 - Known Issues
  14 - Support
  15
  16
  17 Identifying Your Adapter
  18 ========================
  19
  20 The driver in this release is compatible with the Intel Ethernet
  21 Controller XL710 Family.
  22
  23 For more information on how to identify your adapter, go to the Adapter &
  24 Driver ID Guide at:
  25
  26     http://support.intel.com/support/network/sb/CS-012904.htm
  27
  28
  29 Enabling the driver
  30 ===================
  31
  32 The driver is enabled via the standard kernel configuration system,
  33 using the make command:
  34
  35      Make oldconfig/silentoldconfig/menuconfig/etc.
  36
  37 The driver is located in the menu structure at:
  38
  39         -> Device Drivers
  40           -> Network device support (NETDEVICES [=y])
  41             -> Ethernet driver support
  42               -> Intel devices
  43                 -> Intel(R) Ethernet Controller XL710 Family
  44
  45 Additional Configurations
  46 =========================
  47
  48   Generic Receive Offload (GRO)
  49   -----------------------------
  50   The driver supports the in-kernel software implementation of GRO.  GRO has
  51   shown that by coalescing Rx traffic into larger chunks of data, CPU
  52   utilization can be significantly reduced when under large Rx load.  GRO is
  53   an evolution of the previously-used LRO interface.  GRO is able to coalesce
  54   other protocols besides TCP.  It's also safe to use with configurations that
  55   are problematic for LRO, namely bridging and iSCSI.
  56
  57   Ethtool
  58   -------
  59   The driver utilizes the ethtool interface for driver configuration and
  60   diagnostics, as well as displaying statistical information. The latest
  61   ethtool version is required for this functionality.
  62
  63   The latest release of ethtool can be found from
  64   https://www.kernel.org/pub/software/network/ethtool
  65
  66
  67   Flow Director n-ntuple traffic filters (FDir)
  68   ---------------------------------------------
  69   The driver utilizes the ethtool interface for configuring ntuple filters,
  70   via "ethtool -N <device> <filter>".
  71
  72   The sctp4, ip4, udp4, and tcp4 flow types are supported with the standard
  73   fields including src-ip, dst-ip, src-port and dst-port. The driver only
  74   supports fully enabling or fully masking the fields, so use of the mask
  75   fields for partial matches is not supported.
  76
  77   Additionally, the driver supports using the action to specify filters for a
  78   Virtual Function. You can specify the action as a 64bit value, where the
  79   lower 32 bits represents the queue number, while the next 8 bits represent
  80   which VF. Note that 0 is the PF, so the VF identifier is offset by 1. For
  81   example:
  82
  83     ... action 0x800000002 ...
  84
  85   Would indicate to direct traffic for Virtual Function 7 (8 minus 1) on queue
  86   2 of that VF.
  87
  88   The driver also supports using the user-defined field to specify 2 bytes of
  89   arbitrary data to match within the packet payload in addition to the regular
  90   fields. The data is specified in the lower 32bits of the user-def field in
  91   the following way:
  92
  93   +----------------------------+---------------------------+
  94   | 31    28    24    20    16 | 15    12     8     4     0|
  95   +----------------------------+---------------------------+
  96   | offset into packet payload |  2 bytes of flexible data |
  97   +----------------------------+---------------------------+
  98
  99   As an example,
 100
 101     ... user-def 0x4FFFF ....
 102
 103   means to match the value 0xFFFF 4 bytes into the packet payload. Note that
 104   the offset is based on the beginning of the payload, and not the beginning
 105   of the packet. Thus
 106
 107     flow-type tcp4 ... user-def 0x8BEAF ....
 108
 109   would match TCP/IPv4 packets which have the value 0xBEAF 8bytes into the
 110   TCP/IPv4 payload.
 111
 112   For ICMP, the hardware parses the ICMP header as 4 bytes of header and 4
 113   bytes of payload, so if you want to match an ICMP frames payload you may need
 114   to add 4 to the offset in order to match the data.
 115
 116   Furthermore, the offset can only be up to a value of 64, as the hardware
 117   will only read up to 64 bytes of data from the payload. It must also be even
 118   as the flexible data is 2 bytes long and must be aligned to byte 0 of the
 119   packet payload.
 120
 121   When programming filters, the hardware is limited to using a single input
 122   set for each flow type. This means that it is an error to program two
 123   different filters with the same type that don't match on the same fields.
 124   Thus the second of the following two commands will fail:
 125
 126     ethtool -N <device> flow-type tcp4 src-ip 192.168.0.7 action 5
 127     ethtool -N <device> flow-type tcp4 dst-ip 192.168.15.18 action 1
 128
 129   This is because the first filter will be accepted and reprogram the input
 130   set for TCPv4 filters, but the second filter will be unable to reprogram the
 131   input set until all the conflicting TCPv4 filters are first removed.
 132
 133   Note that the user-defined flexible offset is also considered part of the
 134   input set and cannot be programmed separately for multiple filters of the
 135   same type. However, the flexible data is not part of the input set and
 136   multiple filters may use the same offset but match against different data.
 137
 138   Data Center Bridging (DCB)
 139   --------------------------
 140   DCB configuration is not currently supported.
 141
 142   FCoE
 143   ----
 144   The driver supports Fiber Channel over Ethernet (FCoE) and Data Center
 145   Bridging (DCB) functionality. Configuring DCB and FCoE is outside the scope
 146   of this driver doc. Refer to http://www.open-fcoe.org/ for FCoE project
 147   information and http://www.open-lldp.org/ or email list
 148   e1000-eedc@lists.sourceforge.net for DCB information.
 149
 150   MAC and VLAN anti-spoofing feature
 151   ----------------------------------
 152   When a malicious driver attempts to send a spoofed packet, it is dropped by
 153   the hardware and not transmitted.  An interrupt is sent to the PF driver
 154   notifying it of the spoof attempt.
 155
 156   When a spoofed packet is detected the PF driver will send the following
 157   message to the system log (displayed by  the "dmesg" command):
 158
 159   Spoof event(s) detected on VF (n)
 160
 161   Where n=the VF that attempted to do the spoofing.
 162
 163
 164 Performance Tuning
 165 ==================
 166
 167 An excellent article on performance tuning can be found at:
 168
 169 http://www.redhat.com/promo/summit/2008/downloads/pdf/Thursday/Mark_Wagner.pdf
 170
 171
 172 Known Issues
 173 ============
 174
 175
 176 Support
 177 =======
 178
 179 For general information, go to the Intel support website at:
 180
 181     http://support.intel.com
 182
 183 or the Intel Wired Networking project hosted by Sourceforge at:
 184
 185     http://e1000.sourceforge.net
 186
 187 If an issue is identified with the released source code on the supported
 188 kernel with a supported adapter, email the specific information related
 189 to the issue to e1000-devel@lists.sourceforge.net and copy
 190 netdev@vger.kernel.org.