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 B98D4A0512; Wed, 3 Jun 2020 12:44:41 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 022B71D155; Wed, 3 Jun 2020 12:44:41 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by dpdk.org (Postfix) with ESMTP id 6703E1D152; Wed, 3 Jun 2020 12:44:39 +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 053AdqH7005064; Wed, 3 Jun 2020 03:44:37 -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=rwAucD6iglXF+pemLau3RhanO1LM3X1xs6D0QGLJuz0=; b=kKX3Lv+5GhYeO8E47N7hAxfWwdyq3n4mq3l+V79rKi70KtbxkWu29KnNQec+XcmNzv1A 16YPvUVS3Y835vrqTSj6ag3pFPk2YDl5jzQ1TicTgjZzu9UmvIQJ8ltHCMyxIKUhqL3o YS65xSp6VeYcegDE9t49Mf9Z259GpDTqOJTfIEleCfa5QceEFjHSOZi5bwEzCQjO5myw Mucn/WdrQpplMVNGxz8D6baA8EnaItbmfkOZbJFk4l5bzPCDVRwXeSXH9fC2R5Th9592 8oWwlp97G78L5k4ZW3AmRAJjJ6F5wwtv135OvPOsRjl+aI/SLEOz0jSitEfa7b8gutmo vA== Received: from sc-exch01.marvell.com ([199.233.58.181]) by mx0a-0016f401.pphosted.com with ESMTP id 31bmupy6yk-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 03 Jun 2020 03:44:37 -0700 Received: from DC5-EXCH01.marvell.com (10.69.176.38) by SC-EXCH01.marvell.com (10.93.176.81) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 3 Jun 2020 03:44:35 -0700 Received: from SC-EXCH01.marvell.com (10.93.176.81) by DC5-EXCH01.marvell.com (10.69.176.38) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 3 Jun 2020 03:44:35 -0700 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (104.47.70.108) by SC-EXCH01.marvell.com (10.93.176.81) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 3 Jun 2020 03:44:35 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZZJPSRPK6z0CgGLAR0QsZOkyMDRnQ5KBQAFKD+Djy7S+wzU29jxOGfFonRX1ePWPvZBJ4FcVBxVDwuJvx2fEvqvqn8cfm9gdLjuqkL3JqFDgpl+RO1x6YM8U5GwvuoSHFAxsqhwLU/QSphztbyVMxbtrLw9Mm8XOvEjMDMXLqNNUkJCxoRwEUTxqAnpf7Q3NKLM5nYpBo0GUlIcClhmNdIL9IbnPNd/muRYpf/pJHnJsyPDVXsY+yQE/zi3FmFULO1FZTXfaWOdM6LCjWQq7w7yDHwEAAx/i9R9XyrawMmbQiSs7cE+URL/FfkxD9RdQ2HeLpCE/DP5joyrcl/O+pA== 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=rwAucD6iglXF+pemLau3RhanO1LM3X1xs6D0QGLJuz0=; b=B29AT/qF8ZRaNBV2S95cYBV0dwJy4L9vcygCFPGqQMxCFeHTzweX8eVXnhtQovtcWLf+OH+kGfupTB081r9G6xt5zBTIt685yExaqRsIeS0Z5qOT78pZKWSxZbrRsRtup4o0Xt7WyAp++qHLvAcsbI154UDORtjdhmNB6dhZnQ+OnlbhUq+Aag8AX4E29cH6Qh1TMcmrRyQUcaXzJAv79SpRWfqJzzHYMAhkPgAUsUR5rbpxp1Bs5oP1BWLSgII6Sivbuxipm/xCltrBeNAq7vvFDC8A3854VD+FBaFEqfnXW9SyyAsY/hPxaHyTSzTTYz1fy98brnRWoUlmOFeS+Q== 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=rwAucD6iglXF+pemLau3RhanO1LM3X1xs6D0QGLJuz0=; b=I24qL+h3L/nxwvPfdrLAd9oMc1VDk4RzUbRzuygHrsyjAbqY3puZ/YwinAnlLjZytNkDJb5wswOwSUf5XvpyKWXKM3zgjemNGBG3luW2XuslUFPGQns8zTuvbu2YCs9ZgrcoeHZESu9LUdQ8dEbKS6iisfNWMy3Fh+yU4sFpEuw= Authentication-Results: 6wind.com; dkim=none (message not signed) header.d=none;6wind.com; dmarc=none action=none header.from=marvell.com; Received: from BYAPR18MB2917.namprd18.prod.outlook.com (2603:10b6:a03:105::19) by BYAPR18MB3733.namprd18.prod.outlook.com (2603:10b6:a02:c1::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Wed, 3 Jun 2020 10:44:33 +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.3045.024; Wed, 3 Jun 2020 10:44:33 +0000 Date: Wed, 3 Jun 2020 16:14:14 +0530 From: Nithin Dabilpuram 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" Message-ID: <20200603104414.GA28936@outlook.office365.com> References: <20200505061920.GA1705@outlook.office365.com> <20200514202931.GF1739@platinum> <20200515100845.GA19989@outlook.office365.com> <20200515135746.GB9696@outlook.office365.com> <20200528154328.GA3029@outlook.office365.com> <20200602142537.GA6274@outlook.office365.com> <20200603082844.GG12564@platinum> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200603082844.GG12564@platinum> User-Agent: Mutt/1.12.2 (34cd43c) (2019-09-21) X-ClientProxiedBy: BM1PR0101CA0024.INDPRD01.PROD.OUTLOOK.COM (2603:1096:b00:18::34) 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 BM1PR0101CA0024.INDPRD01.PROD.OUTLOOK.COM (2603:1096:b00:18::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18 via Frontend Transport; Wed, 3 Jun 2020 10:44:28 +0000 X-Originating-IP: [115.113.156.2] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d14ee749-354c-4841-e26e-08d807ab1a1d X-MS-TrafficTypeDiagnostic: BYAPR18MB3733: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:2887; X-Forefront-PRVS: 04238CD941 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: N0pTLuSvwcPKzKsYIyWLHb9Fnji7QR3W9PpHNDT9/n91CE054GG2JzhOr5cIRuws74vm9rkArm/iAYcfaEt4IyBDZgqNLjEWpk404fothwLqAbVE3rVNrzOiGDsrFAF4j8I3rjD8TcK+7tdsPljqjBHobj3b06QhNJvYR2XEzDoTY4yQrSvDkryNsNDKeBQvl8uxKepsVnr+HQyd/J3re6Rgy0YS/dzTEW9KhzPK6l22MJ+WWQR5JwsTz69osMdq2eTFCQulodvxKHYZxV1lbMKHKUtVGghE6vvik4s/JN/AKf1PR0KfCNR9Ac74SgESaE2npfYVr+v/pHnRCWC5wYNI3KSqlS3ekBZRXMdeecL49c6hcbi3CWhIiKnewLh2OUsrH0mfDUfH6VZZiTaBFA== 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)(366004)(39860400002)(346002)(396003)(376002)(136003)(7696005)(1076003)(2906002)(7416002)(55236004)(6916009)(55016002)(86362001)(316002)(52116002)(478600001)(5660300002)(9686003)(8936002)(83380400001)(966005)(8676002)(6506007)(33656002)(26005)(66946007)(54906003)(66556008)(6666004)(66476007)(4326008)(16526019)(956004)(186003); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: pGsbu+RqhCBOXc+ziOz9ClK3pIS7SbZNYhCyffCsKhcQIcIljuEn8d0X890kRCIHGAxet8/+CG3jP+0LK360LB27yca4i74KAaOskPeI+80Grus1YOI9rxysxi13IaHk/LpzQ67XIgNBUpCpHi0jxs12tCKP8W4GwpMuWcw4shQE8ZZZowxWqjiwmHWC9rlh/P8WTEFlhIUw7kehp/312ZUAEQdfS3hOpHqCdGEENwcPCEC+pEgCnkj9pt9G7Qh5ne4ycPBcFNTjf0KY+j1QnRyVXadcUck3sArENqv1fIDyyfgQK9ZInNszf8srV7qmFRy8a1TndJDB/oEwTC2q3HdbpWIEsSTa7paI+m2G6wIniDaONVnMZYUYOIQFYRSFj/l/hotrUCKxAPfI2IeGI5lNp0ob3kl6IiQhgLi5zpgsXx+ljeJl/n5n8Y+DxElyOHrVQ7xxwV4/8VVzYUMWVveQxOrvwjFjFe+Ff3A96mE= X-MS-Exchange-CrossTenant-Network-Message-Id: d14ee749-354c-4841-e26e-08d807ab1a1d X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jun 2020 10:44:33.6780 (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: A4FzAs1LVH2xnjG9GNro7FPZCVSXrZ/czOWq1CdspvLTN5XDqsLP+O4T9KFqvdKOAeYAWSKSpBfQYQor/LiGLA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR18MB3733 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-03_11:2020-06-02, 2020-06-03 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 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. Apart from documentation issue, Is there any other issue or future ramification with using Rx field's for Tx ? 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. > > 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. - ICE PMD's dynamic field is however a vendor specific field and only for ICE PMD users. 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. > > Regards, > Olivier > > > > > > > > > > > > > > + Techboard > > > > > > > > There is a related thread going on > > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__mails.dpdk.org_archives_dev_2020-2DMay_168810.html&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=FZ_tPCbgFOh18zwRPO9H0yDx8VW38vuapifdDfc8SFQ&m=nyV4Rud03HW6DbWMpyvOCulQNkagmfo0wKtrwQ7zmmg&s=VuktoUb_xoLsHKdB9mV87x67cP9tXk3DqVXptt9nF_s&e= > > > > > > > > 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 > > > > >