netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 */

...

  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).