Documentation/networking/i40e.txt - arm/linux - Git at Google

 Linux Base Driver for the Intel(R) Ethernet Controller XL710 Family
 ===================================================================

 Intel i40e Linux driver.
 Copyright(c) 2013 Intel Corporation.

 Contents
 ========

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


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

 The driver in this release is compatible with the Intel Ethernet
 Controller XL710 Family.

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

     http://support.intel.com/support/network/sb/CS-012904.htm


 Enabling the driver
 ===================

 The driver is enabled via the standard kernel configuration system,
 using the make command:

      Make oldconfig/silentoldconfig/menuconfig/etc.

 The driver is located in the menu structure at:

 	-> Device Drivers
 	  -> Network device support (NETDEVICES [=y])
 	    -> Ethernet driver support
 	      -> Intel devices
 	        -> Intel(R) Ethernet Controller XL710 Family

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

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

   Ethtool
   -------
   The driver utilizes the ethtool interface for driver configuration and
   diagnostics, as well as displaying statistical information. The latest
   ethtool version is required for this functionality.

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


   Flow Director n-ntuple traffic filters (FDir)
   ---------------------------------------------
   The driver utilizes the ethtool interface for configuring ntuple filters,
   via "ethtool -N <device> <filter>".

   The sctp4, ip4, udp4, and tcp4 flow types are supported with the standard
   fields including src-ip, dst-ip, src-port and dst-port. The driver only
   supports fully enabling or fully masking the fields, so use of the mask
   fields for partial matches is not supported.

   Additionally, the driver supports using the action to specify filters for a
   Virtual Function. You can specify the action as a 64bit value, where the
   lower 32 bits represents the queue number, while the next 8 bits represent
   which VF. Note that 0 is the PF, so the VF identifier is offset by 1. For
   example:

     ... action 0x800000002 ...

   Would indicate to direct traffic for Virtual Function 7 (8 minus 1) on queue
   2 of that VF.

   The driver also supports using the user-defined field to specify 2 bytes of
   arbitrary data to match within the packet payload in addition to the regular
   fields. The data is specified in the lower 32bits of the user-def field in
   the following way:

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

   As an example,

     ... user-def 0x4FFFF ....

   means to match the value 0xFFFF 4 bytes into the packet payload. Note that
   the offset is based on the beginning of the payload, and not the beginning
   of the packet. Thus

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

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

   For ICMP, the hardware parses the ICMP header as 4 bytes of header and 4
   bytes of payload, so if you want to match an ICMP frames payload you may need
   to add 4 to the offset in order to match the data.

   Furthermore, the offset can only be up to a value of 64, as the hardware
   will only read up to 64 bytes of data from the payload. It must also be even
   as the flexible data is 2 bytes long and must be aligned to byte 0 of the
   packet payload.

   When programming filters, the hardware is limited to using a single input
   set for each flow type. This means that it is an error to program two
   different filters with the same type that don't match on the same fields.
   Thus the second of the following two commands will fail:

     ethtool -N <device> flow-type tcp4 src-ip 192.168.0.7 action 5
     ethtool -N <device> flow-type tcp4 dst-ip 192.168.15.18 action 1

   This is because the first filter will be accepted and reprogram the input
   set for TCPv4 filters, but the second filter will be unable to reprogram the
   input set until all the conflicting TCPv4 filters are first removed.

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

   Data Center Bridging (DCB)
   --------------------------
   DCB configuration is not currently supported.

   FCoE
   ----
   The driver supports Fiber Channel over Ethernet (FCoE) and Data Center
   Bridging (DCB) functionality. Configuring DCB and FCoE is outside the scope
   of this driver doc. Refer to http://www.open-fcoe.org/ for FCoE project
   information and http://www.open-lldp.org/ or email list
   e1000-eedc@lists.sourceforge.net for DCB information.

   MAC and VLAN anti-spoofing feature
   ----------------------------------
   When a malicious driver attempts to send a spoofed packet, it is dropped by
   the hardware and not transmitted.  An interrupt is sent to the PF driver
   notifying it of the spoof attempt.

   When a spoofed packet is detected the PF driver will send the following
   message to the system log (displayed by  the "dmesg" command):

   Spoof event(s) detected on VF (n)

   Where n=the VF that attempted to do the spoofing.


 Performance Tuning
 ==================

 An excellent article on performance tuning can be found at:

 http://www.redhat.com/promo/summit/2008/downloads/pdf/Thursday/Mark_Wagner.pdf


 Known Issues
 ============


 Support
 =======

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

     http://support.intel.com

 or the Intel Wired Networking project hosted by Sourceforge at:

     http://e1000.sourceforge.net

 If an issue is identified with the released source code on the supported
 kernel with a supported adapter, email the specific information related
 to the issue to e1000-devel@lists.sourceforge.net and copy
 netdev@vger.kernel.org.
	Linux Base Driver for the Intel(R) Ethernet Controller XL710 Family
	===================================================================

	Intel i40e Linux driver.
	Copyright(c) 2013 Intel Corporation.

	Contents
	========

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


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

	The driver in this release is compatible with the Intel Ethernet
	Controller XL710 Family.

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

	http://support.intel.com/support/network/sb/CS-012904.htm


	Enabling the driver
	===================

	The driver is enabled via the standard kernel configuration system,
	using the make command:

	Make oldconfig/silentoldconfig/menuconfig/etc.

	The driver is located in the menu structure at:

	-> Device Drivers
	-> Network device support (NETDEVICES [=y])
	-> Ethernet driver support
	-> Intel devices
	-> Intel(R) Ethernet Controller XL710 Family

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

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

	Ethtool
	-------
	The driver utilizes the ethtool interface for driver configuration and
	diagnostics, as well as displaying statistical information. The latest
	ethtool version is required for this functionality.

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


	Flow Director n-ntuple traffic filters (FDir)
	---------------------------------------------
	The driver utilizes the ethtool interface for configuring ntuple filters,
	via "ethtool -N <device> <filter>".

	The sctp4, ip4, udp4, and tcp4 flow types are supported with the standard
	fields including src-ip, dst-ip, src-port and dst-port. The driver only
	supports fully enabling or fully masking the fields, so use of the mask
	fields for partial matches is not supported.

	Additionally, the driver supports using the action to specify filters for a
	Virtual Function. You can specify the action as a 64bit value, where the
	lower 32 bits represents the queue number, while the next 8 bits represent
	which VF. Note that 0 is the PF, so the VF identifier is offset by 1. For
	example:

	... action 0x800000002 ...

	Would indicate to direct traffic for Virtual Function 7 (8 minus 1) on queue
	2 of that VF.

	The driver also supports using the user-defined field to specify 2 bytes of
	arbitrary data to match within the packet payload in addition to the regular
	fields. The data is specified in the lower 32bits of the user-def field in
	the following way:

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

	As an example,

	... user-def 0x4FFFF ....

	means to match the value 0xFFFF 4 bytes into the packet payload. Note that
	the offset is based on the beginning of the payload, and not the beginning
	of the packet. Thus

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

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

	For ICMP, the hardware parses the ICMP header as 4 bytes of header and 4
	bytes of payload, so if you want to match an ICMP frames payload you may need
	to add 4 to the offset in order to match the data.

	Furthermore, the offset can only be up to a value of 64, as the hardware
	will only read up to 64 bytes of data from the payload. It must also be even
	as the flexible data is 2 bytes long and must be aligned to byte 0 of the
	packet payload.

	When programming filters, the hardware is limited to using a single input
	set for each flow type. This means that it is an error to program two
	different filters with the same type that don't match on the same fields.
	Thus the second of the following two commands will fail:

	ethtool -N <device> flow-type tcp4 src-ip 192.168.0.7 action 5
	ethtool -N <device> flow-type tcp4 dst-ip 192.168.15.18 action 1

	This is because the first filter will be accepted and reprogram the input
	set for TCPv4 filters, but the second filter will be unable to reprogram the
	input set until all the conflicting TCPv4 filters are first removed.

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

	Data Center Bridging (DCB)
	--------------------------
	DCB configuration is not currently supported.

	FCoE
	----
	The driver supports Fiber Channel over Ethernet (FCoE) and Data Center
	Bridging (DCB) functionality. Configuring DCB and FCoE is outside the scope
	of this driver doc. Refer to http://www.open-fcoe.org/ for FCoE project
	information and http://www.open-lldp.org/ or email list
	e1000-eedc@lists.sourceforge.net for DCB information.

	MAC and VLAN anti-spoofing feature
	----------------------------------
	When a malicious driver attempts to send a spoofed packet, it is dropped by
	the hardware and not transmitted. An interrupt is sent to the PF driver
	notifying it of the spoof attempt.

	When a spoofed packet is detected the PF driver will send the following
	message to the system log (displayed by the "dmesg" command):

	Spoof event(s) detected on VF (n)

	Where n=the VF that attempted to do the spoofing.


	Performance Tuning
	==================

	An excellent article on performance tuning can be found at:

	http://www.redhat.com/promo/summit/2008/downloads/pdf/Thursday/Mark_Wagner.pdf


	Known Issues
	============


	Support
	=======

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

	http://support.intel.com

	or the Intel Wired Networking project hosted by Sourceforge at:

	http://e1000.sourceforge.net

	If an issue is identified with the released source code on the supported
	kernel with a supported adapter, email the specific information related
	to the issue to e1000-devel@lists.sourceforge.net and copy
	netdev@vger.kernel.org.