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 A2B91A04EF; Wed, 3 Jun 2020 10:28:48 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8A3551BE3D; Wed, 3 Jun 2020 10:28:47 +0200 (CEST) Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by dpdk.org (Postfix) with ESMTP id 93CED4CBD for ; Wed, 3 Jun 2020 10:28:46 +0200 (CEST) Received: by mail-wr1-f68.google.com with SMTP id j10so1346654wrw.8 for ; Wed, 03 Jun 2020 01:28:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=lAG//Huw6gmlJVW7QXogcBF6mEXENWcrfYLSsaxyMEA=; b=aQVXTNUM1Q8xE4EnWazhfUXLgidxrZR/kiNDpH/BgDGpyT00zAdFgRwOnkfdCSNICF mA77UFVGORtmn6VY/wwrIcAf5VO+VtFKVtAJIalOE8yP93iNhxwl+6FzxqFJ5GMiTU/z oHfvMGSHD7le5kmOyVWOlIGV/UkT530oeNPRg4DcL1y6FBmsvkSycURJbWa4ZeKZ5nVd DecSvxiG8TJp9Hxd53J9g6VdHORSRdNldSFFUFypBcHdsD4hwepem5H9kBohKi30ms4s vNmeGLx5PY+z2f4dHvAYO48XAEzOEyCt+L0WDxK13ihXGBD7Nm5ufaHsjXD5qsQeh/UC rDQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=lAG//Huw6gmlJVW7QXogcBF6mEXENWcrfYLSsaxyMEA=; b=jf96MbdFXmYGcN/2Uskog2EbxTEaap/MlbjWNa/DwZk02CNOXZ9fpcwkSJVvBjOphi AsXJTyEtRkDAjYpWelys0+6c1S7Eo7TGY3m5WFKf95B94BF/kkJQbR2Cv+bbJLkMDnaW 9WzgQOW2ZDE6aYdglS2T8cd9+pP3Fra+XL6Psbm9QRGVcdLorROiotI955L58KXuOaGX qD+ASiPCgWUTsceMnF5xYr52xj3w2/X5S7/ADF16f3D9IbDtmnX01bKCVa00CYJY6G8k 0MR6pZ/IZWV5nYVSXKcKWAACkqOWY1+MUjVoRe5JNJ3w6xA7cw/KSXxKbgkq2RfGk4gG dSsg== X-Gm-Message-State: AOAM532kTLgL8cfQ/lwm0zAjSxOe89jql4o6IzHRyoCYrUKzlI1HvXsn fsy+4bKWhIOFuf2evLx0EbKAWw== X-Google-Smtp-Source: ABdhPJwjBux8TsgQmhP+UDmrAk2YkVrYl+cYUOaPW5aqOMKyWB3MIJuSChmt9/OOg5fmIlB7sGlJdQ== X-Received: by 2002:a5d:4484:: with SMTP id j4mr29294502wrq.325.1591172925838; Wed, 03 Jun 2020 01:28:45 -0700 (PDT) Received: from 6wind.com (2a01cb0c0005a600345636f7e65ed1a0.ipv6.abo.wanadoo.fr. [2a01:cb0c:5:a600:3456:36f7:e65e:d1a0]) by smtp.gmail.com with ESMTPSA id 128sm1940664wme.39.2020.06.03.01.28.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Jun 2020 01:28:44 -0700 (PDT) Date: Wed, 3 Jun 2020 10:28:44 +0200 From: Olivier Matz To: Nithin Dabilpuram 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: <20200603082844.GG12564@platinum> References: <20200504122735.GD6327@platinum> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200602142537.GA6274@outlook.office365.com> User-Agent: Mutt/1.10.1 (2018-07-13) 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" 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. 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 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. - 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). 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 > >