1ca94d7936
Simon Horman says: ==================== nfp: flower vxlan tunnel offload John says: This patch set allows offloading of TC flower match and set tunnel fields to the NFP. The initial focus is on VXLAN traffic. Due to the current state of the NFP firmware, only VXLAN traffic on well known port 4789 is handled. The match and action fields must explicity set this value to be supported. Tunnel end point information is also offloaded to the NFP for both encapsulation and decapsulation. The NFP expects 3 separate data sets to be supplied. For decapsulation, 2 separate lists exist; a list of MAC addresses referenced by an index comprised of the port number, and a list of IP addresses. These IP addresses are not connected to a MAC or port. The MAC addresses can be written as a block or one at a time (because they have an index, previous values can be overwritten) while the IP addresses are always written as a list of all the available IPs. Because the MAC address used as a tunnel end point may be associated with a physical port or may be a virtual netdev like an OVS bridge, we do not know which addresses should be offloaded. For this reason, all MAC addresses of active netdevs are offloaded to the NFP. A notifier checks for changes to any currently offloaded MACs or any new netdevs that may occur. For IP addresses, the tunnel end point used in the rules is known as the destination IP address must be specified in the flower classifier rule. When a new IP address appears in a rule, the IP address is offloaded. The IP is removed from the offloaded list when all rules matching on that IP are deleted. For encapsulation, a next hop table is updated on the NFP that contains the source/dest IPs, MACs and egress port. These are written individually when requested. If the NFP tries to encapsulate a packet but does not know the next hop, then is sends a request to the host. The host carries out a route lookup and populates the given entry on the NFP table. A notifier also exists to check for any links changing or going down in the kernel next hop table. If an offloaded next hop entry is removed from the kernel then it is also removed on the NFP. The NFP periodically sends a message to the host telling it which tunnel ports have packets egressing the system. The host uses this information to update the used value in the neighbour entry. This means that, rather than expire when it times out, the kernel will send an ARP to check if the link is still live. From an NFP perspective, this means that valid entries will not be removed from its next hop table. ==================== Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Linux kernel ============ This file was moved to Documentation/admin-guide/README.rst Please notice that there are several guides for kernel developers and users. These guides can be rendered in a number of formats, like HTML and PDF. In order to build the documentation, use ``make htmldocs`` or ``make pdfdocs``. There are various text files in the Documentation/ subdirectory, several of them using the Restructured Text markup notation. See Documentation/00-INDEX for a list of what is contained in each file. Please read the Documentation/process/changes.rst file, as it contains the requirements for building and running the kernel, and information about the problems which may result by upgrading your kernel.