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 559FDA0032; Fri, 15 Jul 2022 13:34:44 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8D1DA42B6D; Fri, 15 Jul 2022 13:34:39 +0200 (CEST) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2057.outbound.protection.outlook.com [40.107.220.57]) by mails.dpdk.org (Postfix) with ESMTP id 81E3C40696 for ; Fri, 15 Jul 2022 13:34:37 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=n1E08w2suncxXzflr9U0KMBDX0kif5wwrj77IlY6FXszjKXWIBwoffc0CenH7Zq7pLpUzfcA9O3OVX+FyCHP+fOk7/D4k1CzVB8SaauhmZW2C7AGu1lmbznQ5ji75zFEmk0BMTaG8Msczi0mk+u2fKWciiSfbZjUAz2clbcdYSK3NYItPwLet0zpcboOUC9VZRsp6ygCcB4SH+w5bfURl16HL5q4lWvP0kXfirSuTDgOTZ9i0y6ODnJuaFzo6oSKku5kOWW/15g1BLczXkrvzDdVA/Qv7CE9kmarQfKre2LlTXsmtCbz1lTV0k+OA6sEPsUTVQidXvCHSQiF87Rxaw== 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=9AuqOjeKFe2Ik3Y9VGqO7uyrNBsevNCEq50QdVf1aJw=; b=GmRhv1X2FqysacJcC2/HlzJ+uMDK6GZH8pYDqPVX598O6I22Tc4efexRFwmvnZ2fbPFobhoUdEU9tM9MZTvTK1IU1+ZJzdbMV8axaleQG27zRpQx4gIU2Gol0qBhg54eiGMzHW1UVh0uaA/rFX9w8s4N9Jmbr8F6t3+nCS4YfII/prCIpOz3KNc9EUdJTzHhdyY4qVR+ovWkRbYpQ4YF8z5BdVv7dHi52ihfa4rHhoc0b9p9hukuc8GBW1702IQd5x7qNlD6jMsfSuX1dqyyQWVf4qCWKCO+XS8G3Kmsd3kSlFusjx/dqXR+rHrZMe8WZic5vYQuwPZwg8uPfeCebQ== 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=9AuqOjeKFe2Ik3Y9VGqO7uyrNBsevNCEq50QdVf1aJw=; b=fnr+YyJaZyv4uSYKTa7+g7mzEp7tDbx2dLz7zZroVaqAJEizTweSm43jWcQka1UQOzmmepssMTPdG12fkER2WyZ2GWT4Hf2OW3bE4+sMtQ3C7tSJx5uRSR3tA0nde0zKa5jFyx3U1H57GeF0rzEmyOXXZjBTiKz+b9dnaA1QZd0= Received: from SA9PR11CA0011.namprd11.prod.outlook.com (2603:10b6:806:6e::16) by MWHPR02MB2254.namprd02.prod.outlook.com (2603:10b6:300:5a::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5417.21; Fri, 15 Jul 2022 11:34:34 +0000 Received: from SN1NAM02FT0027.eop-nam02.prod.protection.outlook.com (2603:10b6:806:6e:cafe::27) by SA9PR11CA0011.outlook.office365.com (2603:10b6:806:6e::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5438.14 via Frontend Transport; Fri, 15 Jul 2022 11:34:34 +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-pvapexch02.xlnx.xilinx.com; pr=C Received: from xir-pvapexch02.xlnx.xilinx.com (149.199.80.198) by SN1NAM02FT0027.mail.protection.outlook.com (10.97.4.212) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.5438.12 via Frontend Transport; Fri, 15 Jul 2022 11:34:34 +0000 Received: from xir-pvapexch01.xlnx.xilinx.com (172.21.17.15) by xir-pvapexch02.xlnx.xilinx.com (172.21.17.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.14; Fri, 15 Jul 2022 12:34:32 +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; Fri, 15 Jul 2022 12:34:32 +0100 Envelope-to: xuan.ding@intel.com, viacheslavo@nvidia.com, thomas@monjalon.net, andrew.rybchenko@oktetlabs.ru, 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 [10.71.194.74] (port=51474) by smtp.xilinx.com with esmtp (Exim 4.90) (envelope-from ) id 1oCJaa-0005PI-FW; Fri, 15 Jul 2022 12:34:32 +0100 Message-ID: Date: Fri, 15 Jul 2022 12:34:28 +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 To: "Ding, Xuan" , Slava Ovsiienko , "NBU-Contact-Thomas Monjalon (EXTERNAL)" , "andrew.rybchenko@oktetlabs.ru" 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> From: Ferruh Yigit In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 9a397311-a3a2-4c12-4497-08da6655fde6 X-MS-TrafficTypeDiagnostic: MWHPR02MB2254:EE_ X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: vs4gJt0+ZBjNS1h3FiGh0YfUzpv7fPQunDA/dXoaym6z8SlVIAzer8olFhy01csp6k+8WTVHVSvOQb0hfEkDg4biQ/h7jy1vMN73NfzZjWqtFBt12GoujlH4Le+s0VhtV6XXIiMTT4Q0ZNAwWtY6vTWG2+De/C4umkp3HhZIzKDV7ew4nRxANPwnCjP1dofUP/MN9HjbnSQiUnGx0KjoJg6kiv6ntIIsMqKcy3jypQ0vgZZ8+jhC0v+kZD0IEEJgqTqd6KHqc3r4roN0pT8Zqffj/Rq5t8K2Z7gaeQPf/mh+rqHLUN+BMcjBgWUirVfoVKroSY+0ELUPQBWFN/m/Am8OEYIdy8mdrX0gY6+j5i/CGySVMRetLqTygZ1S7m/fWlyCeXhTuCTgtPfyyVPiM95drl9l7kaKR/GF1rAluzSWr/j9bGY29OXOCWapnMqEYverIjCRZq8vtdmS021IHzFKDZJIZ5f/W/yCKoUJy/O8AMiozYJZcwI6/hAkx3yklhLeoihTL0DQRFjrQl7hmhXvUfy8ts3eQEvDdZ42yFQEiOPOxdFdcEhKFF81cexyfr+5ckbf6/nEBgR5A9gH1vXQSmGaXef8M2X6TNhtqvdkqwb2Pt8/2LS0aCVkO8DUoWuHZD3mU2DSIGSSiFNu0g0SvlT52XIGqpvitBsHGPx6+R8pASdYgU9MhLyrAQozN3+q46e2Q5NcYM/R/vNbI31R1GSvzDMSxFnpfrvwhZvNV7/1H+1owefXyCuviqoQZgEVLKuIw8jZrGFthzwISsFGkApy7ZSurwhzBM1LLGTO+grdo1+fKRRViJHYt4/5Ac7YxjFY193oWwNaoQjwn0+0UKneimNuN3oaVLXCHV4UxCQd6uTFGjwC8SLKvLS6jETk9UrzKR+nF0/bW8xTYS5PTNYNUiysNUBLJiSPqAGm5xZkLA2+gS/KLKN4IJYJ X-Forefront-Antispam-Report: CIP:149.199.80.198; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:xir-pvapexch02.xlnx.xilinx.com; PTR:unknown-80-198.xilinx.com; CAT:NONE; SFS:(13230016)(4636009)(346002)(396003)(39860400002)(376002)(136003)(40470700004)(36840700001)(46966006)(2906002)(966005)(26005)(40480700001)(478600001)(5660300002)(53546011)(82310400005)(8936002)(6666004)(4326008)(70586007)(36860700001)(7636003)(41300700001)(70206006)(44832011)(7416002)(110136005)(8676002)(316002)(54906003)(9786002)(83380400001)(82740400003)(336012)(31696002)(47076005)(426003)(40460700003)(36756003)(186003)(2616005)(356005)(31686004)(50156003)(43740500002)(562404015); DIR:OUT; SFP:1101; X-OriginatorOrg: xilinx.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jul 2022 11:34:34.1670 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9a397311-a3a2-4c12-4497-08da6655fde6 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-pvapexch02.xlnx.xilinx.com] X-MS-Exchange-CrossTenant-AuthSource: SN1NAM02FT0027.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR02MB2254 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/15/2022 9:28 AM, Ding, Xuan wrote: > Hi, > >> -----Original Message----- >> From: Slava Ovsiienko >> Sent: Friday, July 15, 2022 12:56 AM >> To: Ferruh Yigit ; Ding, Xuan >> ; NBU-Contact-Thomas Monjalon (EXTERNAL) >> ; andrew.rybchenko@oktetlabs.ru >> 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 >> Subject: RE: [PATCH] doc: announce header split deprecation >> >>> -----Original Message----- >>> From: Ferruh Yigit >>> Sent: Thursday, July 14, 2022 18:58 >>> To: Ding, Xuan ; NBU-Contact-Thomas Monjalon >>> (EXTERNAL) ; andrew.rybchenko@oktetlabs.ru; >> Slava >>> 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 >>> Subject: Re: [PATCH] doc: announce header split deprecation >>> >>> 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. >> >> Hi, thank you for Cc'ing >> >> Yes, you are right, we have two splitting offloads, and these ones have the >> different intentions. As there are no PMDs actually handling >> RTE_ETH_RX_OFFLOAD_HEADER_SPLIT, there should be no objections for >> this deprecation. > > Thanks for helping review. > > For 'BUFFER_SPLIT', I think it is clear. As Ferruh explains, it is used for splitting packets into multi-segments and multi-mempools based on rte_eth_rxseg_split. > Right now only mlx5 supports this offload. > > For 'HEADER_SPLIT', IMO it is used for splitting packets into two segments based on the split_hdr_size in rte_eth_rxmode. > And header split does not support split into multi-mempools(the same mempool). > I looks like we don't have much details on the intention of the 'HEADER_SPLIT', it is not well documented. > So at this level, we can say that header split and buffer split are the same intention (split packets). > The functions supported by header split have been covered by buffer split. And no PMD actually supports 'HEADER_SPLIT'. > > Please corrects me if my understanding is wrong. > > Thanks, > Xuan > > >> >> Acked-by: Viacheslav Ovsiienko >> >