From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 9416CA0032; Thu, 14 Jul 2022 18:03:21 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D839B42B98; Thu, 14 Jul 2022 18:03:19 +0200 (CEST) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2042.outbound.protection.outlook.com [40.107.94.42]) by mails.dpdk.org (Postfix) with ESMTP id 6403542B93 for ; Thu, 14 Jul 2022 18:03:17 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=E88X+kek/jM4PSP3kNtidG2CYjbymeC59dKoWUDtFmSIeFdJoWEHlmeg3BfpLEY4/7IzP5ZHeL1FEQ5zpmJi3h8BESb55M24+LnWduqevp5dj6Y7wXrwQPa52xCHGOmEHpmFZLBKlb+9GKNgDbM3lB7OIXi8i7Mh2iOKZ6hqplRv16i8LzsoALbYRc4fwMM0iKd6uGzk5X8nX1E8tlr+PIP1GJ/TBbzY1rJ3sPbJmS+cy2XdwRMFU01tqf6v7irVsBjkh3Oq1Y/Q5o9fpwaG1uU77T4LXJlTor2hPch7A6lUJN9ssDEZULCtNi5DrYZWLban1Dr14q5TheDcmsv0lg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=kUzqUP0FYh/1bVfIWPMokfCMYbqSs+/CS5gwGQ0DCJQ=; b=GO9IhhdpyXiLsp5LXfubDEyuECneszZdlBH3XMl7XOYGSlqelznyFxh93AZX3vWfe9xEc0/N08xMpOWDlUi949aXYqE9kXY4Mk7+HfNJ5G0Xel/pZ2+0GbMxr688B64XIaiKEF0d+4DmrH/7Y4LrS17gY7gA1L3MsoGzCxqjrSLGvu94HQIi9NyKkRef3DEXYC+VjXaUFXjLBF8K4zk4E5yAzIH97fM7ksGeKR1XgSKCz2KUEWTvQnNnAM0anMYjMUhJ0kkXLJUCeDPbWfi66RjgYZXfLFFLaJEjN1W0j0wyIfjcNwW1IhhOlOzWmosxzuExZDgZMV1d7kmnXnQwkQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 149.199.80.198) smtp.rcpttodomain=intel.com smtp.mailfrom=xilinx.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=xilinx.com; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xilinx.onmicrosoft.com; s=selector2-xilinx-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kUzqUP0FYh/1bVfIWPMokfCMYbqSs+/CS5gwGQ0DCJQ=; b=MaBrGYuJQlQHzTPY6mcxxHobJa+BHpSaO3mDmu1cxyjqMMshj6AstL2w9lw6eDGPIodAYowQz57usBwfs8HLaWOP4wzfRMRPN8KaisfqS/df1Vfl40oTzOJ3LM3asNiBn5fLaVyo5V6Xwm6XFqisUpE+Vb+yeujj/f8wyVTxmvs= Received: from BN9PR03CA0353.namprd03.prod.outlook.com (2603:10b6:408:f6::28) by BYAPR02MB5445.namprd02.prod.outlook.com (2603:10b6:a03:a4::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5417.26; Thu, 14 Jul 2022 16:03:14 +0000 Received: from BN1NAM02FT028.eop-nam02.prod.protection.outlook.com (2603:10b6:408:f6:cafe::77) by BN9PR03CA0353.outlook.office365.com (2603:10b6:408:f6::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5417.17 via Frontend Transport; Thu, 14 Jul 2022 16:03:14 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 149.199.80.198) smtp.mailfrom=xilinx.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=xilinx.com; Received-SPF: Pass (protection.outlook.com: domain of xilinx.com designates 149.199.80.198 as permitted sender) receiver=protection.outlook.com; client-ip=149.199.80.198; helo=xir-pvapexch01.xlnx.xilinx.com; pr=C Received: from xir-pvapexch01.xlnx.xilinx.com (149.199.80.198) by BN1NAM02FT028.mail.protection.outlook.com (10.13.2.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.5438.12 via Frontend Transport; Thu, 14 Jul 2022 16:03:14 +0000 Received: from xir-pvapexch01.xlnx.xilinx.com (172.21.17.15) by xir-pvapexch01.xlnx.xilinx.com (172.21.17.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.14; Thu, 14 Jul 2022 17:03:13 +0100 Received: from smtp.xilinx.com (172.21.105.198) by xir-pvapexch01.xlnx.xilinx.com (172.21.17.15) with Microsoft SMTP Server id 15.1.2176.14 via Frontend Transport; Thu, 14 Jul 2022 17:03:13 +0100 Envelope-to: xuan.ding@intel.com, thomas@monjalon.net, andrew.rybchenko@oktetlabs.ru, viacheslavo@nvidia.com, mdr@ashroe.eu, dev@dpdk.org, stephen@networkplumber.org, mb@smartsharesystems.com, qi.z.zhang@intel.com, asekhar@marvell.com, pbhagavatula@marvell.com, grive@u256.net Received: from [172.21.36.148] (port=58206) by smtp.xilinx.com with esmtp (Exim 4.90) (envelope-from ) id 1oC1J2-0001v7-To; Thu, 14 Jul 2022 17:03:13 +0100 Message-ID: Date: Thu, 14 Jul 2022 17:03:12 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.0.2 Subject: Re: [PATCH] doc: announce header split deprecation Content-Language: en-US From: Ferruh Yigit To: "Ding, Xuan" , Thomas Monjalon , "andrew.rybchenko@oktetlabs.ru" , Viacheslav Ovsiienko CC: "mdr@ashroe.eu" , "dev@dpdk.org" , "stephen@networkplumber.org" , "mb@smartsharesystems.com" , "Zhang, Qi Z" , "asekhar@marvell.com" , "pbhagavatula@marvell.com" , "grive@u256.net" References: <20220523142016.44451-1-xuan.ding@intel.com> <6226385.mzcYPaeBD7@thomas> <5613126.F5Vx1aKkY9@thomas> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 572cfc68-6a90-46fa-3cb3-08da65b25bcc X-MS-TrafficTypeDiagnostic: BYAPR02MB5445:EE_ X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: t05tPA8lG9/O76vR7N40tKRgzLHInkyaPZzU1tLnOt6hrPRajQG5bsGojGp/fgJrPG6HOX3e4jppDJljohISgFaGGUpllzPMqtV8oy2YAMHBhXKxX1K9PCLMLl3IspPAvgDCITzxzwUf774PoHrHciZ11oP43an71bRkQFevd6BBQGUVBPhz+AJ+iHYFHcFPaGUpRMoAfvJ3+s9E4E4mTj8DNbAaUEOAx1LeH6ztHHZ2+TE7gZH7/8LHsE55F8UAmN32aqQ10wF9e7f+UffOScCc2J/uyAlvvdcP4Mjl8v2iy7ldes3tU+aqf+wpCh6GeZrn9hke+2PfqNxdYxSWnTLPc3TfUAPoRftehRxMsGebEgKPKV96+FFHhvAb3hzsTcmxTBWc6lrOhczbmi6GkHP65V32eu3wB843IGVOchLtgWf4ipOARdFRy7fuwG9TFq9I2D0WJqRDJFt0+HhvMbvS9hyAAjBwcJJ1SAPpWLAHVYoQ3NqXd2KOxzyHKfqoxAkqdQBsyDk6Q1TbSjpkEoWlayVyVWuevA0MaYChQ2SaA4wQ7a2yisB4Su9MTLstP3IQxy3iZwL1NJt+OVIETO9sjEnDChQm5HIMoVhi24r+/sPtH2UFfVEFWvK1DFzNiGqrspd5m8mtupcwsRpZKQFm3OsArryVF2561lQQ3dp0y8fPsDGcQLuTdccd9HiciIEpfSzHhaGvVK14p9JFDqq/2wpsNeWWlvnGEIl/C9oOsy2XaS+a7+2ai13KFpezedrhvumrAflvPuVY0Xh14JbQv2SteeYnF5vozzeIJ6Y8sgrOgABHrvkryh5UUqBik0GmR7RCaeYQjuD7jMgkpqcK5CXfbWghPTfMfvziW3THI5EyAhyXZkQnxujAC//vbRiYMylvR5gx6BKmQkpXPw== X-Forefront-Antispam-Report: CIP:149.199.80.198; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:xir-pvapexch01.xlnx.xilinx.com; PTR:unknown-80-198.xilinx.com; CAT:NONE; SFS:(13230016)(4636009)(396003)(136003)(346002)(376002)(39860400002)(40470700004)(46966006)(36840700001)(36756003)(186003)(44832011)(7636003)(7416002)(40460700003)(54906003)(2906002)(5660300002)(31686004)(110136005)(36860700001)(336012)(2616005)(47076005)(478600001)(82740400003)(356005)(966005)(8676002)(82310400005)(26005)(40480700001)(316002)(9786002)(426003)(41300700001)(83380400001)(31696002)(8936002)(53546011)(70586007)(4326008)(70206006)(50156003)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: xilinx.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jul 2022 16:03:14.3323 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 572cfc68-6a90-46fa-3cb3-08da65b25bcc X-MS-Exchange-CrossTenant-Id: 657af505-d5df-48d0-8300-c31994686c5c X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=657af505-d5df-48d0-8300-c31994686c5c; Ip=[149.199.80.198]; Helo=[xir-pvapexch01.xlnx.xilinx.com] X-MS-Exchange-CrossTenant-AuthSource: BN1NAM02FT028.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR02MB5445 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On 7/14/2022 4:58 PM, Ferruh Yigit wrote: > On 7/14/2022 3:07 PM, Ding, Xuan wrote: >> Hi, >> >>> -----Original Message----- >>> From: Thomas Monjalon >>> Sent: Thursday, July 14, 2022 9:25 PM >>> To: Ding, Xuan ; andrew.rybchenko@oktetlabs.ru; >>> ferruh.yigit@xilinx.com >>> Cc: mdr@ashroe.eu; dev@dpdk.org; stephen@networkplumber.org; >>> mb@smartsharesystems.com; dev@dpdk.org; Zhang, Qi Z >>> ; asekhar@marvell.com; pbhagavatula@marvell.com; >>> grive@u256.net >>> Subject: Re: [PATCH] doc: announce header split deprecation >>> >>> 14/07/2022 14:54, Ding, Xuan: >>>> Hi, >>>> >>>> From: Thomas Monjalon >>>>> 14/07/2022 07:50, Ding, Xuan: >>>>>> From: Thomas Monjalon >>>>>>> 23/05/2022 16:20, xuan.ding@intel.com: >>>>>>>> From: Xuan Ding >>>>>>>> >>>>>>>> RTE_ETH_RX_OFFLOAD_HEADER_SPLIT offload was introduced >>> some >>>>> time >>>>>>> ago >>>>>>>> to substitute bit-field header_split in struct rte_eth_rxmode. >>>>>>>> It allows to enable header split offload with the header size >>>>>>>> controlled using split_hdr_size in the same structure. >>>>>>>> >>>>>>>> Right now, no single PMD actually supports >>>>>>>> RTE_ETH_RX_OFFLOAD_HEADER_SPLIT with above definition. Many >>>>>>>> examples and test apps initialize the field to 0 explicitly. >>>>>>>> The most of drivers simply ignore split_hdr_size since the >>>>>>>> offload is not advertised, but >>>>>>> some double-check that its value is 0. >>>>>>>> >>>>>>>> So the RTE_ETH_RX_OFFLOAD_HEADER_SPLIT and split_header_size >>>>> field >>>>>>>> will be removed in DPDK 22.11. >>>>>>>> >>>>>>>> Signed-off-by: Xuan Ding >>>>>>>> --- >>>>>>>>   doc/guides/rel_notes/deprecation.rst | 4 ++++ >>>>>>>>   1 file changed, 4 insertions(+) >>>>>>>> >>>>>>>> diff --git a/doc/guides/rel_notes/deprecation.rst >>>>>>>> b/doc/guides/rel_notes/deprecation.rst >>>>>>>> index 4e5b23c53d..b8114f29ed 100644 >>>>>>>> --- a/doc/guides/rel_notes/deprecation.rst >>>>>>>> +++ b/doc/guides/rel_notes/deprecation.rst >>>>>>>> @@ -125,3 +125,7 @@ Deprecation Notices >>>>>>>>     applications should be updated to use the ``dmadev`` library >>> instead, >>>>>>>>     with the underlying HW-functionality being provided by the >>>>>>>> ``ioat`` >>> or >>>>>>>>     ``idxd`` dma drivers >>>>>>>> + >>>>>>>> +* ethdev: After bit-field header split was removed, the >>>>>>>> +``RTE_ETH_RX_OFFLOAD_HEADER_SPLIT`` >>>>>>>> +offload and the ``split_hdr_size`` field in structure >>>>>>>> +``rte_eth_rxmode`` to enable header split offload are not >>>>>>>> +supported in any >>>>>>> PMDs. They will be removed in DPDK 22.11. >>>>>>> >>>>>>> It would have been good to talk about rte_eth_rxseg_split which >>>>>>> is similar and configured per-queue. >>>>>> >>>>>> Thanks for your suggestion. >>>>>> >>>>>> But I'm a little confused, are you referring that I need to >>>>>> involve protocol >>>>> based buffer split? >>>>>> About the deprecation of header split, I haven't realized its >>>>>> connection to >>>>> rte_eth_rxseg_split. >>>>> >>>>> What??? >>>>> In old versions of your patch "ethdev: introduce protocol type based >>>>> header split" >>>>> you wrote: >>>>> " >>>>> A new proto field is introduced in the rte_eth_rxseg_split structure >>>>> reserved field to specify header protocol type. >>>>> With Rx offload flag RTE_ETH_RX_OFFLOAD_HEADER_SPLIT enabled and >>>>> protocol type configured, PMD will split the ingress packets into >>>>> two separate regions. >>>>> " >>>> >>>> It has a long history... >>>> It was corrected in v4 that RTE_ETH_RX_OFFLOAD_HEADER_SPLIT is used to >>>> enable header split offload with the header size controlled using >>> "split_hdr_size". >>>> But no single PMD actually supports RTE_ETH_RX_OFFLOAD_HEADER_SPLIT >>> for this purpose. >>>> So we finally decide to deprecate this flag. >>>> >>>> http://patchwork.dpdk.org/project/dpdk/patch/20220402104109.472078- >>> 2-w >>>> enxuanx.wu@intel.com/ >>>> >>>> In following series, I use RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT instead. It >>>> is for multi-segments packet split. And it still needs a "proto_hdr" >>>> field in >>> rte_eth_rxmode to configure split location. >>> >>> I know this history because I was the one asking you to deprecate this. >>> But it seems you didn't get the big picture. >>> >>>>>> Currently there are 2 acks, add more PMD maintainers to help >>>>>> review this deprecation notice for header split, thanks a lot! >>>>> >>>>> I cannot say my feeling strong enough. >>>> >>>> So IMO the deprecation for header split is not relevant with buffer >>>> split. But >>> we can still clean the code. >>>> Hope it make things clearer. >>> >>> They are almost the same features. >>> So when deprecating one, it is important to mention what remains. >>> If needed RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT can still be used and it is >>> configured per-queue, while RTE_ETH_RX_OFFLOAD_HEADER_SPLIT was >>> configurable per-port. >> >> Thanks for your clarification. It's clearer now. >> I was trying to figure out the whole history of header split, >> seems it is not enough. >> > > Isn't the intention of 'RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT' & > 'RTE_ETH_RX_OFFLOAD_HEADER_SPLIT' are different? > Cc'ed Slava for more comment. > > As far as I understand 'BUFFER_SPLIT' has a target to split package > based on size, to various size mempools, and it can split the payload as > well without caring the protocol headers. > Most probably practical usage is to split inner protocol, but protocol > not needed to be known by NIC, it can still split based on size. > Ahh, deprecation notice is to deprecate 'HEADER_SPLIT', not other way around as I got it wrongly. I think both may have use case, specially for NICs that parse the protocols, header split can be easier to use. But since there is no user for a long time, perhaps that is not a real life need, and we can always add it back when needed, hence: Acked-by: Ferruh Yigit > > Also as far as I can see mlx5 implemented the feature [1], contradicting > the claim in the commit log, again Slava can comment better. (Although I > don't see any PMD claim "Buffer Split on Rx" feature supported.) > > > [1] > Commit 9f209b59c8b0 ("net/mlx5: support Rx buffer split description") > >>> >>> Andrew, Ferruh, do you agree to improve this deprecation notice by >>> adding >>> above information? >> >> Agree. It is better to point out the remaining per queue >> rx offload RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT for splitting packets. >> >> Please see v2 after I add more header split background. >> > > I can't see a v2 in patchwork, is a v2 sent? If so, may be something > went wrong. >