Cover Detail
Show a cover letter.
GET /api/covers/80784/?format=api
{ "id": 80784, "url": "http://patches.dpdk.org/api/covers/80784/?format=api", "web_url": "http://patches.dpdk.org/project/dpdk/cover/1602699122-15737-1-git-send-email-viacheslavo@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": "<1602699122-15737-1-git-send-email-viacheslavo@nvidia.com>", "list_archive_url": "https://inbox.dpdk.org/dev/1602699122-15737-1-git-send-email-viacheslavo@nvidia.com", "date": "2020-10-14T18:11:56", "name": "[v6,0/6] ethdev: introduce Rx buffer split", "submitter": { "id": 1926, "url": "http://patches.dpdk.org/api/people/1926/?format=api", "name": "Slava Ovsiienko", "email": "viacheslavo@nvidia.com" }, "mbox": "http://patches.dpdk.org/project/dpdk/cover/1602699122-15737-1-git-send-email-viacheslavo@nvidia.com/mbox/", "series": [ { "id": 12967, "url": "http://patches.dpdk.org/api/series/12967/?format=api", "web_url": "http://patches.dpdk.org/project/dpdk/list/?series=12967", "date": "2020-10-14T18:11:56", "name": "ethdev: introduce Rx buffer split", "version": 6, "mbox": "http://patches.dpdk.org/series/12967/mbox/" } ], "comments": "http://patches.dpdk.org/api/covers/80784/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 1D2C5A04DB;\n\tWed, 14 Oct 2020 20:12:28 +0200 (CEST)", "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id BA3201DA8C;\n\tWed, 14 Oct 2020 20:12:26 +0200 (CEST)", "from mellanox.co.il (mail-il-dmz.mellanox.com [193.47.165.129])\n by dpdk.org (Postfix) with ESMTP id 3D1621DA8C\n for <dev@dpdk.org>; Wed, 14 Oct 2020 20:12:25 +0200 (CEST)", "from Internal Mail-Server by MTLPINE1 (envelope-from\n viacheslavo@nvidia.com) with SMTP; 14 Oct 2020 21:12:21 +0300", "from nvidia.com (pegasus12.mtr.labs.mlnx [10.210.17.40])\n by labmailer.mlnx (8.13.8/8.13.8) with ESMTP id 09EICLFN005860;\n Wed, 14 Oct 2020 21:12:21 +0300" ], "From": "Viacheslav Ovsiienko <viacheslavo@nvidia.com>", "To": "dev@dpdk.org", "Cc": "thomas@monjalon.net, stephen@networkplumber.org, ferruh.yigit@intel.com,\n olivier.matz@6wind.com, jerinjacobk@gmail.com,\n maxime.coquelin@redhat.com, david.marchand@redhat.com,\n arybchenko@solarflare.com", "Date": "Wed, 14 Oct 2020 18:11:56 +0000", "Message-Id": "<1602699122-15737-1-git-send-email-viacheslavo@nvidia.com>", "X-Mailer": "git-send-email 1.8.3.1", "In-Reply-To": "\n <MWHPR12MB136076E652230CEBD6EE6562DF5F0@MWHPR12MB1360.namprd12.prod.outlook.com>", "References": "\n <MWHPR12MB136076E652230CEBD6EE6562DF5F0@MWHPR12MB1360.namprd12.prod.outlook.com>", "Subject": "[dpdk-dev] [PATCH v6 0/6] ethdev: introduce Rx buffer split", "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": "The DPDK datapath in the transmit direction is very flexible.\nAn application can build the multi-segment packet and manages\nalmost all data aspects - the memory pools where segments\nare allocated from, the segment lengths, the memory attributes\nlike external buffers, registered for DMA, etc.\n\nIn the receiving direction, the datapath is much less flexible,\nan application can only specify the memory pool to configure the\nreceiving queue and nothing more. In order to extend receiving\ndatapath capabilities it is proposed to add the way to provide\nextended information how to split the packets being received.\n\nThe following structure is introduced to specify the Rx packet\nsegment:\n\nstruct rte_eth_rxseg {\n struct rte_mempool *mp; /* memory pools to allocate segment from */\n uint16_t length; /* segment maximal data length,\n\t\t \tconfigures \"split point\" */\n uint16_t offset; /* data offset from beginning\n\t\t \tof mbuf data buffer */\n uint32_t reserved; /* reserved field */\n};\n\nThe segment descriptions are added to the rte_eth_rxconf structure:\n rx_seg - pointer the array of segment descriptions, each element\n describes the memory pool, maximal data length, initial\n data offset from the beginning of data buffer in mbuf.\n\t This array allows to specify the different settings for\n\t each segment in individual fashion.\n rx_nseg - number of elements in the array\n\nIf the extended segment descriptions is provided with these new\nfields the mp parameter of the rte_eth_rx_queue_setup must be\nspecified as NULL to avoid ambiguity.\n\nThere are two options to specifiy Rx buffer configuration:\n- mp is not NULL, rx_conf.rx_seg is NULL, rx_conf.rx_nseg is zero,\n it is compatible configuraion, follows existing implementation,\n provides single pool and no description for segment sizes\n and offsets.\n- mp is NULL, rx_conf.rx_seg is not NULL, rx_conf.rx_nseg is not\n zero, it provides the extended configuration, individually for\n each segment.\n\nThe new offload flag RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT in device\ncapabilities is introduced to present the way for PMD to report to\napplication about supporting Rx packet split to configurable\nsegments. Prior invoking the rte_eth_rx_queue_setup() routine\napplication should check RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT flag.\n\nIf the Rx queue is configured with new settings the packets being\nreceived will be split into multiple segments pushed to the mbufs\nwith specified attributes. The PMD will split the received packets\ninto multiple segments according to the specification in the\ndescription array:\n\n- the first network buffer will be allocated from the memory pool,\n specified in the first segment description element, the second\n network buffer - from the pool in the second segment description\n element and so on. If there is no enough elements to describe\n the buffer for entire packet of maximal length the pool from the\n last valid element will be used to allocate the buffers from for the\n rest of segments\n\n- the offsets from the segment description elements will provide\n the data offset from the buffer beginning except the first mbuf -\n for this one the offset is added to the RTE_PKTMBUF_HEADROOM to get\n actual offset from the buffer beginning. If there is no enough\n elements to describe the buffer for entire packet of maximal length\n the offsets for the rest of segment will be supposed to be zero.\n\n- the data length being received to each segment is limited by the\n length specified in the segment description element. The data\n receiving starts with filling up the first mbuf data buffer, if the\n specified maximal segment length is reached and there are data\n remaining (packet is longer than buffer in the first mbuf) the\n following data will be pushed to the next segment up to its own\n maximal length. If the first two segments is not enough to store\n all the packet remaining data the next (third) segment will\n be engaged and so on. If the length in the segment description\n element is zero the actual buffer size will be deduced from\n the appropriate memory pool properties. If there is no enough\n elements to describe the buffer for entire packet of maximal\n length the buffer size will be deduced from the pool of the last\n valid element for the remaining segments.\n\nFor example, let's suppose we configured the Rx queue with the\nfollowing segments:\n seg0 - pool0, len0=14B, off0=2\n seg1 - pool1, len1=20B, off1=128B\n seg2 - pool2, len2=20B, off2=0B\n seg3 - pool3, len3=512B, off3=0B\n\nThe packet 46 bytes long will look like the following:\n seg0 - 14B long @ RTE_PKTMBUF_HEADROOM + 2 in mbuf from pool0\n seg1 - 20B long @ 128 in mbuf from pool1\n seg2 - 12B long @ 0 in mbuf from pool2\n\nThe packet 1500 bytes long will look like the following:\n seg0 - 14B @ RTE_PKTMBUF_HEADROOM + 2 in mbuf from pool0\n seg1 - 20B @ 128 in mbuf from pool1\n seg2 - 20B @ 0 in mbuf from pool2\n seg3 - 512B @ 0 in mbuf from pool3\n seg4 - 512B @ 0 in mbuf from pool3\n seg5 - 422B @ 0 in mbuf from pool3\n\nThe offload RTE_ETH_RX_OFFLOAD_SCATTER must be present and\nconfigured to support new buffer split feature (if rx_nseg\nis greater than one).\n\nThe new approach would allow splitting the ingress packets into\nmultiple parts pushed to the memory with different attributes.\nFor example, the packet headers can be pushed to the embedded\ndata buffers within mbufs and the application data into\nthe external buffers attached to mbufs allocated from the\ndifferent memory pools. The memory attributes for the split\nparts may differ either - for example the application data\nmay be pushed into the external memory located on the dedicated\nphysical device, say GPU or NVMe. This would improve the DPDK\nreceiving datapath flexibility with preserving compatibility\nwith existing API.\n\nSigned-off-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>\n---\nv1: http://patches.dpdk.org/patch/79594/\nv2: http://patches.dpdk.org/patch/79893/\n - add feature support to mlx5 PMD\n\nv3: http://patches.dpdk.org/patch/80389/\n - rte_eth_rx_queue_setup_ex is renamed to rte_eth_rxseg_queue_setup\n - DEV_RX_OFFLOAD_BUFFER_SPLIT is renamed to RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT\n - commit message update\n - documentaion provided\n - release notes update\n - minor bug fixes in testpmd related part\n\nv4: http://patches.dpdk.org/patch/80401/\n - common part of rx_queue_setup/rxseg_queue_setup\n\nv5: http://patches.dpdk.org/patch/80609/\n - refactored to approach of providing split configuration\n in the rte_eth_rxconf structure instead of introducing\n the new API routine\n - added support for rxoffs command to testpmd to\n provide segment offsets for complete testing of split\n configurations\n - patchset is split into two parts - PMD part will\n be presented as separate series\n\nv6: - wordy comments rephrased\n - typos fixed\n - rte_eth_rx_queue_setup configuration check isolated\n for two main options\n - the rest of comments addressed\n\n\nViacheslav Ovsiienko (6):\n ethdev: introduce Rx buffer split\n app/testpmd: add multiple pools per core creation\n app/testpmd: add buffer split offload configuration\n app/testpmd: add rxpkts commands and parameters\n app/testpmd: add rxoffs commands and parameters\n app/testpmd: add extended Rx queue setup\n\n app/test-pmd/bpf_cmd.c | 4 +-\n app/test-pmd/cmdline.c | 151 ++++++++++++++++++++++++----\n app/test-pmd/config.c | 107 +++++++++++++++++++-\n app/test-pmd/parameters.c | 54 ++++++++--\n app/test-pmd/testpmd.c | 120 ++++++++++++++++------\n app/test-pmd/testpmd.h | 44 ++++++--\n doc/guides/nics/features.rst | 15 +++\n doc/guides/rel_notes/deprecation.rst | 5 -\n doc/guides/rel_notes/release_20_11.rst | 9 ++\n doc/guides/testpmd_app_ug/run_app.rst | 22 +++-\n doc/guides/testpmd_app_ug/testpmd_funcs.rst | 36 ++++++-\n lib/librte_ethdev/rte_ethdev.c | 111 +++++++++++++++-----\n lib/librte_ethdev/rte_ethdev.h | 62 +++++++++++-\n 13 files changed, 637 insertions(+), 103 deletions(-)" }