From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id CCB7BA04AB; Sun, 30 Aug 2020 14:59:39 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 294FC1C1F7; Sun, 30 Aug 2020 14:59:39 +0200 (CEST) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id 36CA6255 for ; Sun, 30 Aug 2020 14:59:38 +0200 (CEST) Received: from mx1-us1.ppe-hosted.com (unknown [10.110.50.143]) by dispatch1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTP id AD6302005D; Sun, 30 Aug 2020 12:59:37 +0000 (UTC) Received: from us4-mdac16-1.at1.mdlocal (unknown [10.110.49.147]) by mx1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTP id AB8698009B; Sun, 30 Aug 2020 12:59:37 +0000 (UTC) X-Virus-Scanned: Proofpoint Essentials engine Received: from mx1-us1.ppe-hosted.com (unknown [10.110.50.9]) by mx1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id 3C5E040058; Sun, 30 Aug 2020 12:59:37 +0000 (UTC) Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id 691C158005A; Sun, 30 Aug 2020 12:59:36 +0000 (UTC) Received: from [192.168.38.17] (10.17.10.39) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 30 Aug 2020 13:59:01 +0100 To: Slava Ovsiienko , "dev@dpdk.org" CC: Matan Azrad , Raslan Darawsheh , Thomas Monjalon , "ferruh.yigit@intel.com" , "jerinjacobk@gmail.com" , "stephen@networkplumber.org" , "ajit.khaparde@broadcom.com" , "maxime.coquelin@redhat.com" , "olivier.matz@6wind.com" , "david.marchand@redhat.com" References: <79886244-1390-6c99-287d-1d868bb4090a@solarflare.com> From: Andrew Rybchenko Autocrypt: addr=arybchenko@solarflare.com; keydata= mQINBF2681gBEACbdTxu8eLL3UX2oAelsnK9GkeaJeUYSOHPJQpV7RL/iaIskqTwBRnhjXt7 j9UEwGA+omnOmqQMpeQTb/F9Ma2dYE+Hw4/t/1KVjxr3ehFaASvwR4fWJfO4e2l/Rk4rG6Yi 5r6CWU2y8su2654Fr8KFc+cMGOAgKoZTZHZsRy5lHpMlemeF+VZkv8L5sYJWPnsypgqlCG3h v6lbtfZs+QqYbFH6bqoZwBAl5irmxywGR7ZJr1GLUZZ1lfdazSY8r6Vz0/Ip/KVxGu2uxo81 QCsAj0ZsQtwji9Sds/prTiPrIjx8Fc/tfbnAuVuPcnPbczwCJACzQr4q26XATL3kVuZhSBWh 4XfO/EAUuEq5AemUG5DDTM87g7Lp4eT9gMZB6P+rJwWPNWTiV3L7Cn+fO+l9mTPnOqdzBgDe OaulKiNSft1o0DY4bGzOmM2ad2cZt0jfnbMPMTE9zsr6+RFa+M8Ct20o6U1MUE4vP6veErMK of4kZ8PdoMM+Sq1hxMPNtlcVBSP9xMmdSZPlfDYI5VWosOceEcz7XZdjBJKdwKuz70V7eac4 ITSxgNFCTbeJ03zL2MR5s0IvD9ghISAwZ6ieCjU5UATn5+63qpD0nVNLsAdb/UpfvQcKAmvj 0fKlxu/PMVkjBa7/4cfNogYOhWDKUO+1pMaFwvb6/XTo6uMpfQARAQABtCxBbmRyZXcgUnli Y2hlbmtvIDxhcnliY2hlbmtvQHNvbGFyZmxhcmUuY29tPokCVAQTAQoAPhYhBP6NPgcKRj/Y X0yXQahue0sAy4m+BQJduvNYAhsDBQkB4TOABQsJCAcDBRUKCQgLBRYCAwEAAh4BAheAAAoJ EKhue0sAy4m+t3gP/j1MNc63CEozZo1IZ2UpVPAVWTYbLdPjIRdFqhlwvZYIgGIgIBk3ezKL K0/oc4ZeIwL6wQ5+V24ahuXvvcxLlKxfbJ6lo2iQGC7GLGhsDG9Y2k6sW13/sTJB/XuR2yov k5FtIgJ+aHa1PDZnepnGGOt9ka9n/Jzrc9WKYapOIIyLRe9U26ikoVgyqsD37PVeq5tLWHHA NGTUKupe9G6DFWidxx0KzyMoWDTbW2AWYcEmV2eQsgRT094AZwLFN5ErfefYzsGdO8TAUU9X YTiQN2MvP1pBxY/r0/5UfwV4UKBcR0S3ZvzyvrPoYER2Kxdf/qurx0Mn7StiCQ/JlNZb/GWQ TQ7huduuZHNQKWm7ufbqvKSfbPYvfl3akj7Wl8/zXhYdLqb5mmK45HXrgYGEqPN53OnK2Ngx IgYKEWr05KNv09097jLT5ONgYvszflqlLIzC4dV245g7ucuf9fYmsvmM1p/gFnOJBJL18YE5 P1fuGYNfLP+qp4WMiDqXlzaJfB4JcinyU49BXUj3Utd6f6sNBsO8YWcLbKBV9WmA324S3+wj f4NPRp3A5E+6OmTVMLWire2ZvnYp3YvifUj1r8lhoZ2B2vKuWwiTlHOKYBEjnOQJQnqYZEF0 JQQ1xzVDBQKE01BPlA3vy6BGWe6I4psBVqMOB9lAev/H+xa4u6Z3uQINBF269JsBEAC2KB3W 8JES/fh74avN7LOSdK4QA7gFIUQ4egVL81KnxquLzzilABuOhmZf3Rq6rMHSM8xmUAWa7Dkt YtzXStjEBI/uF0mAR3mMz1RcL2Wp+WD/15HjVpA7hPjXSEsWY0K2ymPerK4yrLcfFTHdMonY JfuACCC9NtOZxrWHOJoUS+RT7AWk80q/6D2iwQ47/2dBTznVG+gSeHSes9l91TB09w6f9JX/ sT+Ud0NQfm7HJ7t2pmGI9O6Po/NLZsDogmnIpJp/WwYOZN9JK7u2FyX2UyRzR8jK42aJkRsh DXs16Cc2/eYGakjrdO3x9a+RoxN7EuFtYhGR1PzMXdUiB5i+FyddYXkYUyO43QE/3VPA5l1v TUOagzZq6aONsdNonGJkV3TIG3JmUNtM+D/+r6QKzmgoJ8w576JxEZI09I/ZFN+g7BnUmlMx 6Z3IUOXVX/SWfGFga0YajwajHz03IBhChEbYbbqndVhmshu2GFURxrfUPYWdDXEqkh+08a5U Didia9jm2Opv4oE1e1TXAePyYJl/Zyps4Cv00GObAxibvMBQCUZQ+IBnNldRBOwXXRQV2xpx P+9iO1VYA/QXn0KqRK+SH1JGRXbJYi42YFaW1gE0EU0fiR2Wb9pK+doNEjjOhlzUGuvOEAUS +4m0m3dlfEvpCV9GMr7ERRpZzh9QkQARAQABiQI8BBgBCgAmFiEE/o0+BwpGP9hfTJdBqG57 SwDLib4FAl269JsCGwwFCQlmAYAACgkQqG57SwDLib7x6g//e+eCtNnJz7qFGbjWRJYNLCe5 gQwkhdyEGk4omr3VmjGj3z9kNFy/muh4pmHUngSAnnpwZggx14N4hhKf9y8G4Dwvsqa6b1zB Jq/c4t/SBDtGW4M/E331N04PaQZpcrbTfp1KqHNknk2N7yOk4CcoLVuIZmA5tPguASV8aAfz ZwhWAwn6vUEw9552eXEAnGFGDTCbyryNwzB5jtVQOEEDjTxcCkpcXMB45Tb1QUslRTu/sBAe HhPCQSUcJHR+KOq+P6yKICGAr291PZd6Qc7C3UyE+A3pY/UfdEVWj0STBWx1qvYLaHLrI4O9 KXDgh7luLjZZafcueCaPYmNo4V2lmNb3+7S4TvqhoZS+wN+9ldRQ4gH3wmRZybN6Y/ZCqxol RaZpE3AqdWsGvIgAkD0FpmtZNii9s2pnrhw0K6S4t4tYgXGTossxNSJUltfFQZdXM1xkZhtv dBZuUEectbZWuviGvQXahOMuH2pM64mx2hpdZzPcI2beeJNHkAsGT2KcaMETgvtHUBFRlLVB YxsUYz3UZmi2JSua4tbcGd6iWVN90eb8CxszYtivfpz6o2nPSjNwg0NaVGSHXjAK0tdByZ9t SkwjC3tEPljVycRSDpbauogOiAkvjENfaPd/H26V5hY822kaclaKDAW6ZG9UKiMijcAgb9u5 CJoOyqE8aGS5Ag0EXbr1RwEQAMXZHbafqmZiu6Kudp+Filgdkj2/XJva5Elv3fLfpXvhVt0Y if5Rzds3RpffoLQZk9nPwK8TbZFqNXPu7HSgg9AY7UdCM94WRFTkUCGKzbgiqGdXZ7Vyc8cy teGW+BcdfQycDvjfy50T3fO4kJNVp2LDNdknPaZVe8HJ80Od63+9ksB6Ni+EijMkh6Uk3ulB CSLnT4iFV57KgU2IsxOQVLnm+0bcsWMcCnGfphkY0yKP+aJ6MfmZkEeaDa7kf24N14ktg50m vOGDitcxA/+XXQXOsOIDJx1VeidxYsQ2FfsKu1G8+G6ejuaLf4rV5MI/+B/tfLbbOdikM5PF pxZVgTir9q13qHumMxdme7w5c7hybW412yWAe9TsrlXktFmFjRSFzAAxQhQSQxArS6db4oBk yeYJ59mW52i4occkimPWSm/raSgdSM+0P6zdWUlxxj+r1qiLgCYvruzLNtp5Nts5tR/HRQjE /ohQYaWDSVJEsc/4eGmgwzHzmvHtXeKkasn01381A1Lv3xwtpnfwERMAhxBZ8EGKEkc5gNdk vIPhknnGgPXqKmE1aWu8LcHiY+RHAF8gYPCDMuwyzBYnbiosKcicuIUp0Fj8XIaPao6F+WTi In4UOrqrYhsaCUvhVjsTBbNphGih9xbFJ8E+lkTLL8P3umtTcMPnpsB4xqcDABEBAAGJBHIE GAEKACYWIQT+jT4HCkY/2F9Ml0GobntLAMuJvgUCXbr1RwIbAgUJCWYBgAJACRCobntLAMuJ vsF0IAQZAQoAHRYhBNTYjdjWgdaEN5MrAN+9UR5r/4d3BQJduvVHAAoJEN+9UR5r/4d3EiQP /3lyby6v49HTU94Q2Fn2Xat6uifR7kWE5SO/1pUwYzx6v+z5K2jqPgqUYmuNoejcGl0CTNhg LbsxzUmAuf1OTAdE+ZYvOAjjKQhY4haxHc4enby/ltnHfWJYWJZ9UN5SsIQLvITvYu6rqthO CYjpXJhwkj3ODmC9H1TrvjrBGc6i7CTnR8RCjMEwCs2LI2frHa4R6imViEr9ScMfUnzdABMQ B0T5MOg8NX92/FRjTldU2KovG0ML9mSveSvVHAoEBLy4UIs5nEDdNiO1opJgKb5CXvWQugub 7AR52phNdKVdEB0S4tigJT4NalyTaPiUhFEm+CzZpMQDJ5E+/OowaPRfN4HeJX+c8sB+vUAZ mkAaG75N+IEk5JKFK9Z+bBYgPgaBDFZYdWDB/TMH0ANt+KI5uYg0i12TB4M8pwKG1DEPUmWc F2YpvB3jnbwzsOpSFiJOOlSs6nOB0Sb5GRtPOO3h6XGj+6mzQd6tcL63c9TrrUkjq7LDkxCz SJ2hTYRC8WNX8Uw9skWo5728JNrXdazEYCenUWmYiKLNKLslXCFodUCRDh/sUiyqRwS7PHEA LYC/UIWLMomI0Yvju3KA5v3RQVXhL+Gx2CzSj3GDz9xxGhJB2LfRfjzPbTR/Z27UpjCkd8z0 Ro3Ypmi1FLQwnRgoOKDbetTAIhugEShaLTITzJAP/iRDJCQsrZah5tE8oIl81qKEmBJEGcdt HYikbpQe7ydcXhqTj7+IECa3O7azI5OhCxUH2jNyonJ/phUslHH2G1TTBZK8y4Hrx5RpuRNS esn3P9uKu9DHqBAL7DMsCPwb2p1VNnapD72DBmRhzS/e6zS2R4+r9yNv03Hv7VCxKkmtE63H qpS//qpjfrtsIcHAjnKDaDtL1LYCtHoweI+DOpKKULSAYp/JE6F8LNibPQ0/P3S5ZIJNC4QZ uESjFOalJwFIqGQdkQB7ltRNJENLrHc+2jKGOuyFHm/Sbvp5EMGdaeQ0+u8CY0P+y6oXenwx 7WrJz/GvbNoFhJoJ6RzxCMQrFgxrssVZ7w5HcUj94lbnJ6osdYE/WpSd50B6jet6LKh5revg u9XI9CoqsPQ1V4wKYYdllPuogCye7KNYNKuiiuSNpaF4gHq1ZWGArwZtWHjgc2v3LegOpRQF SwOskMKmWsUyHIRMG1p8RpkBQTqY2rGSeUqPSvaqjT0nq+SUEM6qxEXD/2Wqri/X6bamuPDb S0PkBvFD2+0zr5Bc2YkMGPBYPNGZiTp3UjmZlLfn3TiBKIC92jherY563CULjSsiBEJCOSvv 4VPLn5aAcfbCXJnE3IGCp/hPl50iQqu7BPOYBbWXeb9ptDjGCAThNxSz0WAXkmcjAFE8gdE6 Znk9 Message-ID: Date: Sun, 30 Aug 2020 15:58:57 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.17.10.39] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.6.1012-25634.006 X-TM-AS-Result: No-22.965800-8.000000-10 X-TMASE-MatchedRID: 8HTFlOrbAtHmLzc6AOD8DfHkpkyUphL9Ud7Bjfo+5jShmLRqudC2iMbr Fd3sG7v6wPb5NDq94CC4Rt1oNt5z9eXzBBRraVbP9VjtTc1fwmCoNgF4lZVXFCDbJV2PcsBEFDL 4bOL9B37lmZU5+C0dpt2QIL6ECvezbILMyHSIRgSxlpnlQFCyhy8or/7xcxJEeqbdaFPgv6R0MG naSDJ+Sy8tdI0b1uqkvMJfo749BNX6K+KIBYwjWw3Tep90J3uQzDHtVtmAaYpECoESVr1FLu/oW PZe2PjsXUksFzkHonlzy9ynShYTPHhQxIeluvqIyf21YeIsPYZn+sA9+u1YLThdESD0qLXTxnMI LRETG5k4a4PpAihuCJRwc8xQ/uBocExcPM4F1gK628cXbnOhT8zzMs2dyeyVDfheddyhsqtWkXe EIE6qU4dnuhl+kJuC7cTZLhf4aVabII6cSoXys/FCD/XOqpSbElLH7tCb90quiyJNZGE/ia6PQn L4wT4IQ+xbrsNShOVMGlvvKhWhyqBArPZgUGVS4h8r8l3l4eZJaD67iKvY0wVQtPavvwzPQ8GVJ O4d1A1lXTQ9lSGXNMDQeaUy/Mpe7toabf6ZG4h9j6Il8VAHF0T7u4S9v+FYmXw0RNbqkoJ50ZLK KIqioLql+bJBVbowWq0iCWq4hAGI39asuTCmhRbwCXv1ucAPbaH3VbOE/Tn2adL4UE5fc7LJAie 8s+T8lB6IdnaWhV3PpcT0AmNqK0mENxFdlRTGtRoHk3L5VJwCC8zqHvcG2gCOLD+ckgKHEAUgrl Mfn/ueZS9CVrDt7TehJNGwTW/xtDcef9MiEsmeAiCmPx4NwFkMvWAuahr89yEa3tvzanYXeuQCq IxlebxAi7jPoeEQftwZ3X11IV0= X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--22.965800-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.6.1012-25634.006 X-MDID: 1598792377-zEQxcF5VaTYq Subject: Re: [dpdk-dev] [PATCH] doc: announce changes to ethdev rxconf structure X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 8/3/20 7:51 PM, Slava Ovsiienko wrote: >> -----Original Message----- >> From: Andrew Rybchenko >> Sent: Monday, August 3, 2020 18:31 >> To: Slava Ovsiienko ; dev@dpdk.org >> Cc: Matan Azrad ; Raslan Darawsheh >> ; Thomas Monjalon ; >> ferruh.yigit@intel.com; jerinjacobk@gmail.com; >> stephen@networkplumber.org; ajit.khaparde@broadcom.com; >> maxime.coquelin@redhat.com; olivier.matz@6wind.com; >> david.marchand@redhat.com >> Subject: Re: [PATCH] doc: announce changes to ethdev rxconf structure >> >> Hi Slava, >> >> On 8/3/20 6:18 PM, Slava Ovsiienko wrote: >>> Hi, Andrew >>> >>> Thanks for the comment, please, see below. >>> >>>> -----Original Message----- >>>> From: Andrew Rybchenko >>>> Sent: Monday, August 3, 2020 17:31 >>>> To: Slava Ovsiienko ; dev@dpdk.org >>>> Cc: Matan Azrad ; Raslan Darawsheh >>>> ; Thomas Monjalon ; >>>> ferruh.yigit@intel.com; jerinjacobk@gmail.com; >>>> stephen@networkplumber.org; ajit.khaparde@broadcom.com; >>>> maxime.coquelin@redhat.com; olivier.matz@6wind.com; >>>> david.marchand@redhat.com >>>> Subject: Re: ***Spam*** [PATCH] doc: announce changes to ethdev >>>> rxconf structure >>>> >>>> On 8/3/20 1:58 PM, Viacheslav Ovsiienko wrote: >>>>> The DPDK datapath in the transmit direction is very flexible. >>>>> The applications can build multisegment packets and manages almost >>>>> all data aspects - the memory pools where segments are allocated >>>>> from, the segment lengths, the memory attributes like external, >> registered, etc. >>>>> >>>>> In the receiving direction, the datapath is much less flexible, the >>>>> applications can only specify the memory pool to configure the >>>>> receiving queue and nothing more. In order to extend the receiving >>>>> datapath capabilities it is proposed to add the new fields into >>>>> rte_eth_rxconf structure: >>>>> >>>>> struct rte_eth_rxconf { >>>>> ... >>>>> uint16_t rx_split_num; /* number of segments to split */ >>>>> uint16_t *rx_split_len; /* array of segment lengthes */ >>>>> struct rte_mempool **mp; /* array of segment memory pools */ >>>>> ... >>>>> }; >>>>> >>>>> The non-zero value of rx_split_num field configures the receiving >>>>> queue to split ingress packets into multiple segments to the mbufs >>>>> allocated from various memory pools according to the specified >>>>> lengths. The zero value of rx_split_num field provides the backward >>>>> compatibility and queue should be configured in a regular way (with >>>>> single/multiple mbufs of the same data buffer length allocated from >>>>> the single memory pool). >>>> >>>> From the above description it is not 100% clear how it will coexist with: >>>>  - existing mb_pool argument of the rte_eth_rx_queue_setup() >>>>  - DEV_RX_OFFLOAD_SCATTER >>> >>> DEV_RX_OFFLOAD_SCATTER flag is required to be reported and configured >>> for the new feature to indicate the application is prepared for the >>> multisegment packets. >> >> I hope it will be mentioned in the feature documentation in the future, but >> I'm not 100% sure that it is required. See below. > I suppose there is the hierarchy: > - applications configures DEV_RX_OFFLOAD_SCATTER on the port and tells in this way: > "Hey, driver, I'm ready to handle multi-segment packets". Readiness in general. > - application configures BUFFER_SPLIT and tells PMD _HOW_ it wants to split, in particular way: > "Hey, driver, please, drop ten bytes here, here and here, and the rest - over there" My idea is to keep SCATTER and BUFFER_SPLIT independent. SCATTER is a possibility to make multi-segment packets getting mbufs from main rxq mempool as many as required. BUFFER_SPLIT is support of many mempools and splitting received packets as specified. >>> >>> But SCATTER it just tells that ingress packet length can exceed the >>> mbuf data buffer length and the chain of mbufs must be built to store >>> the entire packet. But there is the limitation - all mbufs are >>> allocated from the same memory pool, and all data buffers have the same >> length. >>> The new feature provides an opportunity to allocated mbufs from the >>> desired pools and specifies the length of each buffer/part. >> >> Yes, it is clear, but what happens if packet does not fit into the provided >> pools chain? Is the last used many times? May be it logical to use Rx queue >> setup mb_pool as well for the purpose? I.e. use suggested here pools only >> once and use mb_pool many times for the rest if SCATTER is supported and >> only once if SCATTER is not supported. > > It could be easily configured w/o involving SCATTER flag - just specify the last pool > multiple times. I.e. > pool 0 - 14B > pool 1 - 20B > ... > pool N - 512B > pool N - 512B > pool N - 512B, sum of length >= max packet size 1518 I see, but IMHO it is excessive. pools 0 .. N-1 could be provided in buffer split config, Nth should be in main RxQ mempool plus SCATTER enabled. > It was supposed the sum of lengths in array covers the maximal packet size. > Currently there is the limitation on packet size, for example mlx5 PMD > just drops the packets with the length exceeded the one queue is configured for. > >> >>> >>>>  - DEV_RX_OFFLOAD_HEADER_SPLIT >>> The new feature (let's name it as "BUFFER_SPLIT") might be supported >>> in conjunction with HEADER_SPLIT (say, split the rest of the data >>> after the header) or rejected if HEADER_SPLIT is configured on the >>> port, depending on PMD implementation (return ENOTSUP if both features >> are requested on the same port). >> >> OK, consider to make SCATTER and BUFFER_SPLIT independent as suggested >> above. > Sorry, do you mean HEADER_SPLIT and BUFFER_SPLIT? See above. >> >>> >>>> How will application know that the feature is supported? Limitations? >>> It is subject for further discussion, I see two options: >>> - introduce the DEV_RX_OFFLOAD_BUFFER_SPLIT flag >> >> +1 > OK, got it. > >> >>> - return ENOTSUP/EINVAL from rx_queue_setup() if feature is requested >>> (mp parameter is supposed to be NULL for the case) >> >> I'd say that it should be used for corner cases only which are hard to >> formalize. It could be important to know maximum number of buffers to >> split, total length which could be split from the remaining, limitations on split >> lengths. > Agree, the dedicated OFFLOAD flag seems to be preferable. > > With best regards, Slava > >> >>> >>>> Is it always split by specified/fixed length? >>> Yes, it is simple feature, it splits the data to the buffers with >>> required memory attributes provided by specified pools according to the >> fixed lengths. >>> It should be OK for protocols like eCPRI or some tunneling. >> >> I see. Thanks. >> >>> >>>> What happens if header length is actually different? >>> It is per queue configuration, packets might be sorted with rte_flow engine >> between the queues. >>> The supposed use case is to filter out specific protocol packets (say >>> eCPRI with fixed header length) and split ones on specific Rx queue. >> >> Got it. >> >> Thanks, >> Andrew. >> >>> >>> >>> With best regards, >>> Slava >>> >>>> >>>>> The new approach would allow splitting the ingress packets into >>>>> multiple parts pushed to the memory with different attributes. >>>>> For example, the packet headers can be pushed to the embedded data >>>>> buffers within mbufs and the application data into the external >>>>> buffers attached to mbufs allocated from the different memory pools. >>>>> The memory attributes for the split parts may differ either - for >>>>> example the application data may be pushed into the external memory >>>>> located on the dedicated physical device, say GPU or NVMe. This >>>>> would improve the DPDK receiving datapath flexibility preserving >>>>> compatibility with existing API. >>>>> >>>>> Signed-off-by: Viacheslav Ovsiienko >>>>> --- >>>>> doc/guides/rel_notes/deprecation.rst | 5 +++++ >>>>> 1 file changed, 5 insertions(+) >>>>> >>>>> diff --git a/doc/guides/rel_notes/deprecation.rst >>>>> b/doc/guides/rel_notes/deprecation.rst >>>>> index ea4cfa7..cd700ae 100644 >>>>> --- a/doc/guides/rel_notes/deprecation.rst >>>>> +++ b/doc/guides/rel_notes/deprecation.rst >>>>> @@ -99,6 +99,11 @@ Deprecation Notices >>>>> In 19.11 PMDs will still update the field even when the offload is not >>>>> enabled. >>>>> >>>>> +* ethdev: add new fields to ``rte_eth_rxconf`` to configure the >>>>> +receiving >>>>> + queues to split ingress packets into multiple segments according >>>>> +to the >>>>> + specified lengths into the buffers allocated from the specified >>>>> + memory pools. The backward compatibility to existing API is >> preserved. >>>>> + >>>>> * ethdev: ``rx_descriptor_done`` dev_ops and >>>> ``rte_eth_rx_descriptor_done`` >>>>> will be deprecated in 20.11 and will be removed in 21.11. >>>>> Existing ``rte_eth_rx_descriptor_status`` and >>>>> ``rte_eth_tx_descriptor_status`` >>> >