Patch Detail
get:
Show a patch.
patch:
Update a patch.
put:
Update a patch.
GET /api/patches/139207/?format=api
{ "id": 139207, "url": "http://patches.dpdk.org/api/patches/139207/?format=api", "web_url": "http://patches.dpdk.org/project/dpdk/patch/20240409034237.433270-9-stephen@networkplumber.org/", "project": { "id": 1, "url": "http://patches.dpdk.org/api/projects/1/?format=api", "name": "DPDK", "link_name": "dpdk", "list_id": "dev.dpdk.org", "list_email": "dev@dpdk.org", "web_url": "http://core.dpdk.org", "scm_url": "git://dpdk.org/dpdk", "webscm_url": "http://git.dpdk.org/dpdk", "list_archive_url": "https://inbox.dpdk.org/dev", "list_archive_url_format": "https://inbox.dpdk.org/dev/{}", "commit_url_format": "" }, "msgid": "<20240409034237.433270-9-stephen@networkplumber.org>", "list_archive_url": "https://inbox.dpdk.org/dev/20240409034237.433270-9-stephen@networkplumber.org", "date": "2024-04-09T03:40:37", "name": "[v8,8/8] doc: update documentation of TAP PMD", "commit_ref": null, "pull_url": null, "state": "superseded", "archived": false, "hash": "aedc45af7337bea24a41877efbb3f57aad55384a", "submitter": { "id": 27, "url": "http://patches.dpdk.org/api/people/27/?format=api", "name": "Stephen Hemminger", "email": "stephen@networkplumber.org" }, "delegate": { "id": 1, "url": "http://patches.dpdk.org/api/users/1/?format=api", "username": "tmonjalo", "first_name": "Thomas", "last_name": "Monjalon", "email": "thomas@monjalon.net" }, "mbox": "http://patches.dpdk.org/project/dpdk/patch/20240409034237.433270-9-stephen@networkplumber.org/mbox/", "series": [ { "id": 31709, "url": "http://patches.dpdk.org/api/series/31709/?format=api", "web_url": "http://patches.dpdk.org/project/dpdk/list/?series=31709", "date": "2024-04-09T03:40:29", "name": "net/tap: cleanups and fix BPF support", "version": 8, "mbox": "http://patches.dpdk.org/series/31709/mbox/" } ], "comments": "http://patches.dpdk.org/api/patches/139207/comments/", "check": "warning", "checks": "http://patches.dpdk.org/api/patches/139207/checks/", "tags": {}, "related": [], "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@inbox.dpdk.org", "Delivered-To": "patchwork@inbox.dpdk.org", "Received": [ "from mails.dpdk.org (mails.dpdk.org [217.70.189.124])\n\tby inbox.dpdk.org (Postfix) with ESMTP id 50B4343DD9;\n\tTue, 9 Apr 2024 05:43:51 +0200 (CEST)", "from mails.dpdk.org (localhost [127.0.0.1])\n\tby mails.dpdk.org (Postfix) with ESMTP id 9F83840A8A;\n\tTue, 9 Apr 2024 05:42:56 +0200 (CEST)", "from mail-pf1-f169.google.com (mail-pf1-f169.google.com\n [209.85.210.169])\n by mails.dpdk.org (Postfix) with ESMTP id BDC544068A\n for <dev@dpdk.org>; Tue, 9 Apr 2024 05:42:46 +0200 (CEST)", "by mail-pf1-f169.google.com with SMTP id\n d2e1a72fcca58-6ecff9df447so3931619b3a.1\n for <dev@dpdk.org>; Mon, 08 Apr 2024 20:42:46 -0700 (PDT)", "from hermes.lan (204-195-96-226.wavecable.com. [204.195.96.226])\n by smtp.gmail.com with ESMTPSA id\n gm24-20020a17090b101800b0029de90f4d44sm9238197pjb.9.2024.04.08.20.42.44\n (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);\n Mon, 08 Apr 2024 20:42:45 -0700 (PDT)" ], "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1712634166;\n x=1713238966; darn=dpdk.org;\n h=content-transfer-encoding:mime-version:references:in-reply-to\n :message-id:date:subject:cc:to:from:from:to:cc:subject:date\n :message-id:reply-to;\n bh=ripfI62aWcyyKcy7T/8SscUCQ7wbKHxjMNdzwCNhxNk=;\n b=mU1BCFYOHaHaBtRYd30HQizGpgb/UEhUoylMEcSNDv1P7zrQrOr4UYT0euxOkyTN4u\n Da5VuGf20MlyTA78q9kcoQJtswElXQFc31lPyajTJrGpAgzWu7+eCJBJacqOVCabwN5b\n lEhEe0OkQ8mjOUD4hCBXyI4JuYX4nDeBgqK2M0AHUC46oCp3lFR5WTWtQLi7Kl6/2FaN\n kPJbSOmWOaDKHgMd/djP34uNguRdWli4qGv41ZGDaBQc0xMJWWPliBFzsgsspqVVoUtu\n oV6R4N4Q0+x2JP4Sd+MhZOVsP8+DJ8/OM+tKBGbRkDIJ74nPdXrpl5cI2nJGxqXxvyPq\n /6IA==", "X-Google-DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20230601; t=1712634166; x=1713238966;\n h=content-transfer-encoding:mime-version:references:in-reply-to\n :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc\n :subject:date:message-id:reply-to;\n bh=ripfI62aWcyyKcy7T/8SscUCQ7wbKHxjMNdzwCNhxNk=;\n b=JcqT6cTIbOPKBCNw4rMP2ZCXRnBfJ+36hlybpUKEJZtMZTot1EkkkFA9ZGU39PCLVN\n HF96ZF3YuqeoLQezzyRXO3xOgJAaAWHrVMJ/JM+TFZ7GmXCg1txhuLmoanMe+fVznVwo\n jaIS6FMFiEdK3VS76GLD8Z2fDoYyblZTWjROC7lSLpEbth2iZ7cVtL/BEajWMEYhbwa4\n iJOB/L2Cu9znOr6jRGAwg4a9Xp/oPuVPpCqKaBkxyMrCAEBWIUPig+TjP/8KYNaN3ku0\n XoMlFYPoOibG6Rpf++BkPVvkvsFtJd7B0tCbIbxjuchgPm+0r3BKb/YjZa92BrWMuwno\n jXLQ==", "X-Gm-Message-State": "AOJu0YyXp/aJyi+NtjQBa74p2uNfhksTzqOOBanWGaGOw2H7psseYloo\n JfmgdSC+TfbBWmmzvqxno1tXUXqhf/MHenBJjhiB6xLVxkRErCC9ZIdaNFUAytyePaRuwlMqMbm\n rR2Q=", "X-Google-Smtp-Source": "\n AGHT+IHvBSQRpXbFyohRt9oqXtHciOfGNOMeHJJ0WvZZDAJ4pS8Zhd7wMgpSDjLLIBuH77KEnDWKXg==", "X-Received": "by 2002:a05:6a20:7f95:b0:1a3:c4f8:7710 with SMTP id\n d21-20020a056a207f9500b001a3c4f87710mr13470760pzj.4.1712634165660;\n Mon, 08 Apr 2024 20:42:45 -0700 (PDT)", "From": "Stephen Hemminger <stephen@networkplumber.org>", "To": "dev@dpdk.org", "Cc": "Stephen Hemminger <stephen@networkplumber.org>", "Subject": "[PATCH v8 8/8] doc: update documentation of TAP PMD", "Date": "Mon, 8 Apr 2024 20:40:37 -0700", "Message-ID": "<20240409034237.433270-9-stephen@networkplumber.org>", "X-Mailer": "git-send-email 2.43.0", "In-Reply-To": "<20240409034237.433270-1-stephen@networkplumber.org>", "References": "<20240130034925.44869-1-stephen@networkplumber.org>\n <20240409034237.433270-1-stephen@networkplumber.org>", "MIME-Version": "1.0", "Content-Transfer-Encoding": "8bit", "X-BeenThere": "dev@dpdk.org", "X-Mailman-Version": "2.1.29", "Precedence": "list", "List-Id": "DPDK patches and discussions <dev.dpdk.org>", "List-Unsubscribe": "<https://mails.dpdk.org/options/dev>,\n <mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://mails.dpdk.org/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<https://mails.dpdk.org/listinfo/dev>,\n <mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org" }, "content": "The driver support of flows has changed and the wording in\nthe guide was awkward.\n\nDrop references to DPDK pktgen in this documentation since\nit is not required and confusing.\n\nSigned-off-by: Stephen Hemminger <stephen@networkplumber.org>\n---\n doc/guides/linux_gsg/sys_reqs.rst | 3 +\n doc/guides/nics/tap.rst | 274 +++++++++---------------------\n 2 files changed, 80 insertions(+), 197 deletions(-)", "diff": "diff --git a/doc/guides/linux_gsg/sys_reqs.rst b/doc/guides/linux_gsg/sys_reqs.rst\nindex 13be715933..0254568517 100644\n--- a/doc/guides/linux_gsg/sys_reqs.rst\n+++ b/doc/guides/linux_gsg/sys_reqs.rst\n@@ -101,6 +101,9 @@ Running DPDK Applications\n \n To run a DPDK application, some customization may be required on the target machine.\n \n+.. _linux_gsg_kernel_version:\n+\n+\n System Software\n ~~~~~~~~~~~~~~~\n \ndiff --git a/doc/guides/nics/tap.rst b/doc/guides/nics/tap.rst\nindex d4f45c02a1..55e38fb25b 100644\n--- a/doc/guides/nics/tap.rst\n+++ b/doc/guides/nics/tap.rst\n@@ -1,47 +1,51 @@\n .. SPDX-License-Identifier: BSD-3-Clause\n Copyright(c) 2016 Intel Corporation.\n \n-Tun|Tap Poll Mode Driver\n-========================\n+TAP Poll Mode Driver\n+====================\n \n-The ``rte_eth_tap.c`` PMD creates a device using TAP interfaces on the\n-local host. The PMD allows for DPDK and the host to communicate using a raw\n-device interface on the host and in the DPDK application.\n+The TAP Poll Mode Driver (PMD) is a virtual device for injecting packets to be processed\n+by the Linux kernel. This PMD is useful when writing DPDK application\n+for offloading network functionality (such as tunneling) from the kernel.\n \n-The device created is a TAP device, which sends/receives packet in a raw\n-format with a L2 header. The usage for a TAP PMD is for connectivity to the\n-local host using a TAP interface. When the TAP PMD is initialized it will\n-create a number of tap devices in the host accessed via ``ifconfig -a`` or\n-``ip`` command. The commands can be used to assign and query the virtual like\n-device.\n+From the kernel point of view, the TAP device looks like a regular network interface.\n+The network device can be managed by standard tools such as ``ip`` and ``ethtool`` commands.\n+It is also possible to use existing packet tools such as ``wireshark`` or ``tcpdump``.\n \n-These TAP interfaces can be used with Wireshark or tcpdump or Pktgen-DPDK\n-along with being able to be used as a network connection to the DPDK\n-application. The method enable one or more interfaces is to use the\n-``--vdev=net_tap0`` option on the DPDK application command line. Each\n-``--vdev=net_tap1`` option given will create an interface named dtap0, dtap1,\n-and so on.\n+From the DPDK application, the TAP device looks like a DPDK ethdev.\n+Packets are sent and received in L2 (Ethernet) format. The standare DPDK\n+API's to query for information, statistics and send and receive packets\n+work as expected.\n \n-The interface name can be changed by adding the ``iface=foo0``, for example::\n+Requirements\n+~~~~~~~~~~~~\n+\n+The TAP PMD requires kernel support for multiple queues in TAP device as\n+well as the multi-queue ``multiq`` and incoming ``ingress`` queue disciplines.\n+These are standard kernel features in most Linux distributions.\n+\n+Arguments\n+---------\n+\n+TAP devices are created with the command line\n+``--vdev=net_tap0`` option. This option maybe specified more the once by repeating\n+with a different ``net_tapX`` device.\n+\n+By default, the Linux interfaces are named ``dtap0``, ``dtap1``, etc.\n+The interface name can be specified by adding the ``iface=foo0``, for example::\n \n --vdev=net_tap0,iface=foo0 --vdev=net_tap1,iface=foo1, ...\n \n-Normally the PMD will generate a random MAC address, but when testing or with\n-a static configuration the developer may need a fixed MAC address style.\n-Using the option ``mac=fixed`` you can create a fixed known MAC address::\n+Normally the PMD will generate a random MAC address.\n+If a static address is desired instead, the ``mac=fixed`` can be used.\n \n --vdev=net_tap0,mac=fixed\n \n-The MAC address will have a fixed value with the last octet incrementing by one\n-for each interface string containing ``mac=fixed``. The MAC address is formatted\n-as 02:'d':'t':'a':'p':[00-FF]. Convert the characters to hex and you get the\n-actual MAC address: ``02:64:74:61:70:[00-FF]``.\n-\n- --vdev=net_tap0,mac=\"02:64:74:61:70:11\"\n+With the fixed option, the MAC address will have the first octets:\n+as 02:'d':'t':'a':'p':[00-FF] and the last octets are the interface number.\n \n-The MAC address will have a user value passed as string. The MAC address is in\n-format with delimiter ``:``. The string is byte converted to hex and you get\n-the actual MAC address: ``02:64:74:61:70:11``.\n+To specify a specific MAC address use the conventional representation.\n+The string is byte converted to hex, the result is MAC address: ``02:64:74:61:70:11``.\n \n It is possible to specify a remote netdevice to capture packets from by adding\n ``remote=foo1``, for example::\n@@ -59,40 +63,20 @@ netdevice that has no support in the DPDK. It is possible to add explicit\n rte_flow rules on the tap PMD to capture specific traffic (see next section for\n examples).\n \n-After the DPDK application is started you can send and receive packets on the\n-interface using the standard rx_burst/tx_burst APIs in DPDK. From the host\n-point of view you can use any host tool like tcpdump, Wireshark, ping, Pktgen\n-and others to communicate with the DPDK application. The DPDK application may\n-not understand network protocols like IPv4/6, UDP or TCP unless the\n-application has been written to understand these protocols.\n-\n-If you need the interface as a real network interface meaning running and has\n-a valid IP address then you can do this with the following commands::\n-\n- sudo ip link set dtap0 up; sudo ip addr add 192.168.0.250/24 dev dtap0\n- sudo ip link set dtap1 up; sudo ip addr add 192.168.1.250/24 dev dtap1\n-\n-Please change the IP addresses as you see fit.\n-\n-If routing is enabled on the host you can also communicate with the DPDK App\n-over the internet via a standard socket layer application as long as you\n-account for the protocol handling in the application.\n-\n-If you have a Network Stack in your DPDK application or something like it you\n-can utilize that stack to handle the network protocols. Plus you would be able\n-to address the interface using an IP address assigned to the internal\n-interface.\n-\n Normally, when the DPDK application exits,\n the TAP device is marked down and is removed.\n-But this behaviour can be overridden by the use of the persist flag, example::\n+But this behavior can be overridden by the use of the persist flag, example::\n \n --vdev=net_tap0,iface=tap0,persist ...\n \n-The TUN PMD allows user to create a TUN device on host. The PMD allows user\n-to transmit and receive packets via DPDK API calls with L3 header and payload.\n-The devices in host can be accessed via ``ifconfig`` or ``ip`` command. TUN\n-interfaces are passed to DPDK ``rte_eal_init`` arguments as ``--vdev=net_tunX``,\n+TUN devices\n+-----------\n+\n+The TAP device can be used an L3 tunnel only device (TUN).\n+This type of device does not include the Ethernet (L2) header; all packets\n+are sent and received as IP packets.\n+\n+TUN devices are created with the command line arguments ``--vdev=net_tunX``,\n where X stands for unique id, example::\n \n --vdev=net_tun0 --vdev=net_tun1,iface=foo1, ...\n@@ -103,27 +87,33 @@ options. Default interface name is ``dtunX``, where X stands for unique id.\n Flow API support\n ----------------\n \n-The tap PMD supports major flow API pattern items and actions, when running on\n-linux kernels above 4.2 (\"Flower\" classifier required).\n-The kernel support can be checked with this command::\n+The TAP PMD supports major flow API pattern items and actions.\n+\n+Requirements\n+~~~~~~~~~~~~\n \n- zcat /proc/config.gz | ( grep 'CLS_FLOWER=' || echo 'not supported' ) |\n- tee -a /dev/stderr | grep -q '=m' &&\n- lsmod | ( grep cls_flower || echo 'try modprobe cls_flower' )\n+Flow support in TAP driver requires the Linux kernel support of flow based\n+traffic control filter ``flower``. This was added in Linux 4.3 kernel.\n \n-Supported items:\n+The implementation of RSS action uses an eBPF module that requires additional\n+libraries and tools. Building the RSS support requires the ``clang``\n+compiler to compile the C code to BPF target; ``bpftool`` to convert the\n+compiled BPF object to a header file; and ``libbpf`` to load the eBPF\n+action into the kernel.\n \n-- eth: src and dst (with variable masks), and eth_type (0xffff mask).\n-- vlan: vid, pcp, but not eid. (requires kernel 4.9)\n-- ipv4/6: src and dst (with variable masks), and ip_proto (0xffff mask).\n-- udp/tcp: src and dst port (0xffff) mask.\n+Supported match items:\n+\n+ - eth: src and dst (with variable masks), and eth_type (0xffff mask).\n+ - vlan: vid, pcp, but not eid. (requires kernel 4.9)\n+ - ipv4/6: src and dst (with variable masks), and ip_proto (0xffff mask).\n+ - udp/tcp: src and dst port (0xffff) mask.\n \n Supported actions:\n \n - DROP\n - QUEUE\n - PASSTHRU\n-- RSS (requires kernel 4.9)\n+- RSS\n \n It is generally not possible to provide a \"last\" item. However, if the \"last\"\n item, once masked, is identical to the masked spec, then it is supported.\n@@ -133,7 +123,7 @@ full mask (exact match).\n \n As rules are translated to TC, it is possible to show them with something like::\n \n- tc -s filter show dev tap1 parent 1:\n+ tc -s filter show dev dtap1 parent 1:\n \n Examples of testpmd flow rules\n ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n@@ -174,135 +164,25 @@ The IPC synchronization of Rx/Tx queues is currently limited:\n - Maximum 8 queues shared\n - Synchronized on probing, but not on later port update\n \n-Example\n--------\n-\n-The following is a simple example of using the TAP PMD with the Pktgen\n-packet generator. It requires that the ``socat`` utility is installed on the\n-test system.\n-\n-Build DPDK, then pull down Pktgen and build pktgen using the DPDK SDK/Target\n-used to build the dpdk you pulled down.\n-\n-Run pktgen from the pktgen directory in a terminal with a commandline like the\n-following::\n-\n- sudo ./app/app/x86_64-native-linux-gcc/app/pktgen -l 1-5 -n 4 \\\n- --proc-type auto --log-level debug --socket-mem 512,512 --file-prefix pg \\\n- --vdev=net_tap0 --vdev=net_tap1 -b 05:00.0 -b 05:00.1 \\\n- -b 04:00.0 -b 04:00.1 -b 04:00.2 -b 04:00.3 \\\n- -b 81:00.0 -b 81:00.1 -b 81:00.2 -b 81:00.3 \\\n- -b 82:00.0 -b 83:00.0 -- -T -P -m [2:3].0 -m [4:5].1 \\\n- -f themes/black-yellow.theme\n-\n-.. Note:\n-\n- Change the ``-b`` options to exclude all of your physical ports. The\n- following command line is all one line.\n-\n- Also, ``-f themes/black-yellow.theme`` is optional if the default colors\n- work on your system configuration. See the Pktgen docs for more\n- information.\n-\n-Verify with ``ifconfig -a`` command in a different xterm window, should have a\n-``dtap0`` and ``dtap1`` interfaces created.\n-\n-Next set the links for the two interfaces to up via the commands below::\n-\n- sudo ip link set dtap0 up; sudo ip addr add 192.168.0.250/24 dev dtap0\n- sudo ip link set dtap1 up; sudo ip addr add 192.168.1.250/24 dev dtap1\n-\n-Then use socat to create a loopback for the two interfaces::\n-\n- sudo socat interface:dtap0 interface:dtap1\n-\n-Then on the Pktgen command line interface you can start sending packets using\n-the commands ``start 0`` and ``start 1`` or you can start both at the same\n-time with ``start all``. The command ``str`` is an alias for ``start all`` and\n-``stp`` is an alias for ``stop all``.\n-\n-While running you should see the 64 byte counters increasing to verify the\n-traffic is being looped back. You can use ``set all size XXX`` to change the\n-size of the packets after you stop the traffic. Use pktgen ``help``\n-command to see a list of all commands. You can also use the ``-f`` option to\n-load commands at startup in command line or Lua script in pktgen.\n \n RSS specifics\n -------------\n-Packet distribution in TAP is done by the kernel which has a default\n-distribution. This feature is adding RSS distribution based on eBPF code.\n-The default eBPF code calculates RSS hash based on Toeplitz algorithm for\n-a fixed RSS key. It is calculated on fixed packet offsets. For IPv4 and IPv6 it\n-is calculated over src/dst addresses (8 or 32 bytes for IPv4 or IPv6\n-respectively) and src/dst TCP/UDP ports (4 bytes).\n-\n-The RSS algorithm is written in file ``tap_bpf_program.c`` which\n-does not take part in TAP PMD compilation. Instead this file is compiled\n-in advance to eBPF object file. The eBPF object file is then parsed and\n-translated into eBPF byte code in the format of C arrays of eBPF\n-instructions. The C array of eBPF instructions is part of TAP PMD tree and\n-is taking part in TAP PMD compilation. At run time the C arrays are uploaded to\n-the kernel via BPF system calls and the RSS hash is calculated by the\n-kernel.\n-\n-It is possible to support different RSS hash algorithms by updating file\n-``tap_bpf_program.c`` In order to add a new RSS hash algorithm follow these\n-steps:\n-\n-#. Write the new RSS implementation in file ``tap_bpf_program.c``\n-\n- BPF programs which are uploaded to the kernel correspond to\n- C functions under different ELF sections.\n-\n-#. Install ``LLVM`` library and ``clang`` compiler versions 3.7 and above\n-\n-#. Use make to compile `tap_bpf_program.c`` via ``LLVM`` into an object file\n- and extract the resulting instructions into ``tap_bpf_insn.h``::\n-\n- cd bpf; make\n-\n-#. Recompile the TAP PMD.\n-\n-The C arrays are uploaded to the kernel using BPF system calls.\n-\n-``tc`` (traffic control) is a well known user space utility program used to\n-configure the Linux kernel packet scheduler. It is usually packaged as\n-part of the ``iproute2`` package.\n-Since commit 11c39b5e9 (\"tc: add eBPF support to f_bpf\") ``tc`` can be used\n-to uploads eBPF code to the kernel and can be patched in order to print the\n-C arrays of eBPF instructions just before calling the BPF system call.\n-Please refer to ``iproute2`` package file ``lib/bpf.c`` function\n-``bpf_prog_load()``.\n-\n-An example utility for eBPF instruction generation in the format of C arrays will\n-be added in next releases\n-\n-TAP reports on supported RSS functions as part of dev_infos_get callback:\n-``RTE_ETH_RSS_IP``, ``RTE_ETH_RSS_UDP`` and ``RTE_ETH_RSS_TCP``.\n-**Known limitation:** TAP supports all of the above hash functions together\n-and not in partial combinations.\n-\n-Systems supporting flow API\n----------------------------\n-\n-- \"tc flower\" classifier requires linux kernel above 4.2\n-- eBPF/RSS requires linux kernel above 4.9\n-\n-+--------------------+-----------------------+\n-| RH7.3 | No flow rule support |\n-+--------------------+-----------------------+\n-| RH7.4 | No RSS action support |\n-+--------------------+-----------------------+\n-| RH7.5 | No RSS action support |\n-+--------------------+-----------------------+\n-| SLES 15, | No limitation |\n-| kernel 4.12 | |\n-+--------------------+-----------------------+\n-| Azure Ubuntu 16.04,| No limitation |\n-| kernel 4.13 | |\n-+--------------------+-----------------------+\n+The default packet distribution in TAP without flow rules is done by the\n+kernel which has a default flow based distribution.\n+When flow rules are used to distribute packets across a set of queues\n+an eBPF program is used to calculate the RSS based on Toeplitz algorithm for\n+with the given key.\n+\n+The hash is calculated for IPv4 and IPv6, over src/dst addresses\n+(8 or 32 bytes for IPv4 or IPv6 respectively) and\n+optionally the src/dst TCP/UDP ports (4 bytes).\n+\n \n Limitations\n -----------\n \n-* Rx/Tx must have the same number of queues.\n+- Since TAP device uses a file descriptors to talk to the kernel.\n+ The same number of queues must be specified for receive and transmit.\n+\n+- The RSS algorithm only support L3 or L4 functions. It does not support\n+ finer grain selections (for example: only IPV6 packets with extension headers).\n", "prefixes": [ "v8", "8/8" ] }