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 5A998A0C46; Tue, 7 Sep 2021 10:47:39 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D6886410EC; Tue, 7 Sep 2021 10:47:38 +0200 (CEST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by mails.dpdk.org (Postfix) with ESMTP id 0D739410EB for ; Tue, 7 Sep 2021 10:47:36 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10099"; a="242422190" X-IronPort-AV: E=Sophos;i="5.85,274,1624345200"; d="scan'208";a="242422190" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Sep 2021 01:47:36 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.85,274,1624345200"; d="scan'208";a="605133325" Received: from orsmsx604.amr.corp.intel.com ([10.22.229.17]) by fmsmga001.fm.intel.com with ESMTP; 07 Sep 2021 01:47:35 -0700 Received: from orsmsx604.amr.corp.intel.com (10.22.229.17) by ORSMSX604.amr.corp.intel.com (10.22.229.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Tue, 7 Sep 2021 01:47:35 -0700 Received: from orsedg603.ED.cps.intel.com (10.7.248.4) by orsmsx604.amr.corp.intel.com (10.22.229.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12 via Frontend Transport; Tue, 7 Sep 2021 01:47:35 -0700 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.176) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.10; Tue, 7 Sep 2021 01:47:35 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SFBfQtdDrfZ2UPS/jABhtb5hkK8WvHlovtjqmBmkCCPb4BmuRD6q4TIAgTBN0HJjj1H2Ogo0nQN8ZAyOyqHqoXiqb6EQYY1xV+qJwDkvLRWqJm/BNiRs3Y4VQlWfGsYuX0WU/oLnwGL/mk6zyAguG1ae78k7SxJQkvCgzjGvcmI+cVFXWAGT/ijICMUR2RNqluYSFKAgfg+rkhTj3sqH8Iws+AvsLhMb4e1gdahublh5zJhpsMrrIQgU9+vSMaYm6n9RK6cwKbMCrSICnf6LCnMpraaFT1T/Gd5svaxMDUUoyc1ad1Tlg4zVSffOT3Pk3uCw3Zw/634sBUUto9l4dg== 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-SenderADCheck; bh=31SSd5wXbZMEDoFE4x2hMemiDaLldn90Msa21hj3WrM=; b=NShd36sENgmi2G5cy5xYAnWLmqpcKiOl/zbAcOtAStv2A5eMlTmgA2hkAQ0JvYyA3P4vzRxIlRg0ezY/yi17N761oyFSG1bcXwYxFNJxo069iNsiqNKz+X8DgOOHSIdo2+UudCAKERz8B5MgRUZGWMgQcxY6x14Da6c3ICoufMhMfKTXqayo6draKcm1Yx1S2RFOif9/8wPKOq23PeN141VZfTv7uHDepTqF/DWU7PIrQDymazLOzjYjnyIFZA9jpNUckJZaisp8vsopP5jdz/dJD3z8QK2OwGgG3UFPUmN+Slm8jnlRAUUJdz2Svt8orc4Wpn6ZiMrt2PiZeFIlqQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=31SSd5wXbZMEDoFE4x2hMemiDaLldn90Msa21hj3WrM=; b=sTZZKcb2v+s+Z98msJUwj+3VUMWlxc6sCe5fnGMps3A5mQUxZZyMuzg3sBg3XvFW1MTeH0auA+yAHJEvCq/mPE0vTWRDhDUALo7DC/SfnZPcK7mRIUCdnjwDVHvGw03ZQsO7LMNlffHG1iCY4SdxzPUlVLFnimdXDquHTQXfQtI= Authentication-Results: oktetlabs.ru; dkim=none (message not signed) header.d=none;oktetlabs.ru; dmarc=none action=none header.from=intel.com; Received: from PH0PR11MB5000.namprd11.prod.outlook.com (2603:10b6:510:41::19) by PH0PR11MB5030.namprd11.prod.outlook.com (2603:10b6:510:41::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.23; Tue, 7 Sep 2021 08:47:34 +0000 Received: from PH0PR11MB5000.namprd11.prod.outlook.com ([fe80::747b:3a08:d1ec:31fc]) by PH0PR11MB5000.namprd11.prod.outlook.com ([fe80::747b:3a08:d1ec:31fc%5]) with mapi id 15.20.4478.025; Tue, 7 Sep 2021 08:47:34 +0000 To: Akhil Goyal , CC: , , , , , , , , References: <20210823100259.1619886-1-gakhil@marvell.com> From: Ferruh Yigit X-User: ferruhy Message-ID: <06b92d82-f8af-fab0-58aa-9b977ec0f3a1@intel.com> Date: Tue, 7 Sep 2021 09:47:27 +0100 In-Reply-To: <20210823100259.1619886-1-gakhil@marvell.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: DB6PR0301CA0087.eurprd03.prod.outlook.com (2603:10a6:6:30::34) To PH0PR11MB5000.namprd11.prod.outlook.com (2603:10b6:510:41::19) MIME-Version: 1.0 Received: from [192.168.0.206] (37.228.236.146) by DB6PR0301CA0087.eurprd03.prod.outlook.com (2603:10a6:6:30::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4500.14 via Frontend Transport; Tue, 7 Sep 2021 08:47:32 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: bf77ae9d-3c08-43e6-d024-08d971dc22db X-MS-TrafficTypeDiagnostic: PH0PR11MB5030: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Vt+6WJfjy66gnIoN2d9BuaVrgO4/zSEfxq5hOcD+1DipVBRHyBG9cukV1WN62PVic6Qu2+NE90WD0wGa4SDjaIFxaqqT0NUrHVX66alfVGmwM+v2btvHiztzUwE2cS1gER4MlJZBKNJvWoAIeTioQNZWW7fJGIh4cPvV0zpvCKJiGxF4XhvP9OieGJnDLIHdRPDOli4mz4ZN7JzGvakyt5sFrXaY3eJg5oosBxckBNsA2/1XILTAu91HrhHdjDfBfXLoUw7tZyVdsU7NLu+prGKFuSfzuWPEFVPwBFB2l3vydPqO96b0K7olThFQ7/RO5hpo0Row2Qy5sFD3xPo2mM4GpysCd9GKYU80GsUdnhZJWa7mZ6AhoXRdkVlrMy9bWbVvJSmpAczIejihBmAXtt4jA5LRbcVPvDxiXdvVPDpWoriugYUlYB6L7NnhUTga6XR3ODbr8ct3xm3CbUWNSlK4IetO7eIkQJ2fxV9k2PvU1kI6fog1cX9qS8SXcR5kxmmDmHja/gJGfZkuS+j5rHo1yLvpvHY9YneBOoEnKpDYTkLSMDEl52GRAQXUrbbwzSrS/h/N3AOw9yriRQSBfe2zYKpri7Rczjwb1QFpkRtZ8ydtQiG/tLndq+zvZJMAgGY4suAgz71JKslmMOFcxllCtyCyEeAbKQ0S6LywJNcVzOhZD7t5ivgqgrBPgTT2+JATcmV79nHuB15BKpZzzw== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB5000.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(346002)(376002)(396003)(39860400002)(366004)(4326008)(66556008)(6666004)(2906002)(66476007)(31686004)(478600001)(53546011)(83380400001)(31696002)(66946007)(38100700002)(8936002)(956004)(186003)(86362001)(44832011)(26005)(8676002)(36756003)(2616005)(316002)(16576012)(6486002)(5660300002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZFhYOGk4UWZnY04xNDh3RXlreDRtR2orU2tuZHVEUEhxU0Q0dXZWV3lkK1lJ?= =?utf-8?B?WDEyaDdUK3dGeE9xYXRwazVNZlBjS3FJdVRhWmdpNVY4L0RyY21kNG9EYUNt?= =?utf-8?B?c2d0K2FGdjRsSTIyVzFiNEQxU3V2RTRqZ0R6RTVDM2FMUFhqVXlQUi9RVGt6?= =?utf-8?B?U3RXeDFYTUlwMmZZZ3owOFVMa2V3d0RKSjViK2NMc2N0ZTdZNksyTWMyeThJ?= =?utf-8?B?cEVZNnVrdWVYUThYRnFqOXRhUVJvL2JuUE11b2xPd3VCTFN3VnpXK2hQN1c5?= =?utf-8?B?R2FxK0RSdGY4NUZVN1krVS9KYnhsS3RWM2xHeTM5eHJueExMSENncThZVDhu?= =?utf-8?B?dWMzSWhGWVgrd3lBaklhcTdwYys2cWRkSnptWTFSVGNjeURaOVNVY3prMnd5?= =?utf-8?B?Q0lqTDAybDlLL2x3UERTbXVCcEJFQjk2VUxaZG9kNjdpZ01zL0FSQkVSaXI2?= =?utf-8?B?bU1wSHlJemhQaXl1elliOVFvd25lR2VPMTd1S1VNTTFhalZiS0c1YndGMWtu?= =?utf-8?B?aEVTNjJiaG5Sa1BwakVOOWdHaE41d2p3Z0dFWWo1ZGtRVmdPT0Y3S2RPRzRn?= =?utf-8?B?ald3RWpseENzMmkyaW9idXVUTDlLb0hUN1RnZ0FsQy9GOWw4UlBFcU9UdFlo?= =?utf-8?B?MFh5MXRGRU91ejVWYkZvVEU2eW91dUdSTFcvdUZzVTAvZHIrU3VJeHp2NmZs?= =?utf-8?B?Mys1d09rU0hJU05OUDFFNnVtbWhHNndNM2ZiQ0ltZ21lY1pIYXp4M1RYWW9j?= =?utf-8?B?MTEweHkvMFY2ZHZ4Q0FrME9oOWpqWEs5WVZqaGZpa2YvOGt1Wmg3aWFEWTdO?= =?utf-8?B?dlVGRTNYUVJKT2VwZktVY3R4NGh3YWViaTVZRXc4WW15YVBmYzkwRlU2NzhL?= =?utf-8?B?TWpVbit1WlNJY085akZHV2JnUlhPeUlKYkhIMzVGUkphUFg1Ly90YTFBZjI5?= =?utf-8?B?ZEVxSGJocENPWlE1ajB1bldSelM3REt0NkRETXZMYTE0RnhEeFBhNFJWL3pW?= =?utf-8?B?NTFKWU0rdGorbVpOZ0JMRG0zQklYZllpSjNqN0UyZDc0dlprdmxxeVMvZ1hy?= =?utf-8?B?UVRQWUw2cEVFUGg4a2ZIWWNxeVViZWgxMGRJM0tlNGtQdDRUU0VwQndRKzJu?= =?utf-8?B?c09waU1xVERnVU5QVmRsalBSd1crVkFRcmFVekdWeUpONG9uVVlRdGxGOFJL?= =?utf-8?B?cE1DZXBYZ3ZxajBuaXpTZjlQeWhwT2xqSFUwUlhxTkw3RklTZTU4aER4cmxm?= =?utf-8?B?NUFld2xheFpUdHBwTjFEZWdpM0pIZGw2RW02YjJDc2xZTkZxWG55K0N4YlBU?= =?utf-8?B?emx5WmNsdXB2NmhzQTlUbE5heGp4U3N6NC9YZ25uM0xpclVlazFoWWM2ZUov?= =?utf-8?B?NlUrejhPL2tCTll0MFhyQWlsdkp0Wm8wdFF2ZU9BZHgvbnRGVmE5WmJKT05V?= =?utf-8?B?Vm5yeWwrVHI2RCtMVE1TbW05SkYyYm5DMzdkQzhJcW51a2ZRN0IwR29FNG1C?= =?utf-8?B?bTh6c0VqMmozMldZckNPK2VqcHFGRGNZdWVtektROVduMVBZa3FXYmJpODNB?= =?utf-8?B?MGpZOGo2SEUrN04zMXU4aWFhSzcyUkt0ZU0xclErd0hmbC9OTWJvOFVPVzBk?= =?utf-8?B?Y2hSRUtTa3JCdTljc0VjM3Nyc2dycG94UDJZOURSTzkwSndwSUR6by9rZUNZ?= =?utf-8?B?QklpazU0YnJaeXcyV3llR2lqTW80SnE1ZGJEbGIwYkh1N2dRNGlUMnBlT3A4?= =?utf-8?Q?E7iVs/wzq/aFOCl6k4iY/0Rkx1gFbXOLAXNmrTU?= X-MS-Exchange-CrossTenant-Network-Message-Id: bf77ae9d-3c08-43e6-d024-08d971dc22db X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB5000.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Sep 2021 08:47:34.2295 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: RrEIXmPyl8TEsghIvikwaqyvdtUVtHlTcNjr0oeaPusWNYgCZ3s8fvKrxCu95BsiLppKpoXO3aNyr/B+Vu8bdQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5030 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH] RFC: ethdev: add reassembly offload 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 Sender: "dev" On 8/23/2021 11:02 AM, Akhil Goyal wrote: > Reassembly is a costly operation if it is done in > software, however, if it is offloaded to HW, it can > considerably save application cycles. > The operation becomes even more costlier if IP fragmants > are encrypted. > > To resolve above two issues, a new offload > DEV_RX_OFFLOAD_REASSEMBLY is introduced in ethdev for > devices which can attempt reassembly of packets in hardware. > rte_eth_dev_info is added with the reassembly capabilities > which a device can support. > Now, if IP fragments are encrypted, reassembly can also be > attempted while doing inline IPsec processing. > This is controlled by a flag in rte_security_ipsec_sa_options > to enable reassembly of encrypted IP fragments in the inline > path. > > The resulting reassembled packet would be a typical > segmented mbuf in case of success. > > And if reassembly of fragments is failed or is incomplete (if > fragments do not come before the reass_timeout), the mbuf is > updated with an ol_flag PKT_RX_REASSEMBLY_INCOMPLETE and > mbuf is returned as is. Now application may decide the fate > of the packet to wait more for fragments to come or drop. > > Signed-off-by: Akhil Goyal > --- > lib/ethdev/rte_ethdev.c | 1 + > lib/ethdev/rte_ethdev.h | 18 +++++++++++++++++- > lib/mbuf/rte_mbuf_core.h | 3 ++- > lib/security/rte_security.h | 10 ++++++++++ > 4 files changed, 30 insertions(+), 2 deletions(-) > > diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c > index 9d95cd11e1..1ab3a093cf 100644 > --- a/lib/ethdev/rte_ethdev.c > +++ b/lib/ethdev/rte_ethdev.c > @@ -119,6 +119,7 @@ static const struct { > RTE_RX_OFFLOAD_BIT2STR(VLAN_FILTER), > RTE_RX_OFFLOAD_BIT2STR(VLAN_EXTEND), > RTE_RX_OFFLOAD_BIT2STR(JUMBO_FRAME), > + RTE_RX_OFFLOAD_BIT2STR(REASSEMBLY), > RTE_RX_OFFLOAD_BIT2STR(SCATTER), > RTE_RX_OFFLOAD_BIT2STR(TIMESTAMP), > RTE_RX_OFFLOAD_BIT2STR(SECURITY), > diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h > index d2b27c351f..e89a4dc1eb 100644 > --- a/lib/ethdev/rte_ethdev.h > +++ b/lib/ethdev/rte_ethdev.h > @@ -1360,6 +1360,7 @@ struct rte_eth_conf { > #define DEV_RX_OFFLOAD_VLAN_FILTER 0x00000200 > #define DEV_RX_OFFLOAD_VLAN_EXTEND 0x00000400 > #define DEV_RX_OFFLOAD_JUMBO_FRAME 0x00000800 > +#define DEV_RX_OFFLOAD_REASSEMBLY 0x00001000 previous '0x00001000' was 'DEV_RX_OFFLOAD_CRC_STRIP', it has been long that offload has been removed, but not sure if it cause any problem to re-use it. > #define DEV_RX_OFFLOAD_SCATTER 0x00002000 > /** > * Timestamp is set by the driver in RTE_MBUF_DYNFIELD_TIMESTAMP_NAME > @@ -1477,6 +1478,20 @@ struct rte_eth_dev_portconf { > */ > #define RTE_ETH_DEV_SWITCH_DOMAIN_ID_INVALID (UINT16_MAX) > > +/** > + * Reassembly capabilities that a device can support. > + * The device which can support reassembly offload should set > + * DEV_RX_OFFLOAD_REASSEMBLY > + */ > +struct rte_eth_reass_capa { > + /** Maximum time in ns that a fragment can wait for further fragments */ > + uint64_t reass_timeout; > + /** Maximum number of fragments that device can reassemble */ > + uint16_t max_frags; > + /** Reserved for future capabilities */ > + uint16_t reserved[3]; > +}; > + I wonder if there is any other hardware around supports reassembly offload, it would be good to get more feedback on the capabilities list. > /** > * Ethernet device associated switch information > */ > @@ -1582,8 +1597,9 @@ struct rte_eth_dev_info { > * embedded managed interconnect/switch. > */ > struct rte_eth_switch_info switch_info; > + /* Reassembly capabilities of a device for reassembly offload */ > + struct rte_eth_reass_capa reass_capa; > > - uint64_t reserved_64s[2]; /**< Reserved for future fields */ Reserved fields were added to be able to update the struct without breaking the ABI, so that a critical change doesn't have to wait until next ABI break release. Since this is ABI break release, we can keep the reserved field and add the new struct. Or this can be an opportunity to get rid of the reserved field. Personally I have no objection to get rid of the reserved field, but better to agree on this explicitly. > void *reserved_ptrs[2]; /**< Reserved for future fields */ > }; > > diff --git a/lib/mbuf/rte_mbuf_core.h b/lib/mbuf/rte_mbuf_core.h > index bb38d7f581..cea25c87f7 100644 > --- a/lib/mbuf/rte_mbuf_core.h > +++ b/lib/mbuf/rte_mbuf_core.h > @@ -200,10 +200,11 @@ extern "C" { > #define PKT_RX_OUTER_L4_CKSUM_BAD (1ULL << 21) > #define PKT_RX_OUTER_L4_CKSUM_GOOD (1ULL << 22) > #define PKT_RX_OUTER_L4_CKSUM_INVALID ((1ULL << 21) | (1ULL << 22)) > +#define PKT_RX_REASSEMBLY_INCOMPLETE (1ULL << 23) > Similar comment with Andrew's, what is the expectation from application if this flag exists? Can we drop it to simplify the logic in the application? > /* add new RX flags here, don't forget to update PKT_FIRST_FREE */ > > -#define PKT_FIRST_FREE (1ULL << 23) > +#define PKT_FIRST_FREE (1ULL << 24) > #define PKT_LAST_FREE (1ULL << 40) > > /* add new TX flags here, don't forget to update PKT_LAST_FREE */ > diff --git a/lib/security/rte_security.h b/lib/security/rte_security.h > index 88d31de0a6..364eeb5cd4 100644 > --- a/lib/security/rte_security.h > +++ b/lib/security/rte_security.h > @@ -181,6 +181,16 @@ struct rte_security_ipsec_sa_options { > * * 0: Disable per session security statistics collection for this SA. > */ > uint32_t stats : 1; > + > + /** Enable reassembly on incoming packets. > + * > + * * 1: Enable driver to try reassembly of encrypted IP packets for > + * this SA, if supported by the driver. This feature will work > + * only if rx_offload DEV_RX_OFFLOAD_REASSEMBLY is set in > + * inline ethernet device. > + * * 0: Disable reassembly of packets (default). > + */ > + uint32_t reass_en : 1; > }; > > /** IPSec security association direction */ >