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 E7343A0032; Thu, 14 Jul 2022 17:58:30 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8A25342847; Thu, 14 Jul 2022 17:58:30 +0200 (CEST) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2056.outbound.protection.outlook.com [40.107.244.56]) by mails.dpdk.org (Postfix) with ESMTP id 0C1D341156 for ; Thu, 14 Jul 2022 17:58:28 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TJq4C7w39IUicmrBLwD8xwAvGVT1ik1iA+bTr6oWF5aPbrwQ/gLcunV9wO8lYtG6kxALcrLsDz+mZ3zrsSJhuyKr7kp3H+T20jcVpvuCiTgsLtN4tfTR41VOuGjsgjusOa3eQ+tx14RbXAVU0VCkjz6DHTxyhSLzMGV2PGXQ+ngeyOvweH9OELXWnQf7vV653mrM2EOC5BUIBSMJHFZR6HEpwYn9bGcvLknGjRcDBXECxTT2ugvQM7mYW5odbe8RgzrhjHIh7WXti76kQmu4g7YljURdVX5uyjyTNXAQjzdojNc2bT5X5+3G6e25I3wFtyAZxU0c82O7hAwxjHYKMA== 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=0AMxoJA2AzZkKerZZ51Di1cIeGZwUokvrso270+pRvw=; b=BoX1080sfPViVlmrO3w5PgovS1/JnXB3cdIEseXOf3hp5nqQL/ul/Rv2QKuw4pkgUXr9tAiE8GHuNDiGDpktXK8JkU4ORisAjMCQKbq/3ljI1YyNGluK5G5DyuLU3OwcMM/YDLtwTpY8qhtAcvm8CVPzoA7blFPARLJbEX8Pr5seW75hVcPPBgxf15Z7DbsLRcdXfQntKwD4dp+KOOXjG7X+36chUtbUChbVIac3FBxjJVT38ieSvO1ucwBgYXJKzdC7NgYYCfQletKYoZEGOjkAQrAYvd4vLKNO19/HKFlqz/266otd6Gd5jFLmQb4YBrx9iGRT8H1VW+K3oTU9aA== 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=0AMxoJA2AzZkKerZZ51Di1cIeGZwUokvrso270+pRvw=; b=D7aINYyYv2nFYhq0NWl9PrrmfDf2i3eLsKRQAjZbdmB0TwWdvgfdae0v2ri1D5dykVyUwBqC12uPS481Q6qfF9zW6jYfZl/Ed4kgTPTQYujwY/oC8/Fl8ugh25VmZ8DtW7yCcEuUY/8ZWzgFOoeBLuEbShMe3v4hnlzuUnTcv3I= Received: from SA9PR10CA0003.namprd10.prod.outlook.com (2603:10b6:806:a7::8) by CY4PR02MB3349.namprd02.prod.outlook.com (2603:10b6:910:77::39) 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 15:58:25 +0000 Received: from SN1NAM02FT0063.eop-nam02.prod.protection.outlook.com (2603:10b6:806:a7:cafe::d) by SA9PR10CA0003.outlook.office365.com (2603:10b6:806:a7::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5438.17 via Frontend Transport; Thu, 14 Jul 2022 15:58:25 +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 SN1NAM02FT0063.mail.protection.outlook.com (10.97.5.98) 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 15:58:24 +0000 Received: from xir-pvapexch02.xlnx.xilinx.com (172.21.17.17) 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; Thu, 14 Jul 2022 16:58:23 +0100 Received: from smtp.xilinx.com (172.21.105.197) by xir-pvapexch02.xlnx.xilinx.com (172.21.17.17) with Microsoft SMTP Server id 15.1.2176.14 via Frontend Transport; Thu, 14 Jul 2022 16:58:23 +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=51086) by smtp.xilinx.com with esmtp (Exim 4.90) (envelope-from ) id 1oC1EM-0006gv-Rm; Thu, 14 Jul 2022 16:58:23 +0100 Message-ID: Date: Thu, 14 Jul 2022 16:58:22 +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" , 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> 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: 97451deb-cd83-4332-20fd-08da65b1af40 X-MS-TrafficTypeDiagnostic: CY4PR02MB3349:EE_ X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ENa7f4Yv9QUY3znFZJIOqfLMsmSuLlzB92nTFfm0ODvHyMcOixY/6po9rZ98G/ylLFM1fg++y0wkEU4t07WQxG/KZ8/s5mlx/XNREB2Z0SDQZHP1JqKZlZSrSPn3yY0bCwTlxMuQqt0d/LlkPfL8VoIwvglBLMQD8KSlgYauhsPB83tEiz7expOBMxDVhIVs9lpaJhYIPUevvx+dwsHnROIO/nylLuqau7M7ncnR54yN574w15d6fgUSSsS/pOVvEf9HyjGHfCjE9hoVTWb4+HgtQ51qf2tq+wm5Q8RUhsc7YamHKixdDgDT2mB5GVllCd9Vn2aNL/9ZdiELPAH8aZRepUBtoOq+nPPQKP+yt67COIIYcVu3PTJgNf+UD0S+f8oTb/gXga3NjxtaY4LDKuGSYIm9375gd3sO46ZFu45ILa8hZ14cXz6PM1X1wiACFx9NAhMX9Z8wxDZnNyop477YS95EUUEH2YiduYLoGvb8+eZPatB38TNIHfX4R+YsENQeL/EgHJ6JajCI4KLn0K/gASBOdQH/dZjQNqIJzj3uccHYQz0f2bp2E239gXJOV7oipu5JvwWdKhqoHhV3150InNSYeWwPZXaFZ2G1EzWn0R+e1wIXdBdkLyTSSJZIY8Ng/4FFzhZZlEo5Y0RaJfR54BsmBVdZnBKUNiPWTWCckGc33nVxsrQXm+/Ulrc+1pIU+4PrDO17RvJp2pvM3GPfWfyVjefR83Rtrew0S2cxTmrK/qbE9fB/oXuTxfQXnTLrsw2cohEfDWMitWMeiX8uOBlGht92CPJgiHL9VK8aNljbaCwJcvBmdjMMUn/qAWgL3QTYHQb13CI6hcmLsFDV0PK8RHmGnL7W2O+56lYR6YEUiIX1snaGp5RGOuK3gp52/SpvGvD+qKkcCoojMw== 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)(376002)(136003)(396003)(346002)(39860400002)(36840700001)(40470700004)(46966006)(110136005)(54906003)(36860700001)(5660300002)(82310400005)(36756003)(316002)(8676002)(83380400001)(82740400003)(31686004)(40480700001)(356005)(4326008)(7636003)(70586007)(70206006)(41300700001)(31696002)(966005)(40460700003)(186003)(2616005)(478600001)(2906002)(8936002)(7416002)(9786002)(26005)(336012)(426003)(47076005)(53546011)(44832011)(50156003)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: xilinx.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jul 2022 15:58:24.7522 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 97451deb-cd83-4332-20fd-08da65b1af40 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: SN1NAM02FT0063.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR02MB3349 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 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. 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.