1Linux Base Driver for the Intel(R) Ethernet Controller XL710 Family 2=================================================================== 3 4Intel i40e Linux driver. 5Copyright(c) 2013 Intel Corporation. 6 7Contents 8======== 9 10- Identifying Your Adapter 11- Additional Configurations 12- Performance Tuning 13- Known Issues 14- Support 15 16 17Identifying Your Adapter 18======================== 19 20The driver in this release is compatible with the Intel Ethernet 21Controller XL710 Family. 22 23For more information on how to identify your adapter, go to the Adapter & 24Driver ID Guide at: 25 26 http://support.intel.com/support/network/sb/CS-012904.htm 27 28 29Enabling the driver 30=================== 31 32The driver is enabled via the standard kernel configuration system, 33using the make command: 34 35 make config/oldconfig/menuconfig/etc. 36 37The 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 45Additional 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 164Performance Tuning 165================== 166 167An excellent article on performance tuning can be found at: 168 169http://www.redhat.com/promo/summit/2008/downloads/pdf/Thursday/Mark_Wagner.pdf 170 171 172Known Issues 173============ 174 175 176Support 177======= 178 179For general information, go to the Intel support website at: 180 181 http://support.intel.com 182 183or the Intel Wired Networking project hosted by Sourceforge at: 184 185 http://e1000.sourceforge.net 186 187If an issue is identified with the released source code on the supported 188kernel with a supported adapter, email the specific information related 189to the issue to e1000-devel@lists.sourceforge.net and copy 190netdev@vger.kernel.org. 191
