linux.git/include/linux/avf, branch v6.18.21

net: intel: move RSS packet classifier types to libie

2025-06-09T16:56:18+00:00

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.

Reviewed-by: Przemek Kitszel 
Reviewed-by: Simon Horman 
Reviewed-by: Aleksandr Loktionov 
Signed-off-by: Jacob Keller 
Tested-by: Rafal Romanowski 
Tested-by: Rinitha S  (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen

net: intel: rename 'hena' to 'hashcfg' for clarity

2025-06-09T16:56:18+00:00

i40e, ice, and iAVF all use 'hena' as a shorthand for the "hash enable"
configuration. This comes originally from the X710 datasheet 'xxQF_HENA'
registers. In the context of the registers the meaning is fairly clear.

However, on its own, hena is a weird name that can be more difficult to
understand. This is especially true in ice. The E810 hardware doesn't even
have registers with HENA in the name.

Replace the shorthand 'hena' with 'hashcfg'. This makes it clear the
variables deal with the Hash configuration, not just a single boolean
on/off for all hashing.

Do not update the register names. These come directly from the datasheet
for X710 and X722, and it is more important that the names can be searched.

Suggested-by: Przemek Kitszel 
Reviewed-by: Aleksandr Loktionov 
Reviewed-by: Przemek Kitszel 
Reviewed-by: Simon Horman 
Signed-off-by: Jacob Keller 
Tested-by: Rafal Romanowski 
Tested-by: Rinitha S  (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen

Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

2025-03-26T16:32:10+00:00

Merge in late fixes to prepare for the 6.15 net-next PR.

No conflicts, adjacent changes:

drivers/net/ethernet/broadcom/bnxt/bnxt.c
  919f9f497dbc ("eth: bnxt: fix out-of-range access of vnic_info array")
  fe96d717d38e ("bnxt_en: Extend queue stop/start for TX rings")

Signed-off-by: Jakub Kicinski

virtchnl: make proto and filter action count unsigned

2025-03-18T16:38:16+00:00

The count field in virtchnl_proto_hdrs and virtchnl_filter_action_set
should never be negative while still being valid. Changing it from
int to u32 ensures proper handling of values in virtchnl messages in
driverrs and prevents unintended behavior.
In its current signed form, a negative count does not trigger
an error in ice driver but instead results in it being treated as 0.
This can lead to unexpected outcomes when processing messages.
By using u32, any invalid values will correctly trigger -EINVAL,
making error detection more robust.

Fixes: 1f7ea1cd6a374 ("ice: Enable FDIR Configure for AVF")
Reviewed-by: Jedrzej Jagielski 
Reviewed-by: Simon Horman 
Signed-off-by: Jan Glaza 
Signed-off-by: Martyna Szapar-Mudlaw 
Tested-by: Rafal Romanowski 
Signed-off-by: Tony Nguyen

iavf: add support for negotiating flexible RXDID format

2025-02-14T18:58:07+00:00

Enable support for VIRTCHNL_VF_OFFLOAD_RX_FLEX_DESC, to enable the VF
driver the ability to determine what Rx descriptor formats are
available. This requires sending an additional message during
initialization and reset, the VIRTCHNL_OP_GET_SUPPORTED_RXDIDS. This
operation requests the supported Rx descriptor IDs available from the
PF.

This is treated the same way that VLAN V2 capabilities are handled. Add
a new set of extended capability flags, used to process send and receipt
of the VIRTCHNL_OP_GET_SUPPORTED_RXDIDS message.

This ensures we finish negotiating for the supported descriptor formats
prior to beginning configuration of receive queues.

This change stores the supported format bitmap into the iavf_adapter
structure. Additionally, if VIRTCHNL_VF_OFFLOAD_RX_FLEX_DESC is enabled
by the PF, we need to make sure that the Rx queue configuration
specifies the format.

Signed-off-by: Jacob Keller 
Reviewed-by: Simon Horman 
Tested-by: Rafal Romanowski 
Co-developed-by: Mateusz Polchlopek 
Signed-off-by: Mateusz Polchlopek 
Signed-off-by: Tony Nguyen

virtchnl: add enumeration for the rxdid format

2025-02-14T18:58:07+00:00

Support for allowing VF to negotiate the descriptor format requires that
the VF specify which descriptor format to use when requesting Rx queues.
The VF is supposed to request the set of supported formats via the new
VIRTCHNL_OP_GET_SUPPORTED_RXDIDS, and then set one of the supported
formats in the rxdid field of the virtchnl_rxq_info structure.

The virtchnl.h header does not provide an enumeration of the format
values. The existing implementations in the PF directly use the values
from the DDP package.

Make the formats explicit by defining an enumeration of the RXDIDs.
Provide an enumeration for the values as well as the bit positions as
returned by the supported_rxdids data from the
VIRTCHNL_OP_GET_SUPPORTED_RXDIDS.

Signed-off-by: Jacob Keller 
Reviewed-by: Rahul Rameshbabu 
Reviewed-by: Simon Horman 
Reviewed-by: Alexander Lobakin 
Tested-by: Rafal Romanowski 
Signed-off-by: Mateusz Polchlopek 
Signed-off-by: Tony Nguyen

ice: support Rx timestamp on flex descriptor

2025-02-14T18:57:45+00:00

To support Rx timestamp offload, VIRTCHNL_OP_1588_PTP_CAPS is sent by
the VF to request PTP capability and responded by the PF what capability
is enabled for that VF.

Hardware captures timestamps which contain only 32 bits of nominal
nanoseconds, as opposed to the 64bit timestamps that the stack expects.
To convert 32b to 64b, we need a current PHC time.
VIRTCHNL_OP_1588_PTP_GET_TIME is sent by the VF and responded by the
PF with the current PHC time.

Signed-off-by: Simei Su 
Reviewed-by: Simon Horman 
Tested-by: Rafal Romanowski 
Co-developed-by: Mateusz Polchlopek 
Signed-off-by: Mateusz Polchlopek 
Signed-off-by: Tony Nguyen

virtchnl: add support for enabling PTP on iAVF

2025-02-14T17:48:33+00:00

Add support for allowing a VF to enable PTP feature - Rx timestamps

The new capability is gated by VIRTCHNL_VF_CAP_PTP, which must be
set by the VF to request access to the new operations. In addition, the
VIRTCHNL_OP_1588_PTP_CAPS command is used to determine the specific
capabilities available to the VF.

This support includes the following additional capabilities:

* Rx timestamps enabled in the Rx queues (when using flexible advanced
  descriptors)
* Read access to PHC time over virtchnl using
  VIRTCHNL_OP_1588_PTP_GET_TIME

Extra space is reserved in most structures to allow for future
extension (like set clock, Tx timestamps).  Additional opcode numbers
are reserved and space in the virtchnl_ptp_caps structure is
specifically set aside for this.
Additionally, each structure has some space reserved for future
extensions to allow some flexibility.

Signed-off-by: Jacob Keller 
Reviewed-by: Rahul Rameshbabu 
Reviewed-by: Simon Horman 
Reviewed-by: Alexander Lobakin 
Tested-by: Rafal Romanowski 
Signed-off-by: Mateusz Polchlopek 
Signed-off-by: Tony Nguyen

virtchnl: fix m68k build.

2024-10-22T13:54:11+00:00

The kernel test robot reported a build failure on m68k in the intel
driver due to the recent shapers-related changes.

The mentioned arch has funny alignment properties, let's be explicit
about the binary layout expectation introducing a padding field.

Fixes: 608a5c05c39b ("virtchnl: support queue rate limit and quanta size configuration")
Reported-by: kernel test robot 
Closes: https://lore.kernel.org/oe-kbuild-all/202410131710.71Wt6LKO-lkp@intel.com/
Reviewed-by: Alexander Lobakin 
Reviewed-by: Paul Menzel 
Reviewed-by: Jacob Keller 
Link: https://patch.msgid.link/e45d1c9f17356d431b03b419f60b8b763d2ff768.1729000481.git.pabeni@redhat.com
Signed-off-by: Paolo Abeni

virtchnl: support queue rate limit and quanta size configuration

2024-10-10T15:30:23+00:00

This patch adds new virtchnl opcodes and structures for rate limit
and quanta size configuration, which include:
1. VIRTCHNL_OP_CONFIG_QUEUE_BW, to configure max bandwidth for each
VF per queue.
2. VIRTCHNL_OP_CONFIG_QUANTA, to configure quanta size per queue.
3. VIRTCHNL_OP_GET_QOS_CAPS, VF queries current QoS configuration, such
as enabled TCs, arbiter type, up2tc and bandwidth of VSI node. The
configuration is previously set by DCB and PF, and now is the potential
QoS capability of VF. VF can take it as reference to configure queue TC
mapping.

Reviewed-by: Jiri Pirko 
Signed-off-by: Wenjun Wu 
Signed-off-by: Paolo Abeni 
Link: https://patch.msgid.link/839002f7bd6f63b985a060a51b079f6e6dbbe237.1728460186.git.pabeni@redhat.com
Signed-off-by: Jakub Kicinski