From: Simon Horman <horms@kernel.org>
To: Jacob Keller <jacob.e.keller@intel.com>
Cc: netdev <netdev@vger.kernel.org>,
Anthony Nguyen <anthony.l.nguyen@intel.com>,
Intel Wired LAN <intel-wired-lan@lists.osuosl.org>,
Aleksandr Loktionov <aleksandr.loktionov@intel.com>,
Przemek Kitszel <przemyslaw.kitszel@intel.com>
Subject: Re: [PATCH iwl-next 2/2] net: intel: move RSS packet classifier types to libie
Date: Thu, 1 May 2025 14:51:01 +0100 [thread overview]
Message-ID: <20250501135101.GY3339421@horms.kernel.org> (raw)
In-Reply-To: <20250430-jk-hash-ena-refactor-v1-2-8310a4785472@intel.com>
On Wed, Apr 30, 2025 at 10:11:53AM -0700, Jacob Keller wrote:
> The Intel i40e, iavf, and ice drivers all include a definition of the
> packet classifier filter types used to program RSS hash enable bits. For
> i40e, these bits are used for both the PF and VF to configure the PFQF_HENA
> and VFQF_HENA registers.
>
> For ice and iAVF, these bits are used to communicate the desired hash
> enable filter over virtchnl via its struct virtchnl_rss_hashena. The
> virtchnl.h header makes no mention of where the bit definitions reside.
>
> Maintaining a separate copy of these bits across three drivers is
> cumbersome. Move the definition to libie as a new pctype.h header file.
> Each driver can include this, and drop its own definition.
>
> The ice implementation also defined a ICE_AVF_FLOW_FIELD_INVALID, intending
> to use this to indicate when there were no hash enable bits set. This is
> confusing, since the enumeration is using bit positions. A value of 0
> *should* indicate the first bit. Instead, rewrite the code that uses
> ICE_AVF_FLOW_FIELD_INVALID to just check if the avf_hash is zero. From
> context this should be clear that we're checking if none of the bits are
> set.
>
> The values are kept as bit positions instead of encoding the BIT_ULL
> directly into their value. While most users will simply use BIT_ULL
> immediately, i40e uses the macros both with BIT_ULL and test_bit/set_bit
> calls.
>
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Please see comment below.
...
> diff --git a/include/linux/net/intel/libie/pctype.h b/include/linux/net/intel/libie/pctype.h
> new file mode 100644
> index 0000000000000000000000000000000000000000..78723c8a33a084fb1120743427273af4b982c835
> --- /dev/null
> +++ b/include/linux/net/intel/libie/pctype.h
> @@ -0,0 +1,44 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/* Copyright (C) 2025 Intel Corporation */
> +
> +#ifndef __LIBIE_PCTYPE_H
> +#define __LIBIE_PCTYPE_H
> +
> +/**
> + * enum libie_filter_pctype - Packet Classifier Types for filters
> + *
> + * Packet Classifier Type indexes, used to set the xxQF_HENA registers. Also
> + * communicated over the virtchnl API as part of struct virtchnl_rss_hashena.
> + */
As there is a Kernel doc for this enum,
./tools/kernel-doc -none would like each value documented too.
> +enum libie_filter_pctype {
> + /* Note: Values 0-28 are reserved for future use.
> + * Value 29, 30, 32 are not supported on XL710 and X710.
> + */
> + LIBIE_FILTER_PCTYPE_NONF_UNICAST_IPV4_UDP = 29,
> + LIBIE_FILTER_PCTYPE_NONF_MULTICAST_IPV4_UDP = 30,
> + LIBIE_FILTER_PCTYPE_NONF_IPV4_UDP = 31,
> + LIBIE_FILTER_PCTYPE_NONF_IPV4_TCP_SYN_NO_ACK = 32,
> + LIBIE_FILTER_PCTYPE_NONF_IPV4_TCP = 33,
> + LIBIE_FILTER_PCTYPE_NONF_IPV4_SCTP = 34,
> + LIBIE_FILTER_PCTYPE_NONF_IPV4_OTHER = 35,
> + LIBIE_FILTER_PCTYPE_FRAG_IPV4 = 36,
> + /* Note: Values 37-38 are reserved for future use.
> + * Value 39, 40, 42 are not supported on XL710 and X710.
> + */
> + LIBIE_FILTER_PCTYPE_NONF_UNICAST_IPV6_UDP = 39,
> + LIBIE_FILTER_PCTYPE_NONF_MULTICAST_IPV6_UDP = 40,
> + LIBIE_FILTER_PCTYPE_NONF_IPV6_UDP = 41,
> + LIBIE_FILTER_PCTYPE_NONF_IPV6_TCP_SYN_NO_ACK = 42,
> + LIBIE_FILTER_PCTYPE_NONF_IPV6_TCP = 43,
> + LIBIE_FILTER_PCTYPE_NONF_IPV6_SCTP = 44,
> + LIBIE_FILTER_PCTYPE_NONF_IPV6_OTHER = 45,
> + LIBIE_FILTER_PCTYPE_FRAG_IPV6 = 46,
> + /* Note: Value 47 is reserved for future use */
> + LIBIE_FILTER_PCTYPE_FCOE_OX = 48,
> + LIBIE_FILTER_PCTYPE_FCOE_RX = 49,
> + LIBIE_FILTER_PCTYPE_FCOE_OTHER = 50,
> + /* Note: Values 51-62 are reserved for future use */
> + LIBIE_FILTER_PCTYPE_L2_PAYLOAD = 63
> +};
> +
> +#endif /* __LIBIE_PCTYPE_H */
...
next prev parent reply other threads:[~2025-05-01 13:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-30 17:11 [PATCH iwl-next 0/2] net: intel: cleanup RSS hash configuration bits Jacob Keller
2025-04-30 17:11 ` [PATCH iwl-next 1/2] net: intel: rename 'hena' to 'hashcfg' for clarity Jacob Keller
2025-05-01 13:51 ` Simon Horman
2025-04-30 17:11 ` [PATCH iwl-next 2/2] net: intel: move RSS packet classifier types to libie Jacob Keller
2025-05-01 13:51 ` Simon Horman [this message]
2025-05-01 16:52 ` [Intel-wired-lan] " Jacob Keller
2025-04-30 17:35 ` [PATCH iwl-next 0/2] net: intel: cleanup RSS hash configuration bits Loktionov, Aleksandr
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250501135101.GY3339421@horms.kernel.org \
--to=horms@kernel.org \
--cc=aleksandr.loktionov@intel.com \
--cc=anthony.l.nguyen@intel.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jacob.e.keller@intel.com \
--cc=netdev@vger.kernel.org \
--cc=przemyslaw.kitszel@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).