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 260C6A00C2; Mon, 23 May 2022 23:45:56 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C07474067B; Mon, 23 May 2022 23:45:55 +0200 (CEST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by mails.dpdk.org (Postfix) with ESMTP id 02DFF40156 for ; Mon, 23 May 2022 23:45:53 +0200 (CEST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id D680C32009E3; Mon, 23 May 2022 17:45:51 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Mon, 23 May 2022 17:45:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; t=1653342351; x= 1653428751; bh=BdhzbBjqe0C9yGHVnzf+nqMFne+fNaVwH+WudWLp4Vo=; b=u Bq7BjmyLecil0FUQ93db0lJqdBpRjhdjuwparoTBxaUwdW3QtXjjXrRgkRdTNuIq 70EGsJAk9XKZ5aMnFCxsUYk3YRfmOjbDasaLqm4bJVGsXQ0QEW3UBAuFnTZPet9+ vG4gZTvoZDfzfPdlmk8saYozRvKW9i3PxtL87m+3kFyv4n26UyQUSa9rpq/59Kgv g3YT6DFCj/a1BokBg9Hssupp935BXDJJx7kywm6cIcesgphYbvQXj/qOHnLN2Y4L UD9Yi/MEH8PspQDMNYTnoEC+gfKOIYK+3FBUTgT47nRfE6yyQJyQJpXEU1goa3cx bi0fSX50+CAb2eAvnrP5A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1653342351; x= 1653428751; bh=BdhzbBjqe0C9yGHVnzf+nqMFne+fNaVwH+WudWLp4Vo=; b=I FU7LOKxV8df55mgfrzlrbdTsHwJUMNQvwKn3GlxYmltkXwcNpTw5/22c6y1ApaDq 7mf93SpATkYLmSeGWzYulgUCWaHVn5Eoufgmv4wRJzrTGlFwbc7vJpAnfJ078BfD qlHCuNl9uJxdclSianpB6K23BbFqfwOEYeLlcHoM6xMVwSWno3kEsKBo/9ns/kJd jiPBgzha6JVqeua+fKCcphkT/lGcSBY/Zfn3N7/2LC7U9W++I5IREdbJEUSFiH9j HTxS7tKdF66KnRXTjGhxTcr8Ri6ZKXUZ0wIn+6OvD98TkUaP68HqsGJ4QtvPrUL1 JMB+Vt1aY/MejlvY8N2YQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrjedvgddtvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvfevufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnheptdejieeifeehtdffgfdvleetueeffeehueejgfeuteeftddtieek gfekudehtdfgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 23 May 2022 17:45:47 -0400 (EDT) From: Thomas Monjalon To: Stephen Hemminger , Spike Du Cc: dev@dpdk.org, Matan Azrad , Slava Ovsiienko , Ori Kam , Raslan Darawsheh , ferruh.yigit@amd.com, andrew.rybchenko@oktetlabs.ru Subject: Re: [RFC v2 3/7] ethdev: introduce Rx queue based limit watermark Date: Mon, 23 May 2022 23:45:38 +0200 Message-ID: <1836405.jbyF5MZJ3u@thomas> In-Reply-To: References: <20220506035645.4101714-1-spiked@nvidia.com> <20220522082321.3cdb7693@hermes.local> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 23/05/2022 05:01, Spike Du: > From: Stephen Hemminger > > Spike Du wrote: > > > --- a/lib/ethdev/rte_ethdev.h > > > +++ b/lib/ethdev/rte_ethdev.h > > > @@ -1249,7 +1249,16 @@ struct rte_eth_rxconf { > > > */ > > > union rte_eth_rxseg *rx_seg; > > > > > > - uint64_t reserved_64s[2]; /**< Reserved for future fields */ > > > + /** > > > + * Per-queue Rx limit watermark defined as percentage of Rx queue > > > + * size. If Rx queue receives traffic higher than this percentage, > > > + * the event RTE_ETH_EVENT_RX_LWM is triggered. > > > + */ > > > + uint8_t lwm; > > > + > > > + uint8_t reserved_bits[3]; > > > + uint32_t reserved_32s; > > > + uint64_t reserved_64s; > > > > Ok but, this is an ABI risk about this because reserved stuff was never > > required before. An ABI compatibility issue would be for an application compiled with an old DPDK, and loading a new DPDK at runtime. Let's think what would happen in such a case. > > Whenever is a reserved field is introduced the code (in this case > > rte_ethdev_configure). rte_eth_rx_queue_setup() is called with rx_conf->lwm not initialized. Then the library and drivers may interpret a wrong value. > > Best practice would have been to have the code require all reserved fields be > > 0 in earlier releases. In this case an application is like to define a watermark of > > zero; how will your code handle it. > > Having watermark of 0 is desired, which is the default. LWM of 0 means the Rx > Queue's watermark is not monitored, hence no LWM event is generated. The problem is to have a value not initialized. I think the best approach is to not expose the LWM value through this configuration structure. If the need is to get the current value, we should better add a field in the struct rte_eth_rxq_info. [...] > > > Why introduce new query/set operations? This should just be part of the > > overall device configuration. Thanks to the "set" function, we can avoid the ABI compat issue. > Due to different implementation. LWM can be a dynamic configuration which can help user design a flexible flow control. > User may feel ok with LWM of 80% to get high throughput, or later on with 50% to throttle the traffic responsively by handling LWM event in order to reduce drop. > Some driver like mlx5 may implement LWM event as one-time shot. When you receive LWM event, you need to reconfigure LWM in order to receive the event again, thus you will > not likely to be overwhelmed by the events. > These all require set operation. Yes it is better to allow dynamic watermark configuration, not using the function rte_eth_rx_queue_setup(). > For the query operation. The rte_event API rte_eth_dev_callback_process() is per-port API, it doesn't carry much information when an event happens. > When a LWM event happens, we need to know in which Rx queue it happens or optionally what's the current LWM percentage of this queue. > The query operation serves this purpose. Yes "query" has to be called in the event handler because event structure is not specific to any event type.