Patch Detail
get:
Show a patch.
patch:
Update a patch.
put:
Update a patch.
GET /api/patches/139825/?format=api
https://patches.dpdk.org/api/patches/139825/?format=api", "web_url": "https://patches.dpdk.org/project/dpdk/patch/20240502213618.11391-13-stephen@networkplumber.org/", "project": { "id": 1, "url": "https://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": "<20240502213618.11391-13-stephen@networkplumber.org>", "list_archive_url": "https://inbox.dpdk.org/dev/20240502213618.11391-13-stephen@networkplumber.org", "date": "2024-05-02T21:31:48", "name": "[v12,12/12] net/tap: update documentation", "commit_ref": null, "pull_url": null, "state": "new", "archived": false, "hash": "446b5531ec0f7cece89954ccddcd52d76e154219", "submitter": { "id": 27, "url": "https://patches.dpdk.org/api/people/27/?format=api", "name": "Stephen Hemminger", "email": "stephen@networkplumber.org" }, "delegate": { "id": 319, "url": "https://patches.dpdk.org/api/users/319/?format=api", "username": "fyigit", "first_name": "Ferruh", "last_name": "Yigit", "email": "ferruh.yigit@amd.com" }, "mbox": "https://patches.dpdk.org/project/dpdk/patch/20240502213618.11391-13-stephen@networkplumber.org/mbox/", "series": [ { "id": 31871, "url": "https://patches.dpdk.org/api/series/31871/?format=api", "web_url": "https://patches.dpdk.org/project/dpdk/list/?series=31871", "date": "2024-05-02T21:31:36", "name": "net/tap: RSS and other fixes", "version": 12, "mbox": "https://patches.dpdk.org/series/31871/mbox/" } ], "comments": "https://patches.dpdk.org/api/patches/139825/comments/", "check": "success", "checks": "https://patches.dpdk.org/api/patches/139825/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 6182E43F6C;\n\tThu, 2 May 2024 23:38:01 +0200 (CEST)", "from mails.dpdk.org (localhost [127.0.0.1])\n\tby mails.dpdk.org (Postfix) with ESMTP id 2585B40DCB;\n\tThu, 2 May 2024 23:36:50 +0200 (CEST)", "from mail-pf1-f181.google.com (mail-pf1-f181.google.com\n [209.85.210.181])\n by mails.dpdk.org (Postfix) with ESMTP id 84E8E402EC\n for <dev@dpdk.org>; Thu, 2 May 2024 23:36:38 +0200 (CEST)", "by mail-pf1-f181.google.com with SMTP id\n d2e1a72fcca58-6ee13f19e7eso7792410b3a.1\n for <dev@dpdk.org>; Thu, 02 May 2024 14:36:38 -0700 (PDT)", "from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226])\n by smtp.gmail.com with ESMTPSA id\n f14-20020a056a001ace00b006f3eee787d5sm1804829pfv.18.2024.05.02.14.36.36\n (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);\n Thu, 02 May 2024 14:36:37 -0700 (PDT)" ], "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1714685798;\n x=1715290598; 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=wGideQ2bpQnfmGJPPC4CFtvQWQFZrTOnVvTIlAIOpQc=;\n b=OuVg3vd/RR6+sUPj9Z++iIEWefu/82boFpLRZT3NYFukn4oRBtpTBeD0UlsK6Ttpe/\n WZNz5IFrqtpyDaIXvDceNHMdN+t/81OorqhqugbBE9S6tMy2eboJ48ATvlOK6LSJ8Jrl\n NOZjXpcE2hgk0vXVgNxyhpua01KSUQe6i5F0tGKEIuI1Npy6qlcynMnc+LrCtgoiMhJ9\n WwpHawcF1zFepPM7tgVoh80bdbw1NaXmhpRynvTKCO0RZA+OP62ZjafwGes1kvXACKE7\n jheOtdjTjNXluLgBqadMcX3jlz2dsV5WXITi8u4xzBCL4qNbIgxiWlxUp36kElpGICS+\n CjCA==", "X-Google-DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20230601; t=1714685798; x=1715290598;\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=wGideQ2bpQnfmGJPPC4CFtvQWQFZrTOnVvTIlAIOpQc=;\n b=InkR/hilIDJ2MgCwgCyb1VJ9DlVEBE6BpNMaePGlCyPOZs2jQWA9bUOkBgaaM9tN0T\n mdtzy1WcSLN1o6PZpls3WXMQPi663ndjOKnuYgxUIylRTcFfYeXv91CCUuPr7BTx5fvQ\n WFUtwMcPa+vkssIMiGLOoGCD34VJc+oWzPs+zGYB02cgsNon+h3LDfunU2UT1ofsZoi+\n mhcelLFJZ8EdLkfas0nT5m4+mddUD/OLwpnMs11I+gjmtN6XxqeqBD9pDPplhQ38tGwe\n Hh/Br/IwTSl1GbE+kWW2kADw4GSIaA717cIyXxFDGoOt2WI3yW6WGy9RNMJoKQvToYpE\n /ynw==", "X-Gm-Message-State": "AOJu0YzgAyJiMPfB0w+CGqzcPzbFKBGMH+JflDm8lG6qmdGPRRNDFQ+t\n DDs1WBV5G6W/ZMRmlRgD0fLB7N876+A/Omjk8quKNgJpcm9DmBVHbzfpe9jVWhBPzStY9843zgh\n U558YQA==", "X-Google-Smtp-Source": "\n AGHT+IF3eRtjg85oy52sSypFP2m7+ml135gBwbm34Vl1YIOwjD6glnImtA709OTp7nfUjQLwa3tMcg==", "X-Received": "by 2002:a05:6a21:3288:b0:1aa:a6dc:38ca with SMTP id\n yt8-20020a056a21328800b001aaa6dc38camr1159870pzb.16.1714685797497;\n Thu, 02 May 2024 14:36:37 -0700 (PDT)", "From": "Stephen Hemminger <stephen@networkplumber.org>", "To": "dev@dpdk.org", "Cc": "Stephen Hemminger <stephen@networkplumber.org>", "Subject": "[PATCH v12 12/12] net/tap: update documentation", "Date": "Thu, 2 May 2024 14:31:48 -0700", "Message-ID": "<20240502213618.11391-13-stephen@networkplumber.org>", "X-Mailer": "git-send-email 2.43.0", "In-Reply-To": "<20240502213618.11391-1-stephen@networkplumber.org>", "References": "<20240130034925.44869-1-stephen@networkplumber.org>\n <20240502213618.11391-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/nics/tap.rst | 274 +++++++------------------\n doc/guides/rel_notes/release_24_07.rst | 7 +\n 2 files changed, 84 insertions(+), 197 deletions(-)", "diff": "diff --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).\ndiff --git a/doc/guides/rel_notes/release_24_07.rst b/doc/guides/rel_notes/release_24_07.rst\nindex a69f24cf99..8652271ed2 100644\n--- a/doc/guides/rel_notes/release_24_07.rst\n+++ b/doc/guides/rel_notes/release_24_07.rst\n@@ -55,6 +55,13 @@ New Features\n Also, make sure to start the actual text at the margin.\n =======================================================\n \n+* **TAP PMD updates.**\n+\n+ * Fixed support of RSS flow action to work with current Linux\n+ kernels and BPF tooling. Will only be enabled if clang and bpftool\n+ are available.\n+\n+ * Support up to 8 queues when used by secondary process\n \n Removed Items\n -------------\n", "prefixes": [ "v12", "12/12" ] }{ "id": 139825, "url": "