Cover Detail
Show a cover letter.
GET /api/covers/77543/?format=api
{ "id": 77543, "url": "http://patches.dpdk.org/api/covers/77543/?format=api", "web_url": "http://patches.dpdk.org/project/dpdk/cover/1600012140-70151-1-git-send-email-bingz@nvidia.com/", "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": "<1600012140-70151-1-git-send-email-bingz@nvidia.com>", "list_archive_url": "https://inbox.dpdk.org/dev/1600012140-70151-1-git-send-email-bingz@nvidia.com", "date": "2020-09-13T15:48:56", "name": "[RFC,v2,0/4] introduce support for hairpin between two ports", "submitter": { "id": 1976, "url": "http://patches.dpdk.org/api/people/1976/?format=api", "name": "Bing Zhao", "email": "bingz@nvidia.com" }, "mbox": "http://patches.dpdk.org/project/dpdk/cover/1600012140-70151-1-git-send-email-bingz@nvidia.com/mbox/", "series": [ { "id": 12169, "url": "http://patches.dpdk.org/api/series/12169/?format=api", "web_url": "http://patches.dpdk.org/project/dpdk/list/?series=12169", "date": "2020-09-13T15:48:56", "name": "introduce support for hairpin between two ports", "version": 2, "mbox": "http://patches.dpdk.org/series/12169/mbox/" } ], "comments": "http://patches.dpdk.org/api/covers/77543/comments/", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@inbox.dpdk.org", "Delivered-To": "patchwork@inbox.dpdk.org", "Received": [ "from dpdk.org (dpdk.org [92.243.14.124])\n\tby inbox.dpdk.org (Postfix) with ESMTP id C9E83A04C9;\n\tSun, 13 Sep 2020 17:49:11 +0200 (CEST)", "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id 946821DB9;\n\tSun, 13 Sep 2020 17:49:10 +0200 (CEST)", "from git-send-mailer.rdmz.labs.mlnx (unknown [37.142.13.130])\n by dpdk.org (Postfix) with ESMTP id 97E0FE07\n for <dev@dpdk.org>; Sun, 13 Sep 2020 17:49:09 +0200 (CEST)" ], "From": "Bing Zhao <bingz@nvidia.com>", "To": "thomas@monjalon.net, orika@nvidia.com, ferruh.yigit@intel.com,\n arybchenko@solarflare.com", "Cc": "dev@dpdk.org", "Date": "Sun, 13 Sep 2020 23:48:56 +0800", "Message-Id": "<1600012140-70151-1-git-send-email-bingz@nvidia.com>", "X-Mailer": "git-send-email 2.5.5", "In-Reply-To": "\n <CY4PR1201MB0072A4383E611EB8B65D89A6D0240@CY4PR1201MB0072.namprd12.prod.outlook.com>", "References": "\n <CY4PR1201MB0072A4383E611EB8B65D89A6D0240@CY4PR1201MB0072.namprd12.prod.outlook.com>", "MIME-Version": "1.0", "Content-Type": "text/plain; charset=UTF-8", "Content-Transfer-Encoding": "8bit", "Subject": "[dpdk-dev] [RFC PATCH v2 0/4] introduce support for hairpin between\n\ttwo ports", "X-BeenThere": "dev@dpdk.org", "X-Mailman-Version": "2.1.15", "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", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "content": "Hairpin functionality only supports one single port mode (e.g testpmd\napplication) in the current implementation. It means that the traffic\nwill be sent out from the same port it comes. There is no such\nrestriction for some NICs, and strong demand to support two ports\nhairpin mode in real-life cases.\nTwo ports hairpin mode does not really mean hairpin will only support\ntwo ports in a single application. Indeed, it also needs to support\nthe single port hairpin today for compatibility. In the meanwhile,\n'two ports' means the ingress and egress ports of the traffic could\nBe different. And also, there is no restriction that\n 1. traffic from the same ingress port must go to the same egress\n port\n 2. traffic from the port that as 'egress' for other traffic flows\n must go to their 'ingress' port\nThe configuration should be flexible and the behavior of traffic will\nbe decided by the rte flows.\n\nUsually, during the startup phase, all the hairpin configurations\nexcept flows should be done. It means that hairpin TXQ and peer RXQ\nshould be bound together. It is feasible in single port mode and\ntransparent to the application. In two ports mode, there may be some\nproblems for the queues configuring and binding.\n 1. Once TXQ & RXQ belong to different ports, it would be hard to\n configure the first port when the initialization of the second\n port is not done. Also, it is not proper to configure the first\n port during the second one starting.\n 2. The port could be attached and detached dynamically. Hairpin\n between these ports should support dynamic configuration.\n\nIn two ports hairpin mode, since the TXQ and RXQ belong to different\nports. If some actions need to be done in the TX part, the egress flow\ncould be inserted explicitly and managed separately from the RX part.\nWhat's more, one egress flow could be shared for different ingress\nflows from the same or different ports.\n\nIn order to satisfy these, some changes on the current rte ethdev and\nflow APIs are needed and some new APIs will be introduced.\n\n1. Data structures in 'rte_ethdev.h'\nTwo new members are added.\nstruct rte_eth_hairpin_conf {\n\tuint16_t peer_count; /**< The number of peers. */\n\tstruct rte_eth_hairpin_peer peers[RTE_ETH_MAX_HAIRPIN_PEERS];\n\tuint16_t tx_explicit;\n\tuint16_t manual_bind;\n};\n'tx_explicit': If 0, PMD will help to insert the egress flow in a\nimplicit way. If 1, the application will insert it by itself.\n'manual_bind': If 0, PMD will try to bind hairpin TXQ and RXQ peer\nautomatically, like in today's single port hairpin mode and this is\nfor backward compatibility. If 1, then manual bind API will be called.\nThe application should ensure there is no conflict for the hairpin\npeer configurations between TX & RX as today and PMD could check\nthem inside. For new member 'tx_explicit', all queue pairs from one\ningress port to the same egress are suggested to have the same value\nin order not to create chaos, like in RSS cases.\nFor new member 'manual_bind', the same suggestion is applicable.\nThe support for the new members will be decided by the NICs' capacity\nand real-life usage from the application.\n\n2. New macros in 'rte_ethdev.h'\nRTE_ETH_HAIRPIN_BIND_AUTO (0)\nRTE_ETH_HAIRPIN_BIND_MANUAL (1)\nRTE_ETH_HAIRPIN_TXRULE_IMPLICIT (0)\nRTE_ETH_HAIRPIN_TXRULE_EXPLICIT (1)\nThese are used for the new members in 'struct rte_eth_hairpin_conf'.\n\n3. New function APIs in 'rte_ethdev.h'\n* int rte_eth_hairpin_bind(uint16_t tx_port, uint16_t rx_port)\n* typedef int (*eth_hairpin_bind)(struct rte_eth_dev *dev,\n uint16_t rx_port);\nThis function will be used to bind one port egress to the peer port\ningress. If 'rx_port' is equal to RTE_MAX_ETHPORTS, then all the ports\nwill be traversed to bind hairpin egress queues to all of their\ningress queues configured. The application needs to call it repeatedly\nto bind all egress ports.\nThis should be called after the hairpin queues are set up and devices\nare started. If 'manual_bind' is not specified, no need to call this\nAPI. A function pointer with 'eth_hairpin_bind' type should be\nprovided by the PMD to execute the hardware setting in the driver.\n0 return value means success and a negative value will be returned to\nindicate the actual failure.\n\n* int rte_eth_hairpin_unbind(uint16_t tx_port, uint16_t rx_port)\n* typedef int (*eth_hairpin_unbind)(struct rte_eth_dev *dev,\n uint16_t rx_port);\nThis function will unbind one port egress to the peer port ingress,\nonly one direction hairpin will be unbound. Unbinding of the opposite\ndirection needs another call of this API.\nIf 'rx_port' is equal to RTE_MAX_ETHPORTS, all the ports will be\ntraversed to do the queues unbind (if any). The application needs to\ncall it repeatedly to unbind all egress ports.\nThe API could be called without stopping or closing the eth device,\nbut the application should ensure the flows inserted for the hairpin\nport pairs be handled properly. The traffic behavior should be\ndivinable after unbound. It is suggested to remove all the flows for\nthe same direction of a port pairs to be unbound, on both ports.\nA function pointer with 'eth_hairpin_unbind' type should be provided\nby the PMD to execute the hardware setting in the driver.\n0 return value means success and a negative value will be returned to\nindicate the actual failure.\nAfter unbinding, the bind API could be called again to enable it. No\npeer reconfiguring is supported now without closing the devices.\n\n4. New rte_flow item\n* RTE_FLOW_ITEM_TYPE_TX_QUEUE\nstruct rte_flow_item_tx_queue {\n\tuint32_t queue;\n};\nThis provides a new item to match for an egress packet. In two ports\nhairpin mode, since the TX rules could be inserted explicitly on the\negress port, it is hard to distinguish the hairpin packets from the\nsoftware packets. Even if with metadata, it may require complex\nmanagement. The support new rte_flow item is optional, depending on\nthe NIC's capacity. With this item, a few wildcard rules could be\ninserted for hairpin to support some common actions.\n\nWhen switching to two ports hairpin mode with explicit TX rules, the\nmetadata could be used to provide the 'connection' for a packet\nbetween ingress & egress.\n1. The packet header might be changed due to the NAT of DECAP in the\n ingress, and the inner header or other parts may be different.\n2. Different ingress flow rules could share the same egress rule to\n simplify rules management.\nThe rte_flow examples are like below (port 0 RX X -> port 1 TX Y):\n\nflow create 0 ingress group M pattern eth / … / end actions queue index is X / set_meta data is V / end\nX is the ingress hairpin queue index.\n\nflow create 1 egress group N pattern eth / meta data is V / end actions vxlan_encap / end\n\nflow create 1 egress group 0 pattern eth / tx_queue index is Y / end actions jump group N / end\nY is the egress hairpin queue index. This wildcard flow will help to\nredirect all the ethernet packets from hairpin TX queue Y to some\nspecific group for further handling. In the meanwhile, other traffic\nsent from software will not be impacted by this wildcard rule.\n\nTo verify this in testpmd, some changes are also required.\n1. During startup phase, hairpin binding will use the chaining mode.\n E.g. if 3 ports are probed, hairpin traffic will be like this\n port A -> port B, Port B -> port C, port C -> port A\n In only a single port is probed\n port A -> port A\n2. flow command line will add support to parse tx queue index\n pattern format: tx_queue index is UNSIGNED / ...\n\nThanks\n\nSigned-off-by: Bing Zhao <bingz@nvidia.com>\n\nBing Zhao (4):\n ethdev: add support for flow item transmit queue\n testpmd: add item transmit queue in flow CLI\n ethdev: add hairpin bind APIs\n ethdev: add new attributes to hairpin queues config\n\n app/test-pmd/cmdline_flow.c | 18 ++++++\n lib/librte_ethdev/rte_ethdev.c | 100 ++++++++++++++++++++++++++++++++++\n lib/librte_ethdev/rte_ethdev.h | 68 +++++++++++++++++++++++\n lib/librte_ethdev/rte_ethdev_driver.h | 52 ++++++++++++++++++\n lib/librte_ethdev/rte_flow.c | 1 +\n lib/librte_ethdev/rte_flow.h | 30 ++++++++++\n 6 files changed, 269 insertions(+)" }