mirror of
https://github.com/edk2-porting/linux-next.git
synced 2024-12-29 23:53:55 +08:00
911a91c39c
As commit cedd55d49d ("kconfig: Remove silentoldconfig from help
and docs; fix kconfig/conf's help") mentioned, 'silentoldconfig' is a
historical misnomer. That commit removed it from help and docs since
it is an internal interface. If so, it should be allowed to rename
it to something more intuitive. 'syncconfig' is the one I came up
with because it updates the .config if necessary, then synchronize
include/generated/autoconf.h and include/config/* with it.
You should not manually invoke 'silentoldcofig'. Display warning if
used in case existing scripts are doing wrong.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
191 lines
6.6 KiB
Plaintext
191 lines
6.6 KiB
Plaintext
Linux Base Driver for the Intel(R) Ethernet Controller XL710 Family
|
|
===================================================================
|
|
|
|
Intel i40e Linux driver.
|
|
Copyright(c) 2013 Intel Corporation.
|
|
|
|
Contents
|
|
========
|
|
|
|
- Identifying Your Adapter
|
|
- Additional Configurations
|
|
- Performance Tuning
|
|
- Known Issues
|
|
- Support
|
|
|
|
|
|
Identifying Your Adapter
|
|
========================
|
|
|
|
The driver in this release is compatible with the Intel Ethernet
|
|
Controller XL710 Family.
|
|
|
|
For more information on how to identify your adapter, go to the Adapter &
|
|
Driver ID Guide at:
|
|
|
|
http://support.intel.com/support/network/sb/CS-012904.htm
|
|
|
|
|
|
Enabling the driver
|
|
===================
|
|
|
|
The driver is enabled via the standard kernel configuration system,
|
|
using the make command:
|
|
|
|
make config/oldconfig/menuconfig/etc.
|
|
|
|
The driver is located in the menu structure at:
|
|
|
|
-> Device Drivers
|
|
-> Network device support (NETDEVICES [=y])
|
|
-> Ethernet driver support
|
|
-> Intel devices
|
|
-> Intel(R) Ethernet Controller XL710 Family
|
|
|
|
Additional Configurations
|
|
=========================
|
|
|
|
Generic Receive Offload (GRO)
|
|
-----------------------------
|
|
The driver supports the in-kernel software implementation of GRO. GRO has
|
|
shown that by coalescing Rx traffic into larger chunks of data, CPU
|
|
utilization can be significantly reduced when under large Rx load. GRO is
|
|
an evolution of the previously-used LRO interface. GRO is able to coalesce
|
|
other protocols besides TCP. It's also safe to use with configurations that
|
|
are problematic for LRO, namely bridging and iSCSI.
|
|
|
|
Ethtool
|
|
-------
|
|
The driver utilizes the ethtool interface for driver configuration and
|
|
diagnostics, as well as displaying statistical information. The latest
|
|
ethtool version is required for this functionality.
|
|
|
|
The latest release of ethtool can be found from
|
|
https://www.kernel.org/pub/software/network/ethtool
|
|
|
|
|
|
Flow Director n-ntuple traffic filters (FDir)
|
|
---------------------------------------------
|
|
The driver utilizes the ethtool interface for configuring ntuple filters,
|
|
via "ethtool -N <device> <filter>".
|
|
|
|
The sctp4, ip4, udp4, and tcp4 flow types are supported with the standard
|
|
fields including src-ip, dst-ip, src-port and dst-port. The driver only
|
|
supports fully enabling or fully masking the fields, so use of the mask
|
|
fields for partial matches is not supported.
|
|
|
|
Additionally, the driver supports using the action to specify filters for a
|
|
Virtual Function. You can specify the action as a 64bit value, where the
|
|
lower 32 bits represents the queue number, while the next 8 bits represent
|
|
which VF. Note that 0 is the PF, so the VF identifier is offset by 1. For
|
|
example:
|
|
|
|
... action 0x800000002 ...
|
|
|
|
Would indicate to direct traffic for Virtual Function 7 (8 minus 1) on queue
|
|
2 of that VF.
|
|
|
|
The driver also supports using the user-defined field to specify 2 bytes of
|
|
arbitrary data to match within the packet payload in addition to the regular
|
|
fields. The data is specified in the lower 32bits of the user-def field in
|
|
the following way:
|
|
|
|
+----------------------------+---------------------------+
|
|
| 31 28 24 20 16 | 15 12 8 4 0|
|
|
+----------------------------+---------------------------+
|
|
| offset into packet payload | 2 bytes of flexible data |
|
|
+----------------------------+---------------------------+
|
|
|
|
As an example,
|
|
|
|
... user-def 0x4FFFF ....
|
|
|
|
means to match the value 0xFFFF 4 bytes into the packet payload. Note that
|
|
the offset is based on the beginning of the payload, and not the beginning
|
|
of the packet. Thus
|
|
|
|
flow-type tcp4 ... user-def 0x8BEAF ....
|
|
|
|
would match TCP/IPv4 packets which have the value 0xBEAF 8bytes into the
|
|
TCP/IPv4 payload.
|
|
|
|
For ICMP, the hardware parses the ICMP header as 4 bytes of header and 4
|
|
bytes of payload, so if you want to match an ICMP frames payload you may need
|
|
to add 4 to the offset in order to match the data.
|
|
|
|
Furthermore, the offset can only be up to a value of 64, as the hardware
|
|
will only read up to 64 bytes of data from the payload. It must also be even
|
|
as the flexible data is 2 bytes long and must be aligned to byte 0 of the
|
|
packet payload.
|
|
|
|
When programming filters, the hardware is limited to using a single input
|
|
set for each flow type. This means that it is an error to program two
|
|
different filters with the same type that don't match on the same fields.
|
|
Thus the second of the following two commands will fail:
|
|
|
|
ethtool -N <device> flow-type tcp4 src-ip 192.168.0.7 action 5
|
|
ethtool -N <device> flow-type tcp4 dst-ip 192.168.15.18 action 1
|
|
|
|
This is because the first filter will be accepted and reprogram the input
|
|
set for TCPv4 filters, but the second filter will be unable to reprogram the
|
|
input set until all the conflicting TCPv4 filters are first removed.
|
|
|
|
Note that the user-defined flexible offset is also considered part of the
|
|
input set and cannot be programmed separately for multiple filters of the
|
|
same type. However, the flexible data is not part of the input set and
|
|
multiple filters may use the same offset but match against different data.
|
|
|
|
Data Center Bridging (DCB)
|
|
--------------------------
|
|
DCB configuration is not currently supported.
|
|
|
|
FCoE
|
|
----
|
|
The driver supports Fiber Channel over Ethernet (FCoE) and Data Center
|
|
Bridging (DCB) functionality. Configuring DCB and FCoE is outside the scope
|
|
of this driver doc. Refer to http://www.open-fcoe.org/ for FCoE project
|
|
information and http://www.open-lldp.org/ or email list
|
|
e1000-eedc@lists.sourceforge.net for DCB information.
|
|
|
|
MAC and VLAN anti-spoofing feature
|
|
----------------------------------
|
|
When a malicious driver attempts to send a spoofed packet, it is dropped by
|
|
the hardware and not transmitted. An interrupt is sent to the PF driver
|
|
notifying it of the spoof attempt.
|
|
|
|
When a spoofed packet is detected the PF driver will send the following
|
|
message to the system log (displayed by the "dmesg" command):
|
|
|
|
Spoof event(s) detected on VF (n)
|
|
|
|
Where n=the VF that attempted to do the spoofing.
|
|
|
|
|
|
Performance Tuning
|
|
==================
|
|
|
|
An excellent article on performance tuning can be found at:
|
|
|
|
http://www.redhat.com/promo/summit/2008/downloads/pdf/Thursday/Mark_Wagner.pdf
|
|
|
|
|
|
Known Issues
|
|
============
|
|
|
|
|
|
Support
|
|
=======
|
|
|
|
For general information, go to the Intel support website at:
|
|
|
|
http://support.intel.com
|
|
|
|
or the Intel Wired Networking project hosted by Sourceforge at:
|
|
|
|
http://e1000.sourceforge.net
|
|
|
|
If an issue is identified with the released source code on the supported
|
|
kernel with a supported adapter, email the specific information related
|
|
to the issue to e1000-devel@lists.sourceforge.net and copy
|
|
netdev@vger.kernel.org.
|