Cover Detail
Show a cover letter.
GET /api/covers/65432/?format=api
{ "id": 65432, "url": "http://patches.dpdk.org/api/covers/65432/?format=api", "web_url": "http://patches.dpdk.org/project/dpdk/cover/20200131170201.3236153-1-jerinj@marvell.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": "<20200131170201.3236153-1-jerinj@marvell.com>", "list_archive_url": "https://inbox.dpdk.org/dev/20200131170201.3236153-1-jerinj@marvell.com", "date": "2020-01-31T17:01:56", "name": "[RFC,0/5] graph: introduce graph subsystem", "submitter": { "id": 1188, "url": "http://patches.dpdk.org/api/people/1188/?format=api", "name": "Jerin Jacob Kollanukkaran", "email": "jerinj@marvell.com" }, "mbox": "http://patches.dpdk.org/project/dpdk/cover/20200131170201.3236153-1-jerinj@marvell.com/mbox/", "series": [ { "id": 8382, "url": "http://patches.dpdk.org/api/series/8382/?format=api", "web_url": "http://patches.dpdk.org/project/dpdk/list/?series=8382", "date": "2020-01-31T17:01:56", "name": "graph: introduce graph subsystem", "version": 1, "mbox": "http://patches.dpdk.org/series/8382/mbox/" } ], "comments": "http://patches.dpdk.org/api/covers/65432/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 E5FD3A0524;\n\tFri, 31 Jan 2020 18:02:35 +0100 (CET)", "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id 868AB1C0C2;\n\tFri, 31 Jan 2020 18:02:34 +0100 (CET)", "from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com\n [67.231.148.174]) by dpdk.org (Postfix) with ESMTP id 2B0BE1C029;\n Fri, 31 Jan 2020 18:02:33 +0100 (CET)", "from pps.filterd (m0045849.ppops.net [127.0.0.1])\n by mx0a-0016f401.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id\n 00VGvDTX000395; Fri, 31 Jan 2020 09:02:23 -0800", "from sc-exch04.marvell.com ([199.233.58.184])\n by mx0a-0016f401.pphosted.com with ESMTP id 2xvpas8fuj-1\n (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT);\n Fri, 31 Jan 2020 09:02:23 -0800", "from SC-EXCH01.marvell.com (10.93.176.81) by SC-EXCH04.marvell.com\n (10.93.176.84) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 31 Jan\n 2020 09:02:20 -0800", "from maili.marvell.com (10.93.176.43) by SC-EXCH01.marvell.com\n (10.93.176.81) with Microsoft SMTP Server id 15.0.1497.2 via Frontend\n Transport; Fri, 31 Jan 2020 09:02:21 -0800", "from jerin-lab.marvell.com (jerin-lab.marvell.com [10.28.34.14])\n by maili.marvell.com (Postfix) with ESMTP id EC2E33F7040;\n Fri, 31 Jan 2020 09:02:10 -0800 (PST)" ], "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com;\n h=from : to : cc :\n subject : date : message-id : mime-version : content-type :\n content-transfer-encoding; s=pfpt0818;\n bh=xFpI3CZqonj3N/Pb9ZTOnI9HkCh33Pdg6w62XB7Y7JM=;\n b=oUyCEJTQY9ZBvtvaFs1D02DRvs+ftF4eh275F2mumei3FrJwgqSLnXScgN+4mEyrdBr8\n 2v/sniqWphfr7OY10wXUmSGauOKQL1SPFPzwwRxAYmxn02T29OIpX54DUr1I4syyCYEL\n /RyPc0ATU5vkaKQuMVMyWUgpRyODy0Qh8hRX+lcALO3iS9L+8PIO9H+W+LujcP7rcu+C\n 3AAOCn+rVmtUKTNzQRkB9cE3gf2TooKyhV83djnxcC/fbtjOIxb82IsrI87AUbkzsgZW\n hmkLdAPWd69+yobz25Z9c57PHagJ3+vIn6dXCXkG7LTqDhAWeydTY6w9KYvJEEE/TlrR UA==", "From": "<jerinj@marvell.com>", "To": "<dev@dpdk.org>", "CC": "<pkapoor@marvell.com>, <ndabilpuram@marvell.com>,\n <kirankumark@marvell.com>, <pbhagavatula@marvell.com>,\n <pathreya@marvell.com>, <nsaxena@marvell.com>,\n <sshankarnara@marvell.com>, <honnappa.nagarahalli@arm.com>,\n <thomas@monjalon.net>, <david.marchand@redhat.com>,\n <ferruh.yigit@intel.com>, <arybchenko@solarflare.com>,\n <ajit.khaparde@broadcom.com>, <xiaolong.ye@intel.com>,\n <rasland@mellanox.com>, <maxime.coquelin@redhat.com>,\n <akhil.goyal@nxp.com>, <cristian.dumitrescu@intel.com>,\n <john.mcnamara@intel.com>, <bruce.richardson@intel.com>,\n <anatoly.burakov@intel.com>, <gavin.hu@arm.com>,\n <drc@linux.vnet.ibm.com>, <konstantin.ananyev@intel.com>,\n <pallavi.kadam@intel.com>, <olivier.matz@6wind.com>,\n <gage.eads@intel.com>, <nikhil.rao@intel.com>,\n <erik.g.carrillo@intel.com>, <hemant.agrawal@nxp.com>,\n <artem.andreev@oktetlabs.ru>, <sthemmin@microsoft.com>,\n <shahafs@mellanox.com>, <keith.wiles@intel.com>,\n <mattias.ronnblom@ericsson.com>, <jasvinder.singh@intel.com>,\n <vladimir.medvedkin@intel.com>, <mdr@ashroe.eu>, <techboard@dpdk.org>,\n \"Jerin Jacob\" <jerinj@marvell.com>", "Date": "Fri, 31 Jan 2020 22:31:56 +0530", "Message-ID": "<20200131170201.3236153-1-jerinj@marvell.com>", "X-Mailer": "git-send-email 2.24.1", "MIME-Version": "1.0", "Content-Type": "text/plain; charset=\"UTF-8\"", "Content-Transfer-Encoding": "8bit", "X-Proofpoint-Virus-Version": "vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572\n definitions=2020-01-31_04:2020-01-31,\n 2020-01-31 signatures=0", "Subject": "[dpdk-dev] [RFC PATCH 0/5] graph: introduce graph subsystem", "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": "From: Jerin Jacob <jerinj@marvell.com>\n\nThis RFC is targeted for v20.05 release.\n\nThis RFC patch includes an implementation of graph architecture for packet\nprocessing using DPDK primitives.\n\nUsing graph traversal for packet processing is a proven architecture\nthat has been implemented in various open source libraries.\n\nGraph architecture for packet processing enables abstracting the data\nprocessing functions as “nodes” and “links” them together to create a complex\n“graph” to create reusable/modular data processing functions. \n\nThe RFC patch further includes performance enhancements and modularity\nto the DPDK as discussed in more detail below.\n\nWhat this RFC patch contains:\n-----------------------------\n1) The API definition to \"create\" nodes and \"link\" together to create a \"graph\"\nfor packet processing. See, lib/librte_graph/rte_graph.h \n\n2) The Fast path API definition for the graph walker and enqueue function\nused by the workers. See, lib/librte_graph/rte_graph_worker.h\n\n3) Optimized SW implementation for (1) and (2). See, lib/librte_graph/\n\n4) Test case to verify the graph infrastructure functionality\nSee, app/test/test_graph.c\n \n5) Performance test cases to evaluate the cost of graph walker and nodes\nenqueue fast-path function for various combinations.\n\nSee app/test/test_graph_perf.c\n\n6) Packet processing nodes(Null, Rx, Tx, Pkt drop, IPV4 rewrite, IPv4 lookup)\nusing graph infrastructure. See lib/librte_node/*\n\n7) An example application to showcase l3fwd\n(functionality same as existing examples/l3fwd) using graph infrastructure and\nuse packets processing nodes (item (6)). See examples/l3fwd-graph/.\n\nPerformance\n-----------\n1) Graph walk and node enqueue overhead can be tested with performance test\ncase application [1]\n# If all packets go from a node to another node (we call it as \"homerun\") then\nit will be just a pointer swap for a burst of packets.\n# In the worst case, a couple of handful cycles to move an object from a node\nto another node.\n\n2) Performance comparison with existing l3fwd (The complete static code with out\nany nodes) vs modular l3fwd-graph with 5 nodes\n(ip4_lookup, ip4_rewrite, ethdev_tx, ethdev_rx, pkt_drop).\nHere is graphical representation of the l3fwd-graph as Graphviz dot file: \nhttp://bit.ly/39UPPGm\n\n# l3fwd-graph performance is -2.5% wrt static l3fwd.\n\n# We have simulated the similar test with existing librte_pipeline application [4].\nip_pipline application is -48.62% wrt static l3fwd.\n\nThe above results are on octeontx2. It may vary on other platforms.\nThe platforms with higher L1 and L2 caches will have further better performance.\n\nTested architectures:\n--------------------\n1) AArch64\n2) X86\n\n\nGraph library Features\n----------------------\n1) Nodes as plugins\n2) Support for out of tree nodes\n3) Multi-process support.\n4) Low overhead graph walk and node enqueue\n5) Low overhead statistics collection infrastructure\n6) Support to export the graph as a Graphviz dot file.\nSee rte_graph_export()\nExample of exported graph: http://bit.ly/2PqbqOy\n7) Allow having another graph walk implementation\nin the future by segregating the fast path and slow path code.\n\n\nAdvantages of Graph architecture:\n---------------------------------\n\n1) Memory latency is the enemy for high-speed packet processing,\nmoving the similar packet processing code to a node will reduce\nthe I cache and D caches misses.\n2) Exploits the probability that most packets will follow the same nodes in the graph.\n3) Allow SIMD instructions for packet processing of the node.\n4) The modular scheme allows having reusable nodes for the consumers.\n5) The modular scheme allows us to abstract the vendor HW specific\noptimizations as a node.\n\n\nWhat is different than existing libpipeline library\n---------------------------------------------------\nAt a very high level, libpipeline created to allow modular plugin interface.\nBased on our analysis the performance is better in the graph model.\nCheck the details under the Performance section, Item (2).\n\nThis rte_graph implementation has taken care of fixing some of the\narchitecture/implementations limitations with libpipeline.\n\n1) Use cases like IP fragmentation, TCP ACK processing\n(with new TCP data sent out in the same context) \nhave a problem as rte_pipeline_run() passes just pkt_mask of 64 bits to different\ntables and packet pointers are stored in the single array in struct rte_pipeline_run.\n\nIn Graph architecture, The node has complete control of how many packets are\noutput to next node seamlessly.\n\n2) Since pktmask is passed to different tables, it takes multiple for loops to\nextract pkts out of fragmented pkts_mask. This makes it difficult to prefetch\nahead a set of packets. This issue does not exist in Graph architecture.\n\n3) Every table have two/three function pointers unlike graph architecture that\nhas a single function pointer for node.\n\n4) The current libpipeline main fast-path function doesn't support tree-like\ntopology where 64 packets can be redirected to 64 different tables.\nIt is currently limited to table-based next table id instead of per-packet\naction based next table id. So in a typical case, we need to cascade tables and\nsequentially go through all the tables to reach the last table.\n\n5) pkt_mask limit is 64 bits which is the max burst size possible.\nThe graph library supports up to 256.\n\nIn short, both are significantly different architectures.\nAllowing the end-user to choose the model would be a more appropriate decision\nby keeping both in DPDK.\n \n\nWhy this RFC\n------------\n1) We believe, Graph architecture provides the best performance for \nreusable/modular packet processing framework.\nSince DPDK does not have it, it is good to have it in DPDK.\n\n2) Based on our experience, NPU HW accelerates are so different than one vendor \nto another vendor. Going forward, We believe, API abstraction may not be enough\nabstract the difference in HW. The Vendor-specific nodes can abstract the HW\ndifferences and reuse generic the nodes as needed.\nThis would help both the silicon vendors and DPDK end users.\n\n3) The framework enables the protocol stack as use native mbuf for\ngraph processing to avoid any conversion between the formats for\nbetter performance.\n\n4) DPDK becomes the \"goto library\" for userspace HW acceleration.\nIt is good to have native Graph packet processing library in DPDK.\n\n5) Obviously, Our customers are interested in Graph library in DPDK :-)\n\nIdentified tweaking for better performance on different targets\n---------------------------------------------------------------\n1) Test with various burst size values (256, 128, 64, 32) using\nCONFIG_RTE_GRAPH_BURST_SIZE config option.\nBased on our testing, on x86 and arm64 servers, The sweet spot is 256 burst size.\nWhile on arm64 embedded SoCs, it is either 64 or 128.\n\n2) Disable node statistics (use CONFIG_RTE_LIBRTE_GRAPH_STATS config option)\nif not needed.\n\n3) Use arm64 optimized memory copy for arm64 architecture by\nselecting CONFIG_RTE_ARCH_ARM64_MEMCPY. \n\nCommands to run tests\n---------------------\n\n[1] \nperf test:\necho \"graph_perf_autotest\" | sudo ./build/app/test/dpdk-test -c 0x30\n\n[2]\nfunctionality test:\necho \"graph_autotest\" | sudo ./build/app/test/dpdk-test -c 0x30\n\n[3]\nl3fwd-graph:\n./l3fwd-graph -c 0x100 -- -p 0x3 --config=\"(0, 0, 8)\" -P\n\n[4]\n# ./ip_pipeline --c 0xff0000 -- -s route.cli\n\nRoute.cli: (Copy paste to the shell to avoid dos format issues)\n\nhttps://pastebin.com/raw/B4Ktx7TT\n\n\nNext steps\n-----------------------------\n1) Feedback from the community on the library.\n2) Collect the API requirements from the community.\n3) Sending the next version by addressing the community initial.\nfeedback and fixing the following identified \"pending items\".\n\n \nPending items (Will be addressed in next revision)\n-------------------------------------------------\n1) Add documentation as a patch\n2) Add Doxygen API documentation\n3) Split the patches at a more logical level for a better review.\n4) code cleanup\n5) more optimizations in the nodes and graph infrastructure.\n\n\nProgramming guide and API walk-through\n--------------------------------------\n# Anatomy of Node:\n~~~~~~~~~~~~~~~~~\nSee the https://github.com/jerinjacobk/share/blob/master/Anatomy_of_a_node.svg\n\nThe above diagram depicts the anatomy of a node.\nThe node is the basic building block of the graph framework.\n\nA node consists of:\na) process():\n\nThe callback function will be invoked by worker thread using\nrte_graph_walk() function when there is data to be processed by the node.\nA graph node process the function using process() and enqueue to next\ndownstream node using rte_node_enqueue*() function.\n\nb) Context memory: \n\nIt is memory allocated by the library to store the node-specific context\ninformation. which will be used by process(), init(), fini() callbacks.\n\nc) init():\n\nThe callback function which will be invoked by rte_graph_create() on when a node \ngets attached to a graph.\n\nd) fini():\n\nThe callback function which will be invoked by rte_graph_destroy() on when a node \ngets detached to a graph.\n\n\ne) Node name:\n\nIt is the name of the node. When a node registers to graph library, the library \ngives the ID as rte_node_t type. Both ID or Name shall be used lookup the node.\nrte_node_from_name(), rte_node_id_to_name() are the node lookup functions.\n\nf) nb_edges:\n\nNumber of downstream nodes connected to this node. The next_nodes[] stores the\ndownstream nodes objects. rte_node_edge_update() and rte_node_edge_shrink()\nfunctions shall be used to update the next_node[] objects. Consumers of the node\nAPIs are free to update the next_node[] objects till rte_graph_create() invoked.\n\ng) next_node[]:\n\nThe dynamic array to store the downstream nodes connected to this node.\n\n\n# Node creation and registration\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\na) Node implementer creates the node by implementing ops and attributes of\n'struct rte_node_register'\nb) The library registers the node by invoking RTE_NODE_REGISTER on library load\nusing the constructor scheme.\nThe constructor scheme used here to support multi-process.\n\n\n# Link the Nodes to create the graph topology\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\nSee the https://github.com/jerinjacobk/share/blob/master/Link_the_nodes.svg\n\nThe above diagram shows a graph topology after linking the N nodes.\n\nOnce nodes are available to the program, Application or node public API functions\ncan links them together to create a complex packet processing graph.\n\nThere are multiple different types of strategies to link the nodes.\n\nMethod a) Provide the next_nodes[] at the node registration time.\nSee 'struct rte_node_register::nb_edges'. This is a use case to address the static\nnode scheme where one knows upfront the next_nodes[] of the node.\n\nMethod b) Use rte_node_edge_get(), rte_node_edge_update(), rte_node_edge_shrink() to\nUpdate the next_nodes[] links for the node dynamically.\n\nMethod c) Use rte_node_clone() to clone a already existing node.\nWhen rte_node_clone() invoked, The library, would clone all the attributes\nof the node and creates a new one. The name for cloned node shall be\n\"parent_node_name-user_provided_name\". This method enables the use case of Rx and Tx\nnodes where multiple of those nodes need to be cloned based on the number of CPU\navailable in the system. The cloned nodes will be identical, except the \"context memory\".\nContext memory will have information of port, queue pair incase of Rx and Tx ethdev nodes.\n \n# Create the graph object\n~~~~~~~~~~~~~~~~~~~~~~~~~\nNow that the nodes are linked, Its time to create a graph by including\nthe required nodes. The application can provide a set of node patterns to\nform a graph object.\nThe fnmatch() API used underneath for the pattern matching to include\nthe required nodes.\n\nThe rte_graph_create() API shall be used to create the graph.\n\nExample of a graph object creation:\n\n{\"ethdev_rx_0_0\", ipv4-*, ethdev_tx_0_*\"}\n\nIn the above example, A graph object will be created with ethdev Rx\nnode of port 0 and queue 0, all ipv4* nodes in the system,\nand ethdev tx node of port 0 with all queues.\n\n\n# Multi core graph processing\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nIn the current graph library implementation, specifically,\nrte_graph_walk() and rte_node_enqueue* fast path API functions\nare designed to work on single-core to have better performance.\nThe fast path API works on graph object, So the multi-core graph \nprocessing strategy would be to create graph object PER WORKER.\n \n\n# In fast path:\n~~~~~~~~~~~~~~~\n\nTypical fast-path code looks like below, where the application\ngets the fast-path graph object through rte_graph_lookup() \non the worker thread and run the rte_graph_walk() in a tight loop.\n\nstruct rte_graph *graph = rte_graph_lookup(\"worker0\");\n\nwhile (!done) {\n rte_graph_walk(graph);\n}\n\n# Context update when graph walk in action\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nThe fast-path object for the node is `struct rte_node`. \n\nIt may be possible that in slow-path or after the graph walk-in action,\nthe user needs to update the context of the node hence access to \nstruct rte_node * memory.\n\nrte_graph_foreach_node(), rte_graph_node_get(), rte_graph_node_get_by_name()\nAPIs can be used to to get the struct rte_node*. rte_graph_foreach_node() iterator\nfunction works on struct rte_graph * fast-path graph object while others\nworks on graph ID or name.\n\n\n# Get the node statistics using graph cluster\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nThe user may need to know the aggregate stats of the node across\nmultiple graph objects. Especially the situation where each\ngraph object bound to a worker thread.\n\nIntroduced a graph cluster object for statistics. rte_graph_cluster_stats_create()\nshall be used for creating a graph cluster with multiple graph objects and\nrte_graph_cluster_stats_get() to get the aggregate node statistics.\n\nAn example statistics output from rte_graph_cluster_stats_get()\n\n+-----------+------------+-------------+---------------+------------+---------------+-----------+\n|Node |calls |objs |realloc_count |objs/call |objs/sec(10E6) |cycles/call|\n+------------------------+-------------+---------------+------------+---------------+-----------+\n|node0 |12977424 |3322220544 |5 |256.000 |3047.151872 |20.0000 |\n|node1 |12977653 |3322279168 |0 |256.000 |3047.210496 |17.0000 |\n|node2 |12977696 |3322290176 |0 |256.000 |3047.221504 |17.0000 |\n|node3 |12977734 |3322299904 |0 |256.000 |3047.231232 |17.0000 |\n|node4 |12977784 |3322312704 |1 |256.000 |3047.243776 |17.0000 |\n|node5 |12977825 |3322323200 |0 |256.000 |3047.254528 |17.0000 |\n+-----------+------------+-------------+---------------+------------+---------------+-----------+\n\n# Node writing guide lines\n~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nThe process() function of a node is fast-path function and that needs to be written\ncarefully to achieve max performance.\n\nBroadly speaking, there are two different types of nodes.\n\n1) First kind of nodes are those that have a fixed next_nodes[] for the\ncomplete burst (like ethdev_rx, ethdev_tx) and it is simple to write.\nProcess() function can move the obj burst to the next node either using\nrte_node_next_stream_move() or using rte_node_next_stream_get() and\nrte_node_next_stream_put().\n \n \n2) The second kind of such node is `intermediate nodes` that decide what is the next_node[]\nto send to on a per-packet basis. In these nodes,\n\na) Firstly, there has to be the best possible packet processing logic.\nb) Secondly, each packet needs to be queued to its next node.\n\nAt least on some architectures, we get around ~10% more performance if we can avoid copying of \npacket pointers from one node to next as it is ~= memcpy(BURST_SIZE x sizeof(void *)) x NODE_COUNT.\n\nThis can be avoided only in the case where all the packets are destined to the same\nnext node. We call this as home run case and we use rte_node_next_stream_move() to\njust move burst of object array by swapping the pointer. a.k.a move stream from one node to next node\nwith least number of cycles.\n\nExample of intermediate node implementation with home run:\na) Start with speculation that next_node = ctx->next_node.\n This could be the next_node application used in the previous function call of this node.\nb) Get the next_node stream array and space using\n rte_node_next_stream_get(next_node, &space)\nc) while space != 0 and n_pkts_left != 0,\n prefetch next pkt_set and process current pkt_set to find their next node\nd) if all the next nodes of the current pkt_set match speculated next node,\n just count them as successfully speculated(last_spec) till now and\n continue the loop without actually moving them to the next node.\n else if there is a mismatch,\n copy all the pkt_set pointers that were last_spec and\n move the current pkt_set to their respective next's nodes using\n rte_enqueue_next_x1(). Also one of the next_node can be updated as\n speculated next_node if it is more probable. Also set last_spec = 0\ne) if n_pkts_left != 0 and space != 0\n goto c) as there is space in the speculated next_node.\nf) if last_spec == n_pkts_left,\n then we successfully speculated all the packets to right next node.\n Just call rte_node_next_stream_move(node, next_node) to just move the\n stream/obj array to next node. This is home run where we avoided\n memcpy of buffer pointers to next node.\ng) if space = 0 and n_pkts_left != 0\n goto b)\nh) Update the ctx->next_node with more probable next node.\n\n# In-tree node documentation\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~\na) librte_node/ethdev_rx.c:\n This node does rte_eth_rx_burst() into stream buffer acquired using\n rte_node_next_stream_get() and does rte_node_next_stream_put(count)\n only when there are packets received. Each rte_node works on only on\n one rx port and queue that it gets from node->context.\n For each (port X, rx_queue Y), a rte_node is cloned from ethdev_rx_base_node\n as \"ethdev_rx-X-Y\" in rte_node_eth_config() along with updating\n node->context. Each graph needs to be associated with a unique\n rte_node for a (port, rx_queue).\n\nb) librte_node/ethdev_tx.c:\n This node does rte_eth_tx_burst() for a burst of objs received by it.\n It sends the burst to a fixed Tx Port and Queue information from\n node->context. For each (port X), this rte_node is cloned from\n ethdev_tx_node_base as \"ethdev_tx-X\" in rte_node_eth_config()\n along with updating node->context.\n\tSince each graph doesn't need more than one Txq, per port, \n\ta Txq is assigned based on graph id to each rte_node instance.\n\tEach graph needs to be associated with a rte_node for each (port).\n\nc) librte_node/pkt_drop.c:\n This node frees all the objects that are passed to it.\n\nd) librte_node/ip4_lookup.c:\n This node is an intermediate node that does lpm lookup for the received\n\tipv4 packets and the result determines each packets next node.\n a) On successful lpm lookup, the result contains the nex_node id and\n next-hop id with which the packet needs to be further processed.\n b) On lpm lookup failure, objects are redirected to pkt_drop node.\n rte_node_ip4_route_add() is control path API to add ipv4 routes.\n To achieve home run, we use rte_node_stream_move() as mentioned in above\n sections.\n\ne) librte_node/ip4_rewrite.c:\n This node gets packets from ip4_lookup node with next-hop id for each\n packet is embedded in rte_node_mbuf_priv1(mbuf)->nh. This id is used\n to determine the L2 header to be written to the pkt before sending\n the pkt out to a particular ethdev_tx node.\n rte_node_ip4_rewrite_add() is control path API to add next-hop info.\n\nJerin Jacob (1):\n graph: introduce graph subsystem\n\nKiran Kumar K (1):\n test: add graph functional tests\n\nNithin Dabilpuram (2):\n node: add packet processing nodes\n example/l3fwd_graph: l3fwd using graph architecture\n\nPavan Nikhilesh (1):\n test: add graph performance test cases.\n\n app/test/Makefile | 5 +\n app/test/meson.build | 10 +-\n app/test/test_graph.c | 820 +++++++++++++++++\n app/test/test_graph_perf.c | 888 +++++++++++++++++++\n config/common_base | 13 +\n config/rte_config.h | 4 +\n examples/Makefile | 3 +\n examples/l3fwd-graph/Makefile | 58 ++\n examples/l3fwd-graph/main.c | 1131 ++++++++++++++++++++++++\n examples/l3fwd-graph/meson.build | 13 +\n examples/meson.build | 6 +-\n lib/Makefile | 6 +\n lib/librte_graph/Makefile | 28 +\n lib/librte_graph/graph.c | 578 ++++++++++++\n lib/librte_graph/graph_debug.c | 81 ++\n lib/librte_graph/graph_ops.c | 163 ++++\n lib/librte_graph/graph_populate.c | 224 +++++\n lib/librte_graph/graph_private.h | 113 +++\n lib/librte_graph/graph_stats.c | 396 +++++++++\n lib/librte_graph/meson.build | 11 +\n lib/librte_graph/node.c | 419 +++++++++\n lib/librte_graph/rte_graph.h | 277 ++++++\n lib/librte_graph/rte_graph_version.map | 46 +\n lib/librte_graph/rte_graph_worker.h | 280 ++++++\n lib/librte_node/Makefile | 30 +\n lib/librte_node/ethdev_ctrl.c | 106 +++\n lib/librte_node/ethdev_rx.c | 218 +++++\n lib/librte_node/ethdev_rx.h | 17 +\n lib/librte_node/ethdev_rx_priv.h | 45 +\n lib/librte_node/ethdev_tx.c | 74 ++\n lib/librte_node/ethdev_tx_priv.h | 33 +\n lib/librte_node/ip4_lookup.c | 657 ++++++++++++++\n lib/librte_node/ip4_lookup_priv.h | 17 +\n lib/librte_node/ip4_rewrite.c | 340 +++++++\n lib/librte_node/ip4_rewrite_priv.h | 44 +\n lib/librte_node/log.c | 14 +\n lib/librte_node/meson.build | 8 +\n lib/librte_node/node_private.h | 61 ++\n lib/librte_node/null.c | 23 +\n lib/librte_node/pkt_drop.c | 26 +\n lib/librte_node/rte_node_eth_api.h | 31 +\n lib/librte_node/rte_node_ip4_api.h | 33 +\n lib/librte_node/rte_node_version.map | 9 +\n lib/meson.build | 5 +-\n meson.build | 1 +\n mk/rte.app.mk | 2 +\n 46 files changed, 7362 insertions(+), 5 deletions(-)\n create mode 100644 app/test/test_graph.c\n create mode 100644 app/test/test_graph_perf.c\n create mode 100644 examples/l3fwd-graph/Makefile\n create mode 100644 examples/l3fwd-graph/main.c\n create mode 100644 examples/l3fwd-graph/meson.build\n create mode 100644 lib/librte_graph/Makefile\n create mode 100644 lib/librte_graph/graph.c\n create mode 100644 lib/librte_graph/graph_debug.c\n create mode 100644 lib/librte_graph/graph_ops.c\n create mode 100644 lib/librte_graph/graph_populate.c\n create mode 100644 lib/librte_graph/graph_private.h\n create mode 100644 lib/librte_graph/graph_stats.c\n create mode 100644 lib/librte_graph/meson.build\n create mode 100644 lib/librte_graph/node.c\n create mode 100644 lib/librte_graph/rte_graph.h\n create mode 100644 lib/librte_graph/rte_graph_version.map\n create mode 100644 lib/librte_graph/rte_graph_worker.h\n create mode 100644 lib/librte_node/Makefile\n create mode 100644 lib/librte_node/ethdev_ctrl.c\n create mode 100644 lib/librte_node/ethdev_rx.c\n create mode 100644 lib/librte_node/ethdev_rx.h\n create mode 100644 lib/librte_node/ethdev_rx_priv.h\n create mode 100644 lib/librte_node/ethdev_tx.c\n create mode 100644 lib/librte_node/ethdev_tx_priv.h\n create mode 100644 lib/librte_node/ip4_lookup.c\n create mode 100644 lib/librte_node/ip4_lookup_priv.h\n create mode 100644 lib/librte_node/ip4_rewrite.c\n create mode 100644 lib/librte_node/ip4_rewrite_priv.h\n create mode 100644 lib/librte_node/log.c\n create mode 100644 lib/librte_node/meson.build\n create mode 100644 lib/librte_node/node_private.h\n create mode 100644 lib/librte_node/null.c\n create mode 100644 lib/librte_node/pkt_drop.c\n create mode 100644 lib/librte_node/rte_node_eth_api.h\n create mode 100644 lib/librte_node/rte_node_ip4_api.h\n create mode 100644 lib/librte_node/rte_node_version.map" }
