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 8D59C42368; Wed, 11 Oct 2023 19:39:42 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 17798400EF; Wed, 11 Oct 2023 19:39:42 +0200 (CEST) Received: from mail-pg1-f170.google.com (mail-pg1-f170.google.com [209.85.215.170]) by mails.dpdk.org (Postfix) with ESMTP id AB3DC400D7 for ; Wed, 11 Oct 2023 19:39:40 +0200 (CEST) Received: by mail-pg1-f170.google.com with SMTP id 41be03b00d2f7-58907163519so48191a12.1 for ; Wed, 11 Oct 2023 10:39:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1697045979; x=1697650779; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=NF01TMJ40w7B3iS5pOMdthFteokehBkPkSiQaKmW7jw=; b=rc4DpD9LkjumwbUkb+oO7oMdtIIBjws3ByX9H90fA87VkHRonJZPAdRkh3VrhdSjsp pj+sc0V7f8med7DTbIJ9C3Agq8/bXuiJXHh7ynK9N9mWEukXqRk8fi52J3HgyI1G8Gwp y1X02e0TBv6OgP2TM1mql5AlL8/jucWy0RQyAdNzEZLB8emLW6YYKl/K5XAuPcEpuZ7z AtMMpgfQ9BJ48WlcCBGcQYa8Gxkc96UIOFr+E0Zf47minOGphkk9Y/PuRNW4/T6gX0h4 cdDgQg8W9tB+6dxhRtTsnv1ZOp9vnGA9BJxFbnxxvUAafNANCU4YiIB0pm4AW2Apjb37 8G/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697045979; x=1697650779; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=NF01TMJ40w7B3iS5pOMdthFteokehBkPkSiQaKmW7jw=; b=Bt7v6+5ne1nOOD8ZGrfsSlKYQmbi9UazFWf2Ntj6EMLiHrmiXfZXuDfdpNfZaDTADs RHdOu8MF8SQ+0Dnawi7qQEkduuZ1mZOwZG/mylcQb4Tg6nyjxnFJC9Z+eq+Spbjo1hgn JZ53mwH8X4/HHEEZKBBfrxnil+GKf7PL1OHQ0SOkc7CDEeoKRBU6J3Nt94gRNOFp9Zxy bX1bFPwbnCNkcWOFHYjczaCQ8I20aAndwOxMKiX1S98ZTs6JX4P1w3hn4dvzFoSFYAy+ X/J76ieOsZhEm0qlro8ytSDSUmY8QQmvA//tTQ3Z6tICeeZERa+l3n8uh/Eh8Ea74fZy CKIg== X-Gm-Message-State: AOJu0Yw2PFdO1AIBsxRsf3xnx5jKJ2+a/JD0SJxeDn3D7t9kU2Hzz3aJ zHPN6DuXKjTRTKm7m8fAc50S6A== X-Google-Smtp-Source: AGHT+IESJXzRLOr8rVe4kPI4ASIQzkwZt2WWRjUEMrzclyHITz/Ad2iy1xT8zph2BCxcoGfzDw1DUA== X-Received: by 2002:a17:90b:1b4c:b0:274:9823:b481 with SMTP id nv12-20020a17090b1b4c00b002749823b481mr20892011pjb.9.1697045978706; Wed, 11 Oct 2023 10:39:38 -0700 (PDT) Received: from hermes.local (204-195-126-68.wavecable.com. [204.195.126.68]) by smtp.gmail.com with ESMTPSA id pq10-20020a17090b3d8a00b00277371fd346sm190196pjb.30.2023.10.11.10.39.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Oct 2023 10:39:38 -0700 (PDT) Date: Wed, 11 Oct 2023 10:39:36 -0700 From: Stephen Hemminger To: Jie Hai Cc: , Thomas Monjalon , Ferruh Yigit , Andrew Rybchenko , Ori Kam , , , Subject: Re: [PATCH v5 02/40] ethdev: support setting and querying RSS algorithm Message-ID: <20231011103936.5ffcdd73@hermes.local> In-Reply-To: <20231011092805.693171-3-haijie1@huawei.com> References: <20230908080030.3837515-1-haijie1@huawei.com> <20231011092805.693171-1-haijie1@huawei.com> <20231011092805.693171-3-haijie1@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 On Wed, 11 Oct 2023 17:27:27 +0800 Jie Hai wrote: > Currently, rte_eth_rss_conf supports configuring and querying > RSS hash functions, rss key and it's length, but not RSS hash > algorithm. > > The structure ``rte_eth_rss_conf`` is extended by adding a new > field "algorithm". This represents the RSS algorithms to apply. > The following API will be affected: > - rte_eth_dev_configure > - rte_eth_dev_rss_hash_update > - rte_eth_dev_rss_hash_conf_get > > If the value of "algorithm" used for configuration is a gibberish > value, report the error and return. Do the same for > rte_eth_dev_rss_hash_update and rte_eth_dev_configure. > > To check whether the drivers report valid "algorithm", it is set > to default value before querying. > > Signed-off-by: Jie Hai > Signed-off-by: Dongdong Liu > --- > doc/guides/rel_notes/release_23_11.rst | 2 ++ > lib/ethdev/rte_ethdev.c | 17 ++++++++++++++++ > lib/ethdev/rte_ethdev.h | 27 +++++++++++++++++++++++++ > lib/ethdev/rte_flow.c | 1 - > lib/ethdev/rte_flow.h | 28 ++------------------------ > 5 files changed, 48 insertions(+), 27 deletions(-) > > diff --git a/doc/guides/rel_notes/release_23_11.rst b/doc/guides/rel_notes/release_23_11.rst > index e13d57728071..92a445ab2ed3 100644 > --- a/doc/guides/rel_notes/release_23_11.rst > +++ b/doc/guides/rel_notes/release_23_11.rst > @@ -197,6 +197,8 @@ ABI Changes > fields, to move ``rxq`` and ``txq`` fields, to change the size of > ``reserved1`` and ``reserved2`` fields. > > +* ethdev: Added "algorithm" field to ``rte_eth_rss_conf`` structure for RSS > + hash algorithm. > > Known Issues > ------------ > diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c > index 18a4b950b184..2eda1b8072e5 100644 > --- a/lib/ethdev/rte_ethdev.c > +++ b/lib/ethdev/rte_ethdev.c > @@ -1464,6 +1464,14 @@ rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q, > goto rollback; > } > > + if (dev_conf->rx_adv_conf.rss_conf.algorithm >= RTE_ETH_HASH_FUNCTION_MAX) { > + RTE_ETHDEV_LOG(ERR, > + "Ethdev port_id=%u invalid RSS algorithm: 0x%"PRIx64"\n", > + port_id, dev_conf->rx_adv_conf.rss_conf.algorithm); > + ret = -EINVAL; > + goto rollback; > + } > + Rather than having every driver check the algorithm, why not handle this like other features in DPDK (which may mean API/ABI changes). Add a field rss_algo_capa which is bit field of available RSS functions. Then the check for algorithm can be done in generic code. There a couple of reserved fields that could be used. It would mean updating all the drivers once with the capa field but would provide way for application to know what fields are possible. It has proved to be a problem in later ABI changes if a maximum value is exposed. I.e don't expose RTE_ETH_HASH_FUNCTION_MAX.