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 67F5EA00C3; Mon, 8 Jun 2020 11:40:14 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4088F1BE3D; Mon, 8 Jun 2020 11:40:13 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by dpdk.org (Postfix) with ESMTP id 765711BDAC; Mon, 8 Jun 2020 11:40:11 +0200 (CEST) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0589aghZ030389; Mon, 8 Jun 2020 02:40:09 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com; h=date : from : to : cc : subject : message-id : references : content-type : in-reply-to : mime-version; s=pfpt0818; bh=UgNz1GdbQMkpSiCz2rfzXgU57QMoj6C+w5hSbttNuVI=; b=VY3DG9EOZ2mLTm9aP8z34UnBPuSfRax6bWD63bivZRtdoX0qd9fK9ozHeWeGQ5m3jKgq EMcvI4X8NkQw4YnnCDk4TU6qhFlJqcV5nOxwYGQO+n66KZZ6T4MlPRlNpVn/cdk/QrLx vri44NL3Pv9P0qviQYKXsxapA4jIbO98G9/XS6buWwiFB+ikSMpEB4MtlwOtk7jNzjbH uHPpknd0ToBqJ55j9O2O0GIreS9PQBZ2OOG3m5lJb+hREQ73PwXhHCa4+8DVUMQLJXd6 BMTEU3V1M5IRSJtOqVvHt5dg9GuZ08IaP76CXtxytTtMi7jrbT1XAPq3Z96AMNxQXndb xw== Received: from sc-exch02.marvell.com ([199.233.58.182]) by mx0a-0016f401.pphosted.com with ESMTP id 31g8gnw263-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 08 Jun 2020 02:40:09 -0700 Received: from SC-EXCH03.marvell.com (10.93.176.83) by SC-EXCH02.marvell.com (10.93.176.82) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 8 Jun 2020 02:40:08 -0700 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (104.47.44.51) by SC-EXCH03.marvell.com (10.93.176.83) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 8 Jun 2020 02:40:08 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=K2HQ0HGgJMCM/dSxyurIboBFB5HH/Zm1wqc0gfS/YvEjBUrO6qzxFy6fDFE8zimkdLU2Jdg1+YFCSqrHGQ8uy9xM4vU1d/azBo05CgfFhpgmu9kv0MSgjy4UYrLUo6eRQSPwEf9bCq/X399ms4Z5+uJJ2ntr83g3ZTvRX2uc7TZ4crNr1hJ+CMkahXT522QjBZ9oYrEB1V7opOwl9E9zARqDLuN/AxY7X5eCjEDOdbTVzlihJwhggJg7874IDH44coDTYCUVIdjJ8z1NgMyX0cHEWYQnxo/4CUMJZ96Luz1DjhXmt3j7vhjlCsI3p5V4hy5uQ4oTedMe3yM4bwhBew== 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=UgNz1GdbQMkpSiCz2rfzXgU57QMoj6C+w5hSbttNuVI=; b=YlFr60TQ2zu+Qvwp13fuoGkiZI8ZPHD8gAq8K6VYs0CxIIPphj0I9SObG+gntcCmjOtYCVSA/v8AxiPZjuXq+A3cshUaMUiAUjmk5sAQbVGiUPWoZeL1oYlMQbRAGba+1yokpAbpSCLZ9Al9jjbQdq+ExF9fWa07+133wknFnLPCFfCI5FWf7VIyjx15jUMcyRb5xIJkA0gIMJM93wQYMhPZiCK4TrvHAzJ8PsNTatWbVF9wwsk9ksYqMAIIbZVFh1Heurc53XXfc1wJSP4y0BU15JxNZsStT+AsBoYs5eN/HupDOP5iPkErNL738DTNa2Fcm+c4khdEUhGIYDnEvA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=marvell.com; dmarc=pass action=none header.from=marvell.com; dkim=pass header.d=marvell.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.onmicrosoft.com; s=selector1-marvell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UgNz1GdbQMkpSiCz2rfzXgU57QMoj6C+w5hSbttNuVI=; b=SP/e8g4ohtCmHv0dTwRiUVdcBtWV+8WQXwe2gf408XGPenouUvWr7rUdHuNIIKdfKjTvz9dAQQAY+PAYNhKhvM3JMpGZ5UcakB4iCd+SylAyudm/kz911S2VvLtEmJWI/Pq5tE+p2X4jQ3e1okt2sJBXRJ7oY54Kka58a/J+liU= Authentication-Results: mellanox.com; dkim=none (message not signed) header.d=none;mellanox.com; dmarc=none action=none header.from=marvell.com; Received: from BYAPR18MB2917.namprd18.prod.outlook.com (2603:10b6:a03:105::19) by BYAPR18MB2966.namprd18.prod.outlook.com (2603:10b6:a03:10d::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Mon, 8 Jun 2020 09:40:07 +0000 Received: from BYAPR18MB2917.namprd18.prod.outlook.com ([fe80::a1ec:e959:77df:cd58]) by BYAPR18MB2917.namprd18.prod.outlook.com ([fe80::a1ec:e959:77df:cd58%5]) with mapi id 15.20.3066.023; Mon, 8 Jun 2020 09:40:07 +0000 Date: Mon, 8 Jun 2020 15:09:48 +0530 From: Nithin Dabilpuram To: Slava Ovsiienko CC: Olivier Matz , "Ananyev, Konstantin" , Jerin Jacob , "Dumitrescu, Cristian" , Nithin Dabilpuram , Thomas Monjalon , "Yigit, Ferruh" , Andrew Rybchenko , Ori Kam , "Burakov, Anatoly" , "Mcnamara, John" , "Kovacevic, Marko" , dpdk-dev , Jerin Jacob , Krzysztof Kanas , "techboard@dpdk.org" Message-ID: <20200608093948.GA11124@outlook.office365.com> References: <20200515135746.GB9696@outlook.office365.com> <20200528154328.GA3029@outlook.office365.com> <20200602142537.GA6274@outlook.office365.com> <20200603082844.GG12564@platinum> <20200603104414.GA28936@outlook.office365.com> <20200603113822.GI12564@platinum> <20200603125214.GA8237@outlook.office365.com> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.2 (34cd43c) (2019-09-21) X-ClientProxiedBy: PN1PR0101CA0060.INDPRD01.PROD.OUTLOOK.COM (2603:1096:c00:d::22) To BYAPR18MB2917.namprd18.prod.outlook.com (2603:10b6:a03:105::19) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from outlook.office365.com (115.113.156.2) by PN1PR0101CA0060.INDPRD01.PROD.OUTLOOK.COM (2603:1096:c00:d::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18 via Frontend Transport; Mon, 8 Jun 2020 09:40:01 +0000 X-Originating-IP: [115.113.156.2] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7192a9a8-d456-4836-20e5-08d80b8fed70 X-MS-TrafficTypeDiagnostic: BYAPR18MB2966: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:785; X-Forefront-PRVS: 042857DBB5 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 0BiNElP8NpxRq5PrpjhysoGpTNXdfNF8WTvM+hJJm+DNe+9LOb9T+MO2Lmj4Tdytz2PeZKDIHIUk42NFWS8FNhFPMtQoWgDlTIRa4S1iNTrKONxc7+wzjIcXISOoykobMMCPlbI5NYEWLuaHb+PkLD5dkMSTO29BDfi84Znw7eRVUmnSZnRPKp1A6WEX5dm2myQKD8DopuWFdu67ZRom2UiurVZ7S0PAQcJuNShqLolrQJ7GHcFH7knl6xCYgmZ4jJrg/fFo41GynbY5kjDHTQuzv9dxiBmHuS2Q2MuaJKBGXab4hWe4CQchoDkNzWcXs6Uxu6Lyyj7L8kuEWBnvYz36CvmMBbj6q0J2w8ilXUjDt12JSfut/Dzz79MaGKm2TTjjkyagqtg7xVW8tkjMrw== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR18MB2917.namprd18.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(366004)(39850400004)(376002)(346002)(136003)(26005)(45080400002)(6916009)(66946007)(86362001)(7416002)(6666004)(1076003)(5660300002)(16526019)(30864003)(4326008)(66556008)(2906002)(66476007)(316002)(186003)(478600001)(956004)(8676002)(8936002)(55236004)(9686003)(966005)(55016002)(6506007)(83380400001)(7696005)(52116002)(54906003)(53546011)(33656002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: hwfI6OX7vGInXnnpE3dPn16OEe1VN6wzzYJ0WUGqPrA9tt8W0hk6LWRO40effo5xuf70SDSrN28WMHUPvP6oi+mMYopNLMR39ZeAMFFbLCT3Vy3KUWPE1KkdZb6DzErK/31CDTwrZBSyJmyHB2pWvkTkiFWalZqLE+J7BjSlr2z4P5GpCoLbE5qSk3IImbyVSnlov8JqsJxm6/+Wyk+cr+xySACTzhRoO/h1IOVbhRBOOuPgJWn3lCMTtSW1LPr4s+SqibdO0t+rKYWcFq2PSLCnAnQUj76ELkSyXnjw+SUX7L0jxDXLvJDTFkaBDASnxBITyUvftObX/tFowm6BwJtAehCFJtpJ2p5CdeY4tJq5MKV/JW24U+qRqdMgXqgx4nuYZUin2mXqB/hR6SzeLHpUoNlMRhA6djURZiE5J8mrApR2MjQDP1yHYwu7EX17yqtuipNrT5XimwI602iIqBZc4x5e0869rZgYXhmunwU= X-MS-Exchange-CrossTenant-Network-Message-Id: 7192a9a8-d456-4836-20e5-08d80b8fed70 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jun 2020 09:40:07.0009 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 70e1fb47-1155-421d-87fc-2e58f638b6e0 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: weAJ6RgYN3c0tlXrw3Zd4csr4SU65pkztWUyx0DxQdg4Q7nilGEZAcOqgKSL9SWL7mivHtMGsCxcBhVgZfnjog== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR18MB2966 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-08_07:2020-06-08, 2020-06-08 signatures=0 Subject: Re: [dpdk-dev] [EXT] Re: [PATCH 1/3] mbuf: add Tx offloads for packet marking 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 Wed, Jun 03, 2020 at 04:14:13PM +0000, Slava Ovsiienko wrote: > > -----Original Message----- > > From: dev On Behalf Of Nithin Dabilpuram > > Sent: Wednesday, June 3, 2020 15:52 > > To: Olivier Matz > > Cc: Ananyev, Konstantin ; Jerin Jacob > > ; Dumitrescu, Cristian > > ; Nithin Dabilpuram > > ; Thomas Monjalon ; > > Yigit, Ferruh ; Andrew Rybchenko > > ; Ori Kam ; Burakov, > > Anatoly ; Mcnamara, John > > ; Kovacevic, Marko > > ; dpdk-dev ; Jerin Jacob > > ; Krzysztof Kanas ; > > techboard@dpdk.org > > Subject: Re: [dpdk-dev] [EXT] Re: [PATCH 1/3] mbuf: add Tx offloads for > > packet marking > > > > On Wed, Jun 03, 2020 at 01:38:22PM +0200, Olivier Matz wrote: > > > Hi Nithin, > > > > > > On Wed, Jun 03, 2020 at 04:14:14PM +0530, Nithin Dabilpuram wrote: > > > > On Wed, Jun 03, 2020 at 10:28:44AM +0200, Olivier Matz wrote: > > > > > Hi, > > > > > > > > > > On Tue, Jun 02, 2020 at 07:55:37PM +0530, Nithin Dabilpuram wrote: > > > > > > On Tue, Jun 02, 2020 at 10:53:08AM +0000, Ananyev, Konstantin > > wrote: > > > > > > > Hi Jerin, > > > > > > > > > > > > > > > > > > I also share Olivier's concern about consuming 3 bits in > > ol_flags for that feature. > > > > > > > > > > > Can it probably be squeezed somehow? > > > > > > > > > > > Let say we reserve one flag that this information is > > > > > > > > > > > present or not, and re-use one of rx-only fields for store > > additional information (packet_type, or so). > > > > > > > > > > > Or might be some other approach. > > > > > > > > > > > > > > > > > > > > We are fine with this approach where we define one bit > > > > > > > > > > in Tx offloads for pkt marking and and 3 bits reused from Rx > > offload flags area. > > > > > > > > > > > > > > > > > > > > For example: > > > > > > > > > > > > > > > > > > > > @@ -186,10 +186,16 @@ extern "C" { > > > > > > > > > > > > > > > > > > > > /* add new RX flags here, don't forget to update > > > > > > > > > > PKT_FIRST_FREE */ > > > > > > > > > > > > > > > > > > > > +/* Reused Rx offload bits for Tx offloads */ > > > > > > > > > > +#define PKT_X_TX_MARK_VLAN_DEI (1ULL << 0) > > > > > > > > > > +#define PKT_X_TX_MARK_IP_DSCP (1ULL << 1) > > > > > > > > > > +#define PKT_X_TX_MARK_IP_ECN (1ULL << 2) > > > > > > > > > > + > > > > > > > > > > #define PKT_FIRST_FREE (1ULL << 23) -#define > > > > > > > > > > PKT_LAST_FREE (1ULL << 40) > > > > > > > > > > +#define PKT_LAST_FREE (1ULL << 39) > > > > > > > > > > > > > > > > > > > > /* add new TX flags here, don't forget to update > > > > > > > > > > PKT_LAST_FREE */ > > > > > > > > > > +#define PKT_TX_MARK_EN (1ULL << 40) > > > > > > > > > > > > > > > > > > > > Is this fine ? > > > > > > > > > > > > > > > > > > Any thoughts on this approach which uses only 1 bit in Tx > > > > > > > > > flags out of 18 and reuse unused Rx flag bits ? > > > > > > > > > > > > > > My thought was not about re-defining the flags (I think it is > > > > > > > better to keep them intact), but adding a union for one of rx-only > > fields (packet_type/rss/timestamp). > > > > > > > > > > > > Ok. Adding a union field at packet_type field is also fine like below. > > > > > > > > > > > > @@ -187,9 +187,10 @@ extern "C" { > > > > > > /* add new RX flags here, don't forget to update PKT_FIRST_FREE > > > > > > */ > > > > > > > > > > > > #define PKT_FIRST_FREE (1ULL << 23) -#define PKT_LAST_FREE > > > > > > (1ULL << 40) > > > > > > +#define PKT_LAST_FREE (1ULL << 39) > > > > > > > > > > > > /* add new TX flags here, don't forget to update PKT_LAST_FREE > > > > > > */ > > > > > > +#define PKT_TX_MARK_EN (1ULL << 40) > > > > > > > > > > > > /** > > > > > > * Outer UDP checksum offload flag. This flag is used for > > > > > > enabling @@ -461,6 +462,14 @@ enum { #endif }; > > > > > > > > > > > > +/* Tx packet marking flags in rte_mbuf::tx_mark. > > > > > > + * Valid only when PKT_TX_MARK_EN is set in > > > > > > + * rte_mbuf::ol_flags. > > > > > > + */ > > > > > > +#define TX_MARK_VLAN_DEI (1ULL << 0) > > > > > > +#define TX_MARK_IP_DSCP (1ULL << 1) > > > > > > +#define TX_MARK_IP_ECN (1ULL << 2) > > > > > > + > > > > > > /** > > > > > > * The generic rte_mbuf, containing a packet mbuf. > > > > > > */ > > > > > > @@ -543,6 +552,10 @@ struct rte_mbuf { > > > > > > }; > > > > > > uint32_t inner_l4_type:4; /**< Inner L4 type. */ > > > > > > }; > > > > > > + struct { > > > > > > + uint32_t reserved:29; > > > > > > + uint32_t tx_mark:3; > > > > > > + }; > > > > > > }; > > > > > > > > > > > > > > > > > > > > > > > > Please correct me if this is not what you mean. > > > > > > > > > > I'm not a big fan of reusing Rx fields or flags for Tx. > > > > > It's not obvious for an application than adding a tx_mark will > > > > > overwrite the packet_type. I understand that the risk is limited > > > > > because packet_type is Rx and the marks are Tx, but there is still one. > > > > > > > > I'm also not a big fan but just wanted to take this approach so > > > > that, it can both conserve space and also help fast path. > > > > Reusing Rx area is however not a new thing as is already followed > > > > for > > > > mbuf->txadapter field. > > > > > > Yes, and in my opinion this is something we should avoid when > > > possible, because it makes some features exclusive (ex: the big union > > > with sched/rss/adapter/usr/...). > > > > > > > Apart from documentation issue, Is there any other issue or future > > > > ramification with using Rx field's for Tx ? > > > > > > No, I don't see any other issue except the ones we already mentioned (doc, > > code clarity, ). > > > > > > > If it is only about documentation, then we can add more documentation > > to make things clear. > > > > > > > > > > To summarize the different proposed approaches (please correct me if > > I'm wrong): > > > > > > > > > > a- add 3 Tx mbuf flags > > > > > (-) consumes limited resource > > > > > > > > > > b- add 3 dynamic flags > > > > > (-) slower > > > > > > > > - Tx burst Vector implementation can't be done for this tx offload as > > > > offset keeps changing. > > > > > > A vector implementation can be done. But yes, it would be slower than > > > with a static flag. > > > > Very slow atleast in our HW as, we try to translate ol_flags to HW descriptor > > flags in addition to extra operations to be done like offset calculations etc. > > The dynamic flag offset is not subject to be changed after registration. > So, flag offset can be converted once into appropriate mask and stored locally by PMD for further using in vector instructions. > The only difference - loaded variable mask instead of constant one, should not affect performance too much. > With the cmpeq/shifts the and results can be converted to any desired predefined mask (like static one). > > > > > So if we have fixed offsets, then it is easy to have static constant > > BTW, how this constant is loaded? > I suppose on x86 it would be rather mm_load?_si128(*constant array) - no difference > between dynamic and static masks at all. BTW, there is the hint - to make local copy of the > mask/offset in order to avoid cache-line concurrency in global variable storage. > > > 128/256 bit words with offsets and use things like shuffle/table lookup to > > reorganize multiple mbuf flags to descriptor fields in a single instruction. > > Offsets in the HW descriptor remain the fixed ones, so shuffle would still work OK. > Do you already have some vectorized implementation? It would be curious to have a look at. Agree that the constants need to be loaded from memory, but there is also a logic created onto transforming that data to descriptor which is not always straight forward. For example, see otx2_tx.c, // mbuf has tx offload field L2_LEN of 7 bits, L3_LEN of 9 bits which are not on byte boundary. // Below are the transformations done to get them to byte boundary. /* Get tx_offload for ol2, ol3, l2, l3 lengths from mbuf*/ /* * Operation result: * E(8):OL2_LEN(7):OL3_LEN(9):E(24):L3_LEN(9):L2_LEN(7) * E(8):OL2_LEN(7):OL3_LEN(9):E(24):L3_LEN(9):L2_LEN(7) */ asm volatile ("LD1 {%[a].D}[0],[%[in]]\n\t" : [a]"+w"(senddesc01_w1) : [in]"r"(mbuf0 + 2) : "memory"); /* * Operation Result: * E(47):L3_LEN(9):L2_LEN(7+z) * E(47):L3_LEN(9):L2_LEN(7+z) */ senddesc01_w1 = vshlq_n_u64(senddesc01_w1, 1); senddesc23_w1 = vshlq_n_u64(senddesc23_w1, 1); /* * Result: * E(48):L3_LEN(8):L2_LEN(z+7) * E(48):L3_LEN(8):L2_LEN(z+7) */ const int8x16_t tshft3 = { -1, 0, 8, 8, 8, 8, 8, 8, -1, 0, 8, 8, 8, 8, 8, 8, }; senddesc01_w1 = vshlq_u8(senddesc01_w1, tshft3); senddesc23_w1 = vshlq_u8(senddesc23_w1, tshft3); We cannot get all the above logic done runtime for every position of mbuf->l2_len if the field position keeps changing for every application run. > > I strongly share the concern about defining the static mbuf flags, > we should consider all ways to avoid doing this. > > WBR, Slava > > > > > > > > > > > > > > > c- add 1 Tx flag and union with Rx field > > > > > (-) exclusive with Rx field > > > > > (-) still consumes one flag > > > > > > > > > > My preference is still b-, for these reasons: > > > > > > > > > > - There are many different DPDK use cases, and resources in mbuf is > > tight. > > > > > Recent contributions (rte_flow and ice driver) already made use of > > dynamic > > > > > fields/flags. > > > > - Since RTE_FLOW metadata is 32-bit field, it is a clear candidate > > > > for dynamic flags. > > > > > > I'm not sure to get why it is a better candidate than packet marking. > > > You mean because it requires more room in mbuf? > > > > Yes, I feel space consumption is one way to decide whether it should be a > > dynfield or static field. > > > > IMO, other parameter to judge could be whether the field definition/usage > > itself is well know standard and is a part of RTE spec or its definition is > > vendor specific. > > > > > > > > > - ICE PMD's dynamic field is however a vendor specific field and > > > > only for ICE PMD users. > > > > > > Yes, but ICE PMD users may be as important as packet marking users. > > > > Agree, I only meant that the flag ICE PMD registered cannot be used for > > other PMD's so by using dynamic field, we are avoiding wastage of a static > > field that is needed only by one specific PMD irrespective of whether that > > PMD is probed or not. > > > > > > > > > In this case, it is just 1 bit out of 18 free bits available in ol_flags. > > > > > > > > > > > > > > - When I implemented the dynamic fields/flags feature, I did a test > > which > > > > > showed that the cost of having a dynamic offset was few cycles (on > > my test > > > > > platform, it was~3 cycles for reading a field and ~2 cycles for writing a > > > > > field). > > > > > > > > I think this cost is of the case where the address where the > > > > dyn_offset is stored is already in cache as it needs to be read first. > > > > > > This fetch of the value (in case it is not in cache) can be done once > > > per bulk, so I'm not sure the impact would be high. > > > > Agreed, for bulk case offset loading should have less impact. > > > > > > > > > > > Regards, > > > Olivier > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > Olivier > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > + Techboard > > > > > > > > > > > > > > > > There is a related thread going on > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__eur03.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=FZ_tPCbgFOh18zwRPO9H0yDx8VW38vuapifdDfc8SFQ&m=5IzeBXssneRLE7EeAyOUnytITHfcmhQu-eRLr18e5U0&s=aCn4On5jrJAfrGkQm_ftPodlBQo3QiozQM76MU9S8j8&e= > > > > > > > > %2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp- > > 3A__ma > > > > > > > > ils.dpdk.org_archives_dev_2020- > > 2DMay_168810.html%26d%3DDwIGa > > > > > > > > > > Q%26c%3DnKjWec2b6R0mOyPaz7xtfQ%26r%3DFZ_tPCbgFOh18zwRPO9H0y > > D > > > > > > > > > > x8VW38vuapifdDfc8SFQ%26m%3DnyV4Rud03HW6DbWMpyvOCulQNkagmf > > o0w > > > > > > > > > > KtrwQ7zmmg%26s%3DVuktoUb_xoLsHKdB9mV87x67cP9tXk3DqVXptt9nF_s > > > > > > > > > > %26e%3D&data=02%7C01%7Cviacheslavo%40mellanox.com%7C5e7a > > > > > > > > > > 9c93fd684e09267108d807bd0160%7Ca652971c7d2e4d9ba6a4d149256f4 > > > > > > > > > > 61b%7C0%7C0%7C637267855650797843&sdata=r%2B0JIDapZocl6DD > > > > > > > > A8wbNd4LV0CX6zEdDoQJhBpMoELw%3D&reserved=0 > > > > > > > > > > > > > > > > If there is no consensus on email, then I would like to add > > > > > > > > this item to the next TB meeting. > > > > > > > > > > > > > > Ok, I'll add that to tomorrow meeting agenda. > > > > > > > Konstantin > > > > > > > > > > > > > > > > >