Re: [Intel-wired-lan] [PATCH iwl-net v4] i40e: fix livelocks in i40e_reset_subtask()
On 26. 07. 23 22:43, Aleksandr Loktionov wrote:
Fix livelocks by acquiring rtnl_lock() before any reset related operations.
Add rtnl_lock()/rtnl_unlock() at top/bottom of i40e_reset_subtask()
Add check for __I40E_RESET_INTR_RECEIVED bit.
Add re-entry guard by fast return in case reset is already in progress.
Fixes: 373149fc99a0 ("i40e: Decrease the scope of rtnl lock")
Signed-off-by: Aleksandr Loktionov
---
v3->v4 fix | position in the code
v2->v3 fix typo in the commit message
v1->v2 * apply on
https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue.git
---
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 39 +++--
1 file changed, 20 insertions(+), 19 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c
b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 7c30abd..164f7c6 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -10011,42 +10011,44 @@ static void i40e_reset_subtask(struct i40e_pf *pf)
{
u32 reset_flags = 0;
- if (test_bit(__I40E_REINIT_REQUESTED, pf->state)) {
+ if (test_and_clear_bit(__I40E_REINIT_REQUESTED, pf->state))
reset_flags |= BIT(__I40E_REINIT_REQUESTED);
- clear_bit(__I40E_REINIT_REQUESTED, pf->state);
- }
- if (test_bit(__I40E_PF_RESET_REQUESTED, pf->state)) {
+ if (test_and_clear_bit(__I40E_PF_RESET_REQUESTED, pf->state))
reset_flags |= BIT(__I40E_PF_RESET_REQUESTED);
- clear_bit(__I40E_PF_RESET_REQUESTED, pf->state);
- }
- if (test_bit(__I40E_CORE_RESET_REQUESTED, pf->state)) {
+ if (test_and_clear_bit(__I40E_CORE_RESET_REQUESTED, pf->state))
reset_flags |= BIT(__I40E_CORE_RESET_REQUESTED);
- clear_bit(__I40E_CORE_RESET_REQUESTED, pf->state);
- }
- if (test_bit(__I40E_GLOBAL_RESET_REQUESTED, pf->state)) {
+ if (test_and_clear_bit(__I40E_GLOBAL_RESET_REQUESTED, pf->state))
reset_flags |= BIT(__I40E_GLOBAL_RESET_REQUESTED);
- clear_bit(__I40E_GLOBAL_RESET_REQUESTED, pf->state);
- }
- if (test_bit(__I40E_DOWN_REQUESTED, pf->state)) {
+ if (test_and_clear_bit(__I40E_DOWN_REQUESTED, pf->state))
reset_flags |= BIT(__I40E_DOWN_REQUESTED);
- clear_bit(__I40E_DOWN_REQUESTED, pf->state);
- }
+ if (test_and_clear_bit(__I40E_RESET_INTR_RECEIVED, pf->state))
+ reset_flags |= BIT(__I40E_RESET_INTR_RECEIVED);
+
+ if (!(reset_flags & (BIT(__I40E_PF_RESET_REQUESTED) |
+BIT(__I40E_CORE_RESET_REQUESTED) |
+BIT(__I40E_GLOBAL_RESET_REQUESTED) |
+BIT(__I40E_RESET_INTR_RECEIVED
+ return;
+
+ rtnl_lock();
/* If there's a recovery already waiting, it takes
* precedence before starting a new reset sequence.
*/
- if (test_bit(__I40E_RESET_INTR_RECEIVED, pf->state)) {
+ if (reset_flags & BIT(__I40E_RESET_INTR_RECEIVED)) {
i40e_prep_for_reset(pf);
i40e_reset(pf);
- i40e_rebuild(pf, false, false);
+ i40e_rebuild(pf, false, true);
}
/* If we're already down or resetting, just bail */
if (reset_flags &&
!test_bit(__I40E_DOWN, pf->state) &&
!test_bit(__I40E_CONFIG_BUSY, pf->state)) {
- i40e_do_reset(pf, reset_flags, false);
+ i40e_do_reset(pf, reset_flags, true);
}
+
+ rtnl_unlock();
}
/**
@@ -10694,7 +10696,6 @@ static void i40e_prep_for_reset(struct i40e_pf *pf)
int ret = 0;
u32 v;
- clear_bit(__I40E_RESET_INTR_RECEIVED, pf->state);
if (test_and_set_bit(__I40E_RESET_RECOVERY_PENDING, pf->state))
return;
if (i40e_check_asq_alive(&pf->hw))
Tony, why this is marked in IWL patchwork as ChangesRequested? There
were no comments and the patch disappeared from dev-queue. Are you
planning to process it?
Thanks,
Ivan
Re: [Intel-wired-lan] [PATCH iwl-net v3] i40e: fix 32bit FW gtime wrapping issue
On 17. 08. 23 21:28, Aleksandr Loktionov wrote:
Before the i40e_nvm code didn't take into account that 32bit FW gtime
wraps ~70minutes, timeout was calculated as 64bit gtime + NVM_TIMEOUT
, so when gtime was ~70minutes, then gtime could not become greater
than 64bit timeout value and the semaphore to be considered as expired.
Decrease hw_semaphore_timeout size down to 32bits, because FW
I40E_GLVFGEN_TIMER register is 32bits only anyway, but having
both variables same u32 size simplifies code.
Fix FW write semaphore expiration condition, taking into account
that I40E_GLVFGEN_TIMER wraps, by checking the sign of subtraction
of two 32 bit values.
Fixes: 56a62fc86895 ("i40e: init code and hardware support")
Signed-off-by: Aleksandr Loktionov
---
v2->v3 fix commit message
v1->v2 in commit message: add 'Fixes' tag, fix a typo
---
---
drivers/net/ethernet/intel/i40e/i40e_nvm.c | 8
drivers/net/ethernet/intel/i40e/i40e_type.h | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
The same here, v3 was without any comment but marked as
ChangesRequested. The patch is nowhere now... upstream, your dev-queue...
Thanks,
Ivan
Re: [Intel-wired-lan] [PATCH] ice: Add get/set hw address for VF representor ports
Wed, Jan 31, 2024 at 09:08:47AM CET, ksund...@redhat.com wrote: >Changing the mac address of the VF representor ports are not >available via devlink. Add the function handlers to set and get >the HW address for the VF representor ports. Wait a sec. The API is there to change the mac of the actual VF. Not the representor. Apparently your patch is not doing that, changing mac of the representor. NAK. Fix this to change the VF mac address or drop the patch entirely. Thanks! pw-bot: cr
[Intel-wired-lan] [tnguy-next-queue:dev-queue] BUILD SUCCESS dd5cddbfd781d93df1e301ba4a3a57411e2ba326
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue.git dev-queue branch HEAD: dd5cddbfd781d93df1e301ba4a3a57411e2ba326 igc: Unify filtering rule fields elapsed time: 869m configs tested: 180 configs skipped: 3 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: alpha allnoconfig gcc alphaallyesconfig gcc alpha defconfig gcc arc allmodconfig gcc arc allnoconfig gcc arc allyesconfig gcc arc axs101_defconfig gcc arc defconfig gcc arc randconfig-001-20240131 gcc arc randconfig-002-20240131 gcc arm allmodconfig gcc arm allnoconfig gcc arm allyesconfig gcc arm defconfig clang arm randconfig-001-20240131 clang arm randconfig-002-20240131 clang arm randconfig-003-20240131 clang arm randconfig-004-20240131 clang arm sp7021_defconfig clang arm sunxi_defconfig gcc arm64allmodconfig clang arm64 allnoconfig gcc arm64 defconfig gcc arm64 randconfig-001-20240131 clang arm64 randconfig-002-20240131 clang arm64 randconfig-003-20240131 clang arm64 randconfig-004-20240131 clang csky allmodconfig gcc csky allnoconfig gcc csky allyesconfig gcc cskydefconfig gcc csky randconfig-001-20240131 gcc csky randconfig-002-20240131 gcc hexagon allmodconfig clang hexagon allnoconfig clang hexagon allyesconfig clang hexagon defconfig clang hexagon randconfig-001-20240131 clang hexagon randconfig-002-20240131 clang i386 allmodconfig clang i386 allnoconfig clang i386 allyesconfig clang i386 buildonly-randconfig-001-20240131 clang i386 buildonly-randconfig-002-20240131 clang i386 buildonly-randconfig-003-20240131 clang i386 buildonly-randconfig-004-20240131 clang i386 buildonly-randconfig-005-20240131 clang i386 buildonly-randconfig-006-20240131 clang i386defconfig gcc i386 randconfig-001-20240131 clang i386 randconfig-002-20240131 clang i386 randconfig-003-20240131 clang i386 randconfig-004-20240131 clang i386 randconfig-005-20240131 clang i386 randconfig-006-20240131 clang i386 randconfig-011-20240131 gcc i386 randconfig-012-20240131 gcc i386 randconfig-013-20240131 gcc i386 randconfig-014-20240131 gcc i386 randconfig-015-20240131 gcc i386 randconfig-016-20240131 gcc loongarchallmodconfig gcc loongarch allnoconfig gcc loongarch defconfig gcc loongarch loongson3_defconfig gcc loongarch randconfig-001-20240131 gcc loongarch randconfig-002-20240131 gcc m68k allmodconfig gcc m68k allnoconfig gcc m68k allyesconfig gcc m68kdefconfig gcc m68kmvme16x_defconfig gcc microblaze allmodconfig gcc microblazeallnoconfig gcc microblaze allyesconfig gcc microblaze defconfig gcc microblaze mmu_defconfig gcc mips allnoconfig clang mips allyesconfig gcc mips bmips_be_defconfig gcc mips bmips_stb_defconfig clang nios2allmodconfig gcc nios2 allnoconfig gcc nios2allyesconfig gcc nios2 defconfig gcc nios2 randconfig-001
Re: [Intel-wired-lan] [PATCH] ice: Add get/set hw address for VF representor ports
On Wed, Jan 31, 2024 at 01:38:47PM +0530, karthiksundaravel wrote: > Changing the mac address of the VF representor ports are not > available via devlink. Add the function handlers to set and get > the HW address for the VF representor ports. > > Signed-off-by: karthiksundaravel > --- > drivers/net/ethernet/intel/ice/ice_devlink.c | 134 ++- > 1 file changed, 132 insertions(+), 2 deletions(-) > > diff --git a/drivers/net/ethernet/intel/ice/ice_devlink.c > b/drivers/net/ethernet/intel/ice/ice_devlink.c > index 80dc5445b50d..56d81836c469 100644 > --- a/drivers/net/ethernet/intel/ice/ice_devlink.c > +++ b/drivers/net/ethernet/intel/ice/ice_devlink.c > @@ -9,6 +9,8 @@ As Jiri already wrote, you are not changing MAC of VF in your code. Try to look at ice_set_vf_mac in ice_sriov.c. In current implementation you nedd to set new MAC value for VF and reset it. You shouldn't use PF VSI. Pointer to VF you can get from representor struct (through parent VSI). You shouldn't manage the rules during MAC changing, as in switchdev slow-path there shouldn't be VF MAC rules. It can be problematic as user already can have MAC + sth rule (which also needs to be change). I will leave it to user (most probably the MAC change happens before adding any rules). In few days we will send patchset for subfunction support where the subfunction MAC chaning is implementing from devlink API. I will add you to the CC. Thanks for working on it, it is a gap in our solution. Thanks, Michal
[Intel-wired-lan] [PATCH iwl-next v5 2/3] ixgbe: Rearrange args to fix reverse Christmas tree
Clean up the code touched during type conversion by the previous patch
of the series.
Suggested-by: Tony Nguyen
Reviewed-by: Przemek Kitszel
Reviewed-by: Simon Horman
Signed-off-by: Jedrzej Jagielski
---
.../net/ethernet/intel/ixgbe/ixgbe_82598.c| 14 ++--
.../net/ethernet/intel/ixgbe/ixgbe_82599.c| 41 ++--
.../net/ethernet/intel/ixgbe/ixgbe_common.c | 66 +--
.../net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 2 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c | 54 +++
drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c | 12 ++--
drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c | 50 +++---
7 files changed, 120 insertions(+), 119 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c
index 51baa176b99f..283a23150a4d 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c
@@ -97,8 +97,8 @@ static int ixgbe_init_phy_ops_82598(struct ixgbe_hw *hw)
{
struct ixgbe_mac_info *mac = &hw->mac;
struct ixgbe_phy_info *phy = &hw->phy;
- int ret_val;
u16 list_offset, data_offset;
+ int ret_val;
/* Identify the PHY */
phy->ops.identify(hw);
@@ -414,10 +414,10 @@ static int ixgbe_fc_enable_82598(struct ixgbe_hw *hw)
static int ixgbe_start_mac_link_82598(struct ixgbe_hw *hw,
bool autoneg_wait_to_complete)
{
+ int status = 0;
u32 autoc_reg;
u32 links_reg;
u32 i;
- int status = 0;
/* Restart link */
autoc_reg = IXGBE_READ_REG(hw, IXGBE_AUTOC);
@@ -649,13 +649,13 @@ static int ixgbe_setup_copper_link_82598(struct ixgbe_hw
*hw,
**/
static int ixgbe_reset_hw_82598(struct ixgbe_hw *hw)
{
- int status;
int phy_status = 0;
- u32 ctrl;
+ u8 analog_val;
u32 gheccr;
- u32 i;
+ int status;
u32 autoc;
- u8 analog_val;
+ u32 ctrl;
+ u32 i;
/* Call adapter stop to disable tx/rx and clear interrupts */
status = hw->mac.ops.stop_adapter(hw);
@@ -951,10 +951,10 @@ static int ixgbe_write_analog_reg8_82598(struct ixgbe_hw
*hw, u32 reg, u8 val)
static int ixgbe_read_i2c_phy_82598(struct ixgbe_hw *hw, u8 dev_addr,
u8 byte_offset, u8 *eeprom_data)
{
- int status = 0;
u16 sfp_addr = 0;
u16 sfp_data = 0;
u16 sfp_stat = 0;
+ int status = 0;
u16 gssr;
u32 i;
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c
index 2ae659b123e4..e0c300fe5cee 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c
@@ -100,8 +100,8 @@ static void ixgbe_init_mac_link_ops_82599(struct ixgbe_hw
*hw)
static int ixgbe_setup_sfp_modules_82599(struct ixgbe_hw *hw)
{
- int ret_val;
u16 list_offset, data_offset, data_value;
+ int ret_val;
if (hw->phy.sfp_type != ixgbe_sfp_type_unknown) {
ixgbe_init_mac_link_ops_82599(hw);
@@ -503,11 +503,11 @@ static void ixgbe_stop_mac_link_on_d3_82599(struct
ixgbe_hw *hw)
static int ixgbe_start_mac_link_82599(struct ixgbe_hw *hw,
bool autoneg_wait_to_complete)
{
+ bool got_lock = false;
+ int status = 0;
u32 autoc_reg;
u32 links_reg;
u32 i;
- int status = 0;
- bool got_lock = false;
if (ixgbe_verify_lesm_fw_enabled_82599(hw)) {
status = hw->mac.ops.acquire_swfw_sync(hw,
@@ -661,11 +661,11 @@ static int ixgbe_setup_mac_link_smartspeed(struct
ixgbe_hw *hw,
ixgbe_link_speed speed,
bool autoneg_wait_to_complete)
{
- int status = 0;
ixgbe_link_speed link_speed = IXGBE_LINK_SPEED_UNKNOWN;
- s32 i, j;
- bool link_up = false;
u32 autoc_reg = IXGBE_READ_REG(hw, IXGBE_AUTOC);
+ bool link_up = false;
+ int status = 0;
+ s32 i, j;
/* Set autoneg_advertised value based on input link speed */
hw->phy.autoneg_advertised = 0;
@@ -771,12 +771,11 @@ static int ixgbe_setup_mac_link_82599(struct ixgbe_hw *hw,
ixgbe_link_speed speed,
bool autoneg_wait_to_complete)
{
+ ixgbe_link_speed link_capabilities = IXGBE_LINK_SPEED_UNKNOWN;
+ u32 pma_pmd_10g_serial, pma_pmd_1g, link_mode, links_reg, i;
+ u32 autoc2 = IXGBE_READ_REG(hw, IXGBE_AUTOC2);
bool autoneg = false;
int status;
- u32 pma_pmd_1g, link_mode, links_reg, i;
- u32 autoc2 = IXGBE_READ_REG(hw, IXGBE_AUTOC2);
- u32 pma_pmd_10g_serial = autoc2 & IXGBE_AUTOC2_10G_SERIAL_PMA_PMD_MASK;
- ixgbe_link_speed link_capabilities = IXGBE_LINK_SPEE
[Intel-wired-lan] [PATCH iwl-next v5 3/3] ixgbe: Clarify the values of the returning status
Converting s32 functions to regular int in the previous patch of the series
caused triggering smatch warnings about missing error code.
New smatch warnings:
drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c:2884 ixgbe_get_lcd_t_x550em()
warn: missing error code? 'status'
drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c:3130 ixgbe_enter_lplu_t_x550em()
warn: missing error code? 'status'
Old smatch warnings:
drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c:2890 ixgbe_get_lcd_t_x550em()
warn: missing error code? 'status'
Fix it by clearly stating returning error code as 0.
Reported-by: kernel test robot
Reported-by: Dan Carpenter
Closes: https://lore.kernel.org/r/202401041701.6qktszmx-...@intel.com/
Reviewed-by: Simon Horman
Signed-off-by: Jedrzej Jagielski
---
drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
index efce4b231493..bee1d2f554d3 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
@@ -2883,17 +2883,17 @@ static int ixgbe_get_lcd_t_x550em(struct ixgbe_hw *hw,
/* If link partner advertised 1G, return 1G */
if (an_lp_status & IXGBE_AUTO_NEG_LP_1000BASE_CAP) {
*lcd_speed = IXGBE_LINK_SPEED_1GB_FULL;
- return status;
+ return 0;
}
/* If 10G disabled for LPLU via NVM D10GMP, then return no valid LCD */
if ((hw->bus.lan_id && (word & NVM_INIT_CTRL_3_D10GMP_PORT1)) ||
(word & NVM_INIT_CTRL_3_D10GMP_PORT0))
- return status;
+ return 0;
/* Link partner not capable of lower speeds, return 10G */
*lcd_speed = IXGBE_LINK_SPEED_10GB_FULL;
- return status;
+ return 0;
}
/**
@@ -3129,7 +3129,7 @@ static int ixgbe_enter_lplu_t_x550em(struct ixgbe_hw *hw)
(lcd_speed == IXGBE_LINK_SPEED_1GB_FULL)) ||
((speed == IXGBE_MDIO_AUTO_NEG_VENDOR_STATUS_10GB) &&
(lcd_speed == IXGBE_LINK_SPEED_10GB_FULL)))
- return status;
+ return 0;
/* Clear AN completed indication */
status = hw->phy.ops.read_reg(hw, IXGBE_MDIO_AUTO_NEG_VENDOR_TX_ALARM,
--
2.31.1
Re: [Intel-wired-lan] [PATCH net-next v5] ethtool: ice: Support for RSS settings to GTP from ethtool
On 31.01.2024 02:37, Takeru Hayasaka wrote: > This is a patch that enables RSS functionality for GTP packets using ethtool. > > A user can include TEID and make RSS work for GTP-U over IPv4 by doing the > following:`ethtool -N ens3 rx-flow-hash gtpu4 sde` > > In addition to gtpu(4|6), we now support gtpc(4|6),gtpc(4|6)t,gtpu(4|6)e, > gtpu(4|6)u, and gtpu(4|6)d. > > gtpc(4|6): Used for GTP-C in IPv4 and IPv6, where the GTP header format does > not include a TEID. > gtpc(4|6)t: Used for GTP-C in IPv4 and IPv6, with a GTP header format that > includes a TEID. > gtpu(4|6): Used for GTP-U in both IPv4 and IPv6 scenarios. > gtpu(4|6)e: Used for GTP-U with extended headers in both IPv4 and IPv6. > gtpu(4|6)u: Used when the PSC (PDU session container) in the GTP-U extended > header includes Uplink, applicable to both IPv4 and IPv6. > gtpu(4|6)d: Used when the PSC in the GTP-U extended header includes Downlink, > for both IPv4 and IPv6. > > GTP generates a flow that includes an ID called TEID to identify the tunnel. > This tunnel is created for each UE (User Equipment).By performing RSS based on > this flow, it is possible to apply RSS for each communication unit from the > UE. > Without this, RSS would only be effective within the range of IP addresses. > For > instance, the PGW can only perform RSS within the IP range of the SGW. > Problematic from a load distribution perspective, especially if there's a bias > in the terminals connected to a particular base station.This case can be > solved by using this patch. LGTM Reviewed-by: Marcin Szycik > Signed-off-by: Takeru Hayasaka > --- > v2->v3: Based on Harald-san's review, I added documentation and comments to > ethtool.h and ice.rst. > v3->v4: Based on Marcin-san's review, I added the missing code for GTPC and > GTPC_TEID, and revised the documentation and comments. > v4->v5: Based on Marcin-san's review, I fixed rename and wrong code regarding > GTPC [...] > f Hash on bytes 0 and 1 of the Layer 4 header of the Rx packet. > n Hash on bytes 2 and 3 of the Layer 4 header of the Rx packet. > - Still removing this line :c > +e Hash on GTP Packet on TEID (4bytes) of the Rx packet. > > Accelerated Receive Flow Steering (aRFS) > ---8<---
[Intel-wired-lan] [PATCH net] ice: fix unaligned access in ice_create_lag_recipe
new_rcp->recipe_bitmap was written to as if it were an aligned bitmap.
It is an 8-byte array, but aligned only to 4.
Use put_unaligned to set its value.
Additionally, values in ice commands are typically in little-endian.
I assume the recipe bitmap should be too, so use the *_le64 conversion.
I don't have a big-endian system with ice to test this.
I tested that the driver does not crash when probing on aarch64 anymore,
which is good enough for me. I don't know if the LAG feature actually
works.
This is what the crash looked like without the fix:
[ 17.599009] Unable to handle kernel paging request at virtual address
07ff9c6dc004
[ 17.599011] Mem abort info:
[ 17.599011] ESR = 0x9621
[ 17.599012] EC = 0x25: DABT (current EL), IL = 32 bits
[ 17.599013] SET = 0, FnV = 0
[ 17.599014] EA = 0, S1PTW = 0
[ 17.599014] FSC = 0x21: alignment fault
[ 17.599015] Data abort info:
[ 17.599016] ISV = 0, ISS = 0x0021, ISS2 = 0x
[ 17.599016] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 17.599017] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 17.599019] swapper pgtable: 4k pages, 48-bit VAs, pgdp=080dd6bd
[ 17.599020] [07ff9c6dc004] pgd=1800083fffacf003, p4d=1800083fffacf003,
pud=1800083ffface003, pmd=1800083fff9ea003, pte=006808001c6dcf07
[ 17.599025] Internal error: Oops: 9621 [#1] SMP
[ 17.599027] Modules linked in: crct10dif_ce ghash_ce sha2_ce sha256_arm64
mlx5_core sha1_ce sbsa_gwdt ice(+) nvme nvme_core mlxfw igb tls nvme_common
psample i2c_algo_bit gnss pci_hyperv_intf i2c_designware_platform
i2c_designware_core xgene_hwmon dm_mirror dm_region_hash dm_log dm_mod
[ 17.599043] CPU: 0 PID: 18 Comm: kworker/0:1 Not tainted
5.14.0-407.el9.aarch64 #1
[ 17.599044] Hardware name: GIGABYTE R272-P31-00/MP32-AR1-00, BIOS F31L (SCP:
2.10.20220531) 09/29/2022
[ 17.599046] Workqueue: events work_for_cpu_fn
[ 17.599051] pstate: 6049 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 17.599053] pc : ice_create_lag_recipe.constprop.0+0xbc/0x11c [ice]
[ 17.599091] lr : ice_create_lag_recipe.constprop.0+0x54/0x11c [ice]
[ 17.599121] sp : 884a3c50
[ 17.599122] x29: 884a3c50 x28: abc4a6790f00 x27: abc4a6200fa0
[ 17.599124] x26: 07ff809e5c34 x25: 083e5f41980d x24: 07ff8610a0c0
[ 17.599126] x23: x22: 07ff9fe894c0 x21: 07ffb771a460
[ 17.599128] x20: 07ff9c6dc000 x19: x18: 0014
[ 17.599130] x17: c3142fa2 x16: 7e77e163 x15: 18c66856
[ 17.599132] x14: b8afd426 x13: 7e8b3b19 x12: 4a34fdf7
[ 17.599134] x11: a7cb2fcc x10: ff8a x9 :
[ 17.599136] x8 : 0025 x7 : 0001 x6 : abc487a054d8
[ 17.599138] x5 : 07ff9c6dc004 x4 : 000a x3 :
[ 17.599140] x2 : x1 : 0400 x0 : 07ff9c6dc004
[ 17.599142] Call trace:
[ 17.599143] ice_create_lag_recipe.constprop.0+0xbc/0x11c [ice]
[ 17.599172] ice_init_lag+0xcc/0x22c [ice]
[ 17.599201] ice_init_features+0x160/0x2b4 [ice]
[ 17.599230] ice_probe+0x2d0/0x30c [ice]
[ 17.599258] local_pci_probe+0x58/0xb0
[ 17.599262] work_for_cpu_fn+0x20/0x30
[ 17.599264] process_one_work+0x1e4/0x4c0
[ 17.599266] worker_thread+0x220/0x450
[ 17.599268] kthread+0xe8/0xf4
[ 17.599270] ret_from_fork+0x10/0x20
[ 17.599273] Code: 380044a4 f800429f 8b000ca0 d503201f (f821301f)
[ 17.599274] ---[ end trace 168d79e2ecf9f7e3 ]---
[ 17.599275] Kernel panic - not syncing: Oops: Fatal exception
[ 17.893321] SMP: stopping secondary CPUs
[ 17.897374] Kernel Offset: 0x2bc49c40 from 0x8800
[ 17.903453] PHYS_OFFSET: 0x8000
[ 17.906928] CPU features: 0x0,0001,70028143,1041720b
[ 17.912226] Memory Limit: none
[ 17.915268] ---[ end Kernel panic - not syncing: Oops: Fatal exception ]---
Fixes: 1e0f9881ef79 ("ice: Flesh out implementation of support for SRIOV on
bonded interface")
Signed-off-by: Michal Schmidt
---
drivers/net/ethernet/intel/ice/ice_lag.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_lag.c
b/drivers/net/ethernet/intel/ice/ice_lag.c
index 2a25323105e5..d4848f6fe919 100644
--- a/drivers/net/ethernet/intel/ice/ice_lag.c
+++ b/drivers/net/ethernet/intel/ice/ice_lag.c
@@ -1829,9 +1829,7 @@ static int ice_create_lag_recipe(struct ice_hw *hw, u16
*rid,
new_rcp->content.act_ctrl_fwd_priority = prio;
new_rcp->content.rid = *rid | ICE_AQ_RECIPE_ID_IS_ROOT;
new_rcp->recipe_indx = *rid;
- bitmap_zero((unsigned long *)new_rcp->recipe_bitmap,
- ICE_MAX_NUM_RECIPES);
- set_bit(*rid, (unsigned long *)new_rcp->recipe_bitmap);
+ put_unaligned_le64(BIT_ULL(*rid), new_rcp->recipe_bitmap);
err = ice_aq_add_recipe(hw, new_rcp, 1, NULL);
if (err)
--
Re: [Intel-wired-lan] [PATCH] ice: Add get/set hw address for VF representor ports
Wed, Jan 31, 2024 at 11:43:44AM CET, michal.swiatkow...@linux.intel.com wrote: >On Wed, Jan 31, 2024 at 01:38:47PM +0530, karthiksundaravel wrote: >> Changing the mac address of the VF representor ports are not >> available via devlink. Add the function handlers to set and get >> the HW address for the VF representor ports. >> >> Signed-off-by: karthiksundaravel >> --- >> drivers/net/ethernet/intel/ice/ice_devlink.c | 134 ++- >> 1 file changed, 132 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/net/ethernet/intel/ice/ice_devlink.c >> b/drivers/net/ethernet/intel/ice/ice_devlink.c >> index 80dc5445b50d..56d81836c469 100644 >> --- a/drivers/net/ethernet/intel/ice/ice_devlink.c >> +++ b/drivers/net/ethernet/intel/ice/ice_devlink.c >> @@ -9,6 +9,8 @@ > >As Jiri already wrote, you are not changing MAC of VF in your code. Try >to look at ice_set_vf_mac in ice_sriov.c. In current implementation you >nedd to set new MAC value for VF and reset it. You shouldn't use PF VSI. > >Pointer to VF you can get from representor struct (through parent VSI). What if it is in a different host? Would you still be able to change the mac? > >You shouldn't manage the rules during MAC changing, as in switchdev >slow-path there shouldn't be VF MAC rules. It can be problematic as user >already can have MAC + sth rule (which also needs to be change). I will >leave it to user (most probably the MAC change happens before adding any >rules). Rules are on the representor, not the VF, correct? Seems unrelated to me. > >In few days we will send patchset for subfunction support where the >subfunction MAC chaning is implementing from devlink API. I will add you >to the CC. > >Thanks for working on it, it is a gap in our solution. > >Thanks, >Michal >
Re: [Intel-wired-lan] [PATCH net] ice: fix unaligned access in ice_create_lag_recipe
Wed, Jan 31, 2024 at 12:58:23PM CET, mschm...@redhat.com wrote:
>new_rcp->recipe_bitmap was written to as if it were an aligned bitmap.
>It is an 8-byte array, but aligned only to 4.
>Use put_unaligned to set its value.
>
>Additionally, values in ice commands are typically in little-endian.
>I assume the recipe bitmap should be too, so use the *_le64 conversion.
>I don't have a big-endian system with ice to test this.
>
>I tested that the driver does not crash when probing on aarch64 anymore,
>which is good enough for me. I don't know if the LAG feature actually
>works.
>
>This is what the crash looked like without the fix:
>[ 17.599009] Unable to handle kernel paging request at virtual address
>07ff9c6dc004
>[ 17.599011] Mem abort info:
>[ 17.599011] ESR = 0x9621
>[ 17.599012] EC = 0x25: DABT (current EL), IL = 32 bits
>[ 17.599013] SET = 0, FnV = 0
>[ 17.599014] EA = 0, S1PTW = 0
>[ 17.599014] FSC = 0x21: alignment fault
>[ 17.599015] Data abort info:
>[ 17.599016] ISV = 0, ISS = 0x0021, ISS2 = 0x
>[ 17.599016] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
>[ 17.599017] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
>[ 17.599019] swapper pgtable: 4k pages, 48-bit VAs, pgdp=080dd6bd
>[ 17.599020] [07ff9c6dc004] pgd=1800083fffacf003, p4d=1800083fffacf003,
>pud=1800083ffface003, pmd=1800083fff9ea003, pte=006808001c6dcf07
>[ 17.599025] Internal error: Oops: 9621 [#1] SMP
>[ 17.599027] Modules linked in: crct10dif_ce ghash_ce sha2_ce sha256_arm64
>mlx5_core sha1_ce sbsa_gwdt ice(+) nvme nvme_core mlxfw igb tls nvme_common
>psample i2c_algo_bit gnss pci_hyperv_intf i2c_designware_platform
>i2c_designware_core xgene_hwmon dm_mirror dm_region_hash dm_log dm_mod
>[ 17.599043] CPU: 0 PID: 18 Comm: kworker/0:1 Not tainted
>5.14.0-407.el9.aarch64 #1
>[ 17.599044] Hardware name: GIGABYTE R272-P31-00/MP32-AR1-00, BIOS F31L
>(SCP: 2.10.20220531) 09/29/2022
>[ 17.599046] Workqueue: events work_for_cpu_fn
>[ 17.599051] pstate: 6049 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
>[ 17.599053] pc : ice_create_lag_recipe.constprop.0+0xbc/0x11c [ice]
>[ 17.599091] lr : ice_create_lag_recipe.constprop.0+0x54/0x11c [ice]
>[ 17.599121] sp : 884a3c50
>[ 17.599122] x29: 884a3c50 x28: abc4a6790f00 x27:
>abc4a6200fa0
>[ 17.599124] x26: 07ff809e5c34 x25: 083e5f41980d x24:
>07ff8610a0c0
>[ 17.599126] x23: x22: 07ff9fe894c0 x21:
>07ffb771a460
>[ 17.599128] x20: 07ff9c6dc000 x19: x18:
>0014
>[ 17.599130] x17: c3142fa2 x16: 7e77e163 x15:
>18c66856
>[ 17.599132] x14: b8afd426 x13: 7e8b3b19 x12:
>4a34fdf7
>[ 17.599134] x11: a7cb2fcc x10: ff8a x9 :
>
>[ 17.599136] x8 : 0025 x7 : 0001 x6 :
>abc487a054d8
>[ 17.599138] x5 : 07ff9c6dc004 x4 : 000a x3 :
>
>[ 17.599140] x2 : x1 : 0400 x0 :
>07ff9c6dc004
>[ 17.599142] Call trace:
>[ 17.599143] ice_create_lag_recipe.constprop.0+0xbc/0x11c [ice]
>[ 17.599172] ice_init_lag+0xcc/0x22c [ice]
>[ 17.599201] ice_init_features+0x160/0x2b4 [ice]
>[ 17.599230] ice_probe+0x2d0/0x30c [ice]
>[ 17.599258] local_pci_probe+0x58/0xb0
>[ 17.599262] work_for_cpu_fn+0x20/0x30
>[ 17.599264] process_one_work+0x1e4/0x4c0
>[ 17.599266] worker_thread+0x220/0x450
>[ 17.599268] kthread+0xe8/0xf4
>[ 17.599270] ret_from_fork+0x10/0x20
>[ 17.599273] Code: 380044a4 f800429f 8b000ca0 d503201f (f821301f)
>[ 17.599274] ---[ end trace 168d79e2ecf9f7e3 ]---
>[ 17.599275] Kernel panic - not syncing: Oops: Fatal exception
>[ 17.893321] SMP: stopping secondary CPUs
>[ 17.897374] Kernel Offset: 0x2bc49c40 from 0x8800
>[ 17.903453] PHYS_OFFSET: 0x8000
>[ 17.906928] CPU features: 0x0,0001,70028143,1041720b
>[ 17.912226] Memory Limit: none
>[ 17.915268] ---[ end Kernel panic - not syncing: Oops: Fatal exception ]---
>
>Fixes: 1e0f9881ef79 ("ice: Flesh out implementation of support for SRIOV on
>bonded interface")
>Signed-off-by: Michal Schmidt
>---
> drivers/net/ethernet/intel/ice/ice_lag.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
>diff --git a/drivers/net/ethernet/intel/ice/ice_lag.c
>b/drivers/net/ethernet/intel/ice/ice_lag.c
>index 2a25323105e5..d4848f6fe919 100644
>--- a/drivers/net/ethernet/intel/ice/ice_lag.c
>+++ b/drivers/net/ethernet/intel/ice/ice_lag.c
>@@ -1829,9 +1829,7 @@ static int ice_create_lag_recipe(struct ice_hw *hw, u16
>*rid,
> new_rcp->content.act_ctrl_fwd_priority = prio;
> new_rcp->content.rid = *rid | ICE_AQ_RECIPE_ID_IS_ROOT;
> new_rcp->recipe_indx = *rid;
>- bitmap_zero((unsigned long *)new_rcp->recipe_bitmap,
>- ICE_MAX_NUM_RECIPES);
>- set_bit(*rid, (unsigned long *
[Intel-wired-lan] [PATCH net] i40e: Do not allow untrusted VF to remove administratively set MAC
Currently when PF administratively sets VF's MAC address and the VF
is put down (VF tries to delete all MACs) then the MAC is removed
from MAC filters and primary VF MAC is zeroed.
Do not allow untrusted VF to remove primary MAC when it was set
administratively by PF.
Reproducer:
1) Create VF
2) Set VF interface up
3) Administratively set the VF's MAC
4) Put VF interface down
[root@host ~]# echo 1 > /sys/class/net/enp2s0f0/device/sriov_numvfs
[root@host ~]# ip link set enp2s0f0v0 up
[root@host ~]# ip link set enp2s0f0 vf 0 mac fe:6c:b5:da:c7:7d
[root@host ~]# ip link show enp2s0f0
23: enp2s0f0: mtu 1500 qdisc mq state UP mode
DEFAULT group default qlen 1000
link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff
vf 0 link/ether fe:6c:b5:da:c7:7d brd ff:ff:ff:ff:ff:ff, spoof checking
on, link-state auto, trust off
[root@host ~]# ip link set enp2s0f0v0 down
[root@host ~]# ip link show enp2s0f0
23: enp2s0f0: mtu 1500 qdisc mq state UP mode
DEFAULT group default qlen 1000
link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff
vf 0 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking
on, link-state auto, trust off
Fixes: 700bbf6c1f9e ("i40e: allow VF to remove any MAC filter")
Fixes: ceb29474bbbc ("i40e: Add support for VF to specify its primary MAC
address")
Signed-off-by: Ivan Vecera
---
.../ethernet/intel/i40e/i40e_virtchnl_pf.c| 38 ---
1 file changed, 33 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
index 908cdbd3ec5d..b34c71770887 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -2848,6 +2848,24 @@ static int i40e_vc_get_stats_msg(struct i40e_vf *vf, u8
*msg)
(u8 *)&stats, sizeof(stats));
}
+/**
+ * i40e_can_vf_change_mac
+ * @vf: pointer to the VF info
+ *
+ * Return true if the VF is allowed to change its MAC filters, false otherwise
+ */
+static bool i40e_can_vf_change_mac(struct i40e_vf *vf)
+{
+ /* If the VF MAC address has been set administratively (via the
+* ndo_set_vf_mac command), then deny permission to the VF to
+* add/delete unicast MAC addresses, unless the VF is trusted
+*/
+ if (vf->pf_set_mac && !vf->trusted)
+ return false;
+
+ return true;
+}
+
#define I40E_MAX_MACVLAN_PER_HW 3072
#define I40E_MAX_MACVLAN_PER_PF(num_ports) (I40E_MAX_MACVLAN_PER_HW / \
(num_ports))
@@ -2907,8 +2925,8 @@ static inline int i40e_check_vf_permission(struct i40e_vf
*vf,
* The VF may request to set the MAC address filter already
* assigned to it so do not return an error in that case.
*/
- if (!test_bit(I40E_VIRTCHNL_VF_CAP_PRIVILEGE, &vf->vf_caps) &&
- !is_multicast_ether_addr(addr) && vf->pf_set_mac &&
+ if (!i40e_can_vf_change_mac(vf) &&
+ !is_multicast_ether_addr(addr) &&
!ether_addr_equal(addr, vf->default_lan_addr.addr)) {
dev_err(&pf->pdev->dev,
"VF attempting to override administratively set
MAC address, bring down and up the VF interface to resume normal operation\n");
@@ -3114,19 +3132,29 @@ static int i40e_vc_del_mac_addr_msg(struct i40e_vf *vf,
u8 *msg)
ret = -EINVAL;
goto error_param;
}
- if (ether_addr_equal(al->list[i].addr,
vf->default_lan_addr.addr))
- was_unimac_deleted = true;
}
vsi = pf->vsi[vf->lan_vsi_idx];
spin_lock_bh(&vsi->mac_filter_hash_lock);
/* delete addresses from the list */
- for (i = 0; i < al->num_elements; i++)
+ for (i = 0; i < al->num_elements; i++) {
+ const u8 *addr = al->list[i].addr;
+
+ /* Allow to delete VF primary MAC only if it was not set
+* administratively by PF or if VF is trusted.
+*/
+ if (ether_addr_equal(addr, vf->default_lan_addr.addr) &&
+ i40e_can_vf_change_mac(vf))
+ was_unimac_deleted = true;
+ else
+ continue;
+
if (i40e_del_mac_filter(vsi, al->list[i].addr)) {
ret = -EINVAL;
spin_unlock_bh(&vsi->mac_filter_hash_lock);
goto error_param;
}
+ }
spin_unlock_bh(&vsi->mac_filter_hash_lock);
--
2.39.3
Re: [Intel-wired-lan] [PATCH net-next v5] ethtool: ice: Support for RSS settings to GTP from ethtool
Hi Marcin-san > LGTM Thanks for your review! > Still removing this line :c Oh! Sorry for the oversight. I will fix it in the next patch. Could you please take another look at the patch? Thanks Takeru 2024年1月31日(水) 20:53 Marcin Szycik : > > > > On 31.01.2024 02:37, Takeru Hayasaka wrote: > > This is a patch that enables RSS functionality for GTP packets using > > ethtool. > > > > A user can include TEID and make RSS work for GTP-U over IPv4 by doing the > > following:`ethtool -N ens3 rx-flow-hash gtpu4 sde` > > > > In addition to gtpu(4|6), we now support gtpc(4|6),gtpc(4|6)t,gtpu(4|6)e, > > gtpu(4|6)u, and gtpu(4|6)d. > > > > gtpc(4|6): Used for GTP-C in IPv4 and IPv6, where the GTP header format does > > not include a TEID. > > gtpc(4|6)t: Used for GTP-C in IPv4 and IPv6, with a GTP header format that > > includes a TEID. > > gtpu(4|6): Used for GTP-U in both IPv4 and IPv6 scenarios. > > gtpu(4|6)e: Used for GTP-U with extended headers in both IPv4 and IPv6. > > gtpu(4|6)u: Used when the PSC (PDU session container) in the GTP-U extended > > header includes Uplink, applicable to both IPv4 and IPv6. > > gtpu(4|6)d: Used when the PSC in the GTP-U extended header includes > > Downlink, > > for both IPv4 and IPv6. > > > > GTP generates a flow that includes an ID called TEID to identify the tunnel. > > This tunnel is created for each UE (User Equipment).By performing RSS based > > on > > this flow, it is possible to apply RSS for each communication unit from the > > UE. > > Without this, RSS would only be effective within the range of IP addresses. > > For > > instance, the PGW can only perform RSS within the IP range of the SGW. > > Problematic from a load distribution perspective, especially if there's a > > bias > > in the terminals connected to a particular base station.This case can be > > solved by using this patch. > > LGTM > Reviewed-by: Marcin Szycik > > > Signed-off-by: Takeru Hayasaka > > --- > > v2->v3: Based on Harald-san's review, I added documentation and comments to > > ethtool.h and ice.rst. > > v3->v4: Based on Marcin-san's review, I added the missing code for GTPC and > > GTPC_TEID, and revised the documentation and comments. > > v4->v5: Based on Marcin-san's review, I fixed rename and wrong code > > regarding > > GTPC > > [...] > > > f Hash on bytes 0 and 1 of the Layer 4 header of the Rx packet. > > n Hash on bytes 2 and 3 of the Layer 4 header of the Rx packet. > > - > > Still removing this line :c > > > +e Hash on GTP Packet on TEID (4bytes) of the Rx packet. > > > > Accelerated Receive Flow Steering (aRFS) > > > > ---8<---
[Intel-wired-lan] [PATCH net-next v6] ethtool: ice: Support for RSS settings to GTP from ethtool
This is a patch that enables RSS functionality for GTP packets using ethtool. A user can include TEID and make RSS work for GTP-U over IPv4 by doing the following:`ethtool -N ens3 rx-flow-hash gtpu4 sde` In addition to gtpu(4|6), we now support gtpc(4|6),gtpc(4|6)t,gtpu(4|6)e, gtpu(4|6)u, and gtpu(4|6)d. gtpc(4|6): Used for GTP-C in IPv4 and IPv6, where the GTP header format does not include a TEID. gtpc(4|6)t: Used for GTP-C in IPv4 and IPv6, with a GTP header format that includes a TEID. gtpu(4|6): Used for GTP-U in both IPv4 and IPv6 scenarios. gtpu(4|6)e: Used for GTP-U with extended headers in both IPv4 and IPv6. gtpu(4|6)u: Used when the PSC (PDU session container) in the GTP-U extended header includes Uplink, applicable to both IPv4 and IPv6. gtpu(4|6)d: Used when the PSC in the GTP-U extended header includes Downlink, for both IPv4 and IPv6. GTP generates a flow that includes an ID called TEID to identify the tunnel. This tunnel is created for each UE (User Equipment).By performing RSS based on this flow, it is possible to apply RSS for each communication unit from the UE. Without this, RSS would only be effective within the range of IP addresses. For instance, the PGW can only perform RSS within the IP range of the SGW. Problematic from a load distribution perspective, especially if there's a bias in the terminals connected to a particular base station.This case can be solved by using this patch. Signed-off-by: Takeru Hayasaka --- v2->v3: Based on Harald-san's review, I added documentation and comments to ethtool.h and ice.rst. v3->v4: Based on Marcin-san's review, I added the missing code for GTPC and GTPC_TEID, and revised the documentation and comments. v4->v5: Based on Marcin-san's review, I fixed rename and wrong code regarding GTPC v5->v6: Based on Marcin-san's review, Undoing the addition of unnecessary blank lines.Minor fixes. .../device_drivers/ethernet/intel/ice.rst | 21 - drivers/net/ethernet/intel/ice/ice_ethtool.c | 82 +++ drivers/net/ethernet/intel/ice/ice_flow.h | 31 +-- drivers/net/ethernet/intel/ice/ice_lib.c | 37 + include/uapi/linux/ethtool.h | 48 +++ 5 files changed, 210 insertions(+), 9 deletions(-) diff --git a/Documentation/networking/device_drivers/ethernet/intel/ice.rst b/Documentation/networking/device_drivers/ethernet/intel/ice.rst index 5038e54586af..934752f675ba 100644 --- a/Documentation/networking/device_drivers/ethernet/intel/ice.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/ice.rst @@ -368,15 +368,28 @@ more options for Receive Side Scaling (RSS) hash byte configuration. # ethtool -N rx-flow-hash Where is: -tcp4 signifying TCP over IPv4 -udp4 signifying UDP over IPv4 -tcp6 signifying TCP over IPv6 -udp6 signifying UDP over IPv6 +tcp4signifying TCP over IPv4 +udp4signifying UDP over IPv4 +gtpc4 signifying GTP-C over IPv4 +gtpc4t signifying GTP-C (include TEID) over IPv4 +gtpu4 signifying GTP-U over IPV4 +gtpu4e signifying GTP-U and Extension Header over IPV4 +gtpu4u signifying GTP-U PSC Uplink over IPV4 +gtpu4d signifying GTP-U PSC Downlink over IPV4 +tcp6signifying TCP over IPv6 +udp6signifying UDP over IPv6 +gtpc6 signifying GTP-C over IPv6 +gtpc6t signifying GTP-C (include TEID) over IPv6 +gtpu6 signifying GTP-U over IPV6 +gtpu6e signifying GTP-U and Extension Header over IPV6 +gtpu6u signifying GTP-U PSC Uplink over IPV6 +gtpu6d signifying GTP-U PSC Downlink over IPV6 And is one or more of: s Hash on the IP source address of the Rx packet. d Hash on the IP destination address of the Rx packet. f Hash on bytes 0 and 1 of the Layer 4 header of the Rx packet. n Hash on bytes 2 and 3 of the Layer 4 header of the Rx packet. +e Hash on GTP Packet on TEID (4bytes) of the Rx packet. Accelerated Receive Flow Steering (aRFS) diff --git a/drivers/net/ethernet/intel/ice/ice_ethtool.c b/drivers/net/ethernet/intel/ice/ice_ethtool.c index a19b06f18e40..d0e05032f464 100644 --- a/drivers/net/ethernet/intel/ice/ice_ethtool.c +++ b/drivers/net/ethernet/intel/ice/ice_ethtool.c @@ -2486,6 +2486,24 @@ static u32 ice_parse_hdrs(struct ethtool_rxnfc *nfc) case SCTP_V4_FLOW: hdrs |= ICE_FLOW_SEG_HDR_SCTP | ICE_FLOW_SEG_HDR_IPV4; break; + case GTPU_V4_FLOW: + hdrs |= ICE_FLOW_SEG_HDR_GTPU_IP | ICE_FLOW_SEG_HDR_IPV4; + break; + case GTPC_V4_FLOW: + hdrs |= ICE_FLOW_SEG_HDR_GTPC | ICE_FLOW_SEG_HDR_IPV4; + break; + case GTPC_TEID_V4_FLOW: + hdrs |= ICE_FLOW_SEG_HDR_GTPC_TEID | ICE_FLOW_SEG_HDR_IPV4; + break; + case GTPU_EH_V4_FLOW: + hdrs |= ICE_FLOW_SEG_HDR_GTPU_EH | ICE_FLOW_SEG_HDR_IPV4; + break; + case GTPU_UL_V4_FLOW: +
Re: [Intel-wired-lan] [PATCH iwl-next v4 2/2] ice: Implement 'flow-type ether' rules
On 1/25/2024 12:09 AM, Paul Menzel wrote:
Dear Lukasz, dear Jakub, dear Mateusz,
Thank you for your patch.
Am 24.01.24 um 16:21 schrieb Lukasz Plachno:
From: Jakub Buchocki
Add support for 'flow-type ether' Flow Director rules via ethtool.
Can you please elaborate on the implementation?
New commit message below
Rules not containing masks are processed by the Flow Director,
and support the following set of input parameters in all combinations:
src, dst, proto, vlan-etype, vlan, action.
It is possible to specify address mask in ethtool parameters but only
00:00:00:00:00 and FF:FF:FF:FF:FF are valid.
The same applies to proto, vlan-etype and vlan masks:
only 0x and 0x masks are valid.
It’d be great, if you gave an example, how you tested this.
Example at the bottom, let me know if such commit message is OK for you.
ice: Implement 'flow-type ether' rules
Add support for 'flow-type ether' Flow Director rules via ethtool.
Create packet segment info for filter configuration based on ethtool
command parameters.
Reuse infrastructure already created for ipv4 and ipv6 flows to convert
packet segment into extraction sequence, which is later used to program
the filter inside Flow Director block of the Rx pipeline.
Rules not containing masks are processed by the Flow Director,
and support the following set of input parameters in all
combinations: src, dst, proto, vlan-etype, vlan, action.
It is possible to specify address mask in ethtool parameters but
only 00:00:00:00:00 and FF:FF:FF:FF:FF are valid.
The same applies to proto, vlan-etype and vlan masks:
only 0x and 0x masks are valid.
Testing:
# (DUT) iperf3 -s
# (DUT) ethtool -U ens785f0np0 flow-type ether dst 00:00:00:00:01:00
action 10
# (DUT) watch 'ethtool -S ens785f0np0 | grep rx_queue'
# (LP) iperf3 -c ${DUT_IP}
Counters increase only for:
'rx_queue_10_packets'
'rx_queue_10_bytes'
Thanks,
Łukasz
Signed-off-by: Jakub Buchocki
Co-developed-by: Mateusz Pacuszka
Signed-off-by: Mateusz Pacuszka
Reviewed-by: Przemek Kitszel
Signed-off-by: Lukasz Plachno
---
.../net/ethernet/intel/ice/ice_ethtool_fdir.c | 140 +-
drivers/net/ethernet/intel/ice/ice_fdir.c | 27
drivers/net/ethernet/intel/ice/ice_fdir.h | 11 ++
drivers/net/ethernet/intel/ice/ice_type.h | 1 +
4 files changed, 178 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_ethtool_fdir.c
b/drivers/net/ethernet/intel/ice/ice_ethtool_fdir.c
index 9a1a04f5f146..d6fadc65a7a6 100644
--- a/drivers/net/ethernet/intel/ice/ice_ethtool_fdir.c
+++ b/drivers/net/ethernet/intel/ice/ice_ethtool_fdir.c
@@ -41,6 +41,8 @@ static struct in6_addr zero_ipv6_addr_mask = {
static int ice_fltr_to_ethtool_flow(enum ice_fltr_ptype flow)
{
switch (flow) {
+ case ICE_FLTR_PTYPE_NONF_ETH:
+ return ETHER_FLOW;
case ICE_FLTR_PTYPE_NONF_IPV4_TCP:
return TCP_V4_FLOW;
case ICE_FLTR_PTYPE_NONF_IPV4_UDP:
@@ -72,6 +74,8 @@ static int ice_fltr_to_ethtool_flow(enum
ice_fltr_ptype flow)
static enum ice_fltr_ptype ice_ethtool_flow_to_fltr(int eth)
{
switch (eth) {
+ case ETHER_FLOW:
+ return ICE_FLTR_PTYPE_NONF_ETH;
case TCP_V4_FLOW:
return ICE_FLTR_PTYPE_NONF_IPV4_TCP;
case UDP_V4_FLOW:
@@ -137,6 +141,15 @@ int ice_get_ethtool_fdir_entry(struct ice_hw *hw,
struct ethtool_rxnfc *cmd)
memset(&fsp->m_ext, 0, sizeof(fsp->m_ext));
switch (fsp->flow_type) {
+ case ETHER_FLOW:
+ fsp->h_u.ether_spec.h_proto = rule->eth.type;
+ fsp->m_u.ether_spec.h_proto = rule->eth_mask.type;
+ ether_addr_copy(fsp->h_u.ether_spec.h_dest, rule->eth.dst);
+ ether_addr_copy(fsp->m_u.ether_spec.h_dest, rule->eth_mask.dst);
+ ether_addr_copy(fsp->h_u.ether_spec.h_source, rule->eth.src);
+ ether_addr_copy(fsp->m_u.ether_spec.h_source,
+ rule->eth_mask.src);
+ break;
case IPV4_USER_FLOW:
fsp->h_u.usr_ip4_spec.ip_ver = ETH_RX_NFC_IP4;
fsp->h_u.usr_ip4_spec.proto = 0;
@@ -1193,6 +1206,111 @@ ice_set_fdir_ip6_usr_seg(struct
ice_flow_seg_info *seg,
return 0;
}
+/**
+ * ice_fdir_vlan_valid - validate VLAN data for Flow Director rule
+ * @fsp: pointer to ethtool Rx flow specification
+ *
+ * Return: true if vlan data is valid, false otherwise
+ */
+static bool ice_fdir_vlan_valid(struct ethtool_rx_flow_spec *fsp)
+{
+ if (fsp->m_ext.vlan_etype && !eth_type_vlan(fsp->h_ext.vlan_etype))
+ return false;
+
+ if (fsp->m_ext.vlan_tci &&
+ ntohs(fsp->h_ext.vlan_tci) >= VLAN_N_VID)
+ return false;
+
+ return true;
+}
+
+/**
+ * ice_set_ether_flow_seg
+ * @seg: flow segment for programming
+ * @eth_spec: mask data from ethtool
+ *
+ * Return: 0 on success and errno in case of error.
+ */
+static int ice_set_ether_flow_seg(struct device *dev,
+ struct ice_flow_seg_info *seg,
+ struct ethhdr *eth_spec)
+{
[Intel-wired-lan] [PATCH] ice: Add get/set hw address for VF representor ports
Changing the mac address of the VF representor ports are not
available via devlink. Add the function handlers to set and get
the HW address for the VF representor ports.
Signed-off-by: karthiksundaravel
---
drivers/net/ethernet/intel/ice/ice_devlink.c | 134 ++-
1 file changed, 132 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_devlink.c
b/drivers/net/ethernet/intel/ice/ice_devlink.c
index 80dc5445b50d..56d81836c469 100644
--- a/drivers/net/ethernet/intel/ice/ice_devlink.c
+++ b/drivers/net/ethernet/intel/ice/ice_devlink.c
@@ -9,6 +9,8 @@
#include "ice_eswitch.h"
#include "ice_fw_update.h"
#include "ice_dcb_lib.h"
+#include "ice_fltr.h"
+#include "ice_tc_lib.h"
static int ice_active_port_option = -1;
@@ -1576,6 +1578,134 @@ void ice_devlink_destroy_pf_port(struct ice_pf *pf)
devlink_port_unregister(&pf->devlink_port);
}
+/**
+ * ice_devlink_port_get_vf_mac_address - .port_fn_hw_addr_get devlink handler
+ * @port: devlink port structure
+ * @hw_addr: Mac address of the port
+ * @hw_addr_len: length of mac address
+ * @extack: extended netdev ack structure
+ *
+ * Callback for the devlink .port_fn_hw_addr_get operation
+ * Return: zero on success or an error code on failure.
+ */
+
+static int ice_devlink_port_get_vf_mac_address(struct devlink_port *port,
+ u8 *hw_addr, int *hw_addr_len,
+ struct netlink_ext_ack *extack)
+{
+ struct net_device *netdev = port->type_eth.netdev;
+
+ if (!netdev || !netdev->dev_addr)
+ return -EADDRNOTAVAIL;
+
+ ether_addr_copy(hw_addr, netdev->dev_addr);
+ *hw_addr_len = ETH_ALEN;
+ return 0;
+}
+
+/**
+ * ice_devlink_port_set_vf_mac_address - .port_fn_hw_addr_set devlink handler
+ * @port: devlink port structure
+ * @hw_addr: Mac address of the port
+ * @hw_addr_len: length of mac address
+ * @extack: extended netdev ack structure
+ *
+ * Callback for the devlink .port_fn_hw_addr_set operation
+ * Return: zero on success or an error code on failure.
+ */
+static int ice_devlink_port_set_vf_mac_address(struct devlink_port *port,
+ const u8 *hw_addr,
+ int hw_addr_len,
+ struct netlink_ext_ack *extack)
+{
+ struct devlink *devlink = port->devlink;
+ struct net_device *netdev = port->type_eth.netdev;
+ struct ice_pf *pf = devlink_priv(devlink);
+ struct ice_vsi *vsi = *pf->vsi;
+ struct ice_hw *hw = &pf->hw;
+ struct device *dev = ice_pf_to_dev(pf);
+ u8 old_mac[ETH_ALEN];
+ u8 flags = 0;
+ const u8 *mac = hw_addr;
+ int err;
+
+ if (!netdev)
+ return -EADDRNOTAVAIL;
+
+ if (!is_valid_ether_addr(mac))
+ return -EADDRNOTAVAIL;
+
+ if (ether_addr_equal(netdev->dev_addr, mac)) {
+ dev_dbg(dev, "already using mac %pM\n", mac);
+ return 0;
+ }
+
+ if (test_bit(ICE_DOWN, pf->state) ||
+ ice_is_reset_in_progress(pf->state)) {
+ dev_err(dev, "can't set mac %pM. device not ready\n", mac);
+ return -EBUSY;
+ }
+
+ if (ice_chnl_dmac_fltr_cnt(pf)) {
+ dev_err(dev, "can't set mac %pM. Device has tc-flower filters,
delete all of them and try again\n",
+ mac);
+ return -EAGAIN;
+ }
+
+ netif_addr_lock_bh(netdev);
+ ether_addr_copy(old_mac, netdev->dev_addr);
+ /* change the netdev's MAC address */
+ eth_hw_addr_set(netdev, mac);
+ netif_addr_unlock_bh(netdev);
+
+ /* Clean up old MAC filter. Not an error if old filter doesn't exist */
+ err = ice_fltr_remove_mac(vsi, old_mac, ICE_FWD_TO_VSI);
+ if (err && err != -ENOENT) {
+ err = -EADDRNOTAVAIL;
+ goto err_update_filters;
+ }
+
+ /* Add filter for new MAC. If filter exists, return success */
+ err = ice_fltr_add_mac(vsi, mac, ICE_FWD_TO_VSI);
+ if (err == -EEXIST) {
+ /* Although this MAC filter is already present in hardware it's
+* possible in some cases (e.g. bonding) that dev_addr was
+* modified outside of the driver and needs to be restored back
+* to this value.
+*/
+ dev_dbg(dev, "filter for MAC %pM already exists\n", mac);
+ return 0;
+ } else if (err) {
+ /* error if the new filter addition failed */
+ err = -EADDRNOTAVAIL;
+ }
+
+err_update_filters:
+ if (err) {
+ dev_err(dev, "can't set MAC %pM. filter update failed\n", mac);
+ netif_addr_lock_bh(netdev);
+ eth_hw_addr_set(netdev, old_mac);
+ netif_addr_unlock_bh(netdev);
+ return err
Re: [Intel-wired-lan] [PATCH] ice: Add get/set hw address for VF representor ports
Dear karthiksundaravel,
Thank you for your patch.
Am 31.01.24 um 09:08 schrieb karthiksundaravel:
Changing the mac address of the VF representor ports are not
Do you mean “is not possible”?
available via devlink. Add the function handlers to set and get
the HW address for the VF representor ports.
How did you test this? It’d be great if you documented it.
Signed-off-by: karthiksundaravel
Is “karthiksundaravel” the official spelling of your name. If not, you
can change it with
git config --global user.name "Your Name"
git commit -s --amend --author="Your Name "
---
drivers/net/ethernet/intel/ice/ice_devlink.c | 134 ++-
1 file changed, 132 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_devlink.c
b/drivers/net/ethernet/intel/ice/ice_devlink.c
index 80dc5445b50d..56d81836c469 100644
--- a/drivers/net/ethernet/intel/ice/ice_devlink.c
+++ b/drivers/net/ethernet/intel/ice/ice_devlink.c
@@ -9,6 +9,8 @@
#include "ice_eswitch.h"
#include "ice_fw_update.h"
#include "ice_dcb_lib.h"
+#include "ice_fltr.h"
+#include "ice_tc_lib.h"
static int ice_active_port_option = -1;
@@ -1576,6 +1578,134 @@ void ice_devlink_destroy_pf_port(struct ice_pf *pf)
devlink_port_unregister(&pf->devlink_port);
}
+/**
+ * ice_devlink_port_get_vf_mac_address - .port_fn_hw_addr_get devlink handler
+ * @port: devlink port structure
+ * @hw_addr: Mac address of the port
+ * @hw_addr_len: length of mac address
Mac/mac is spelled differently. (Also below.)
+ * @extack: extended netdev ack structure
+ *
+ * Callback for the devlink .port_fn_hw_addr_get operation
+ * Return: zero on success or an error code on failure.
+ */
+
+static int ice_devlink_port_get_vf_mac_address(struct devlink_port *port,
+ u8 *hw_addr, int *hw_addr_len,
+ struct netlink_ext_ack *extack)
+{
+ struct net_device *netdev = port->type_eth.netdev;
+
+ if (!netdev || !netdev->dev_addr)
+ return -EADDRNOTAVAIL;
+
+ ether_addr_copy(hw_addr, netdev->dev_addr);
+ *hw_addr_len = ETH_ALEN;
+ return 0;
+}
+
+/**
+ * ice_devlink_port_set_vf_mac_address - .port_fn_hw_addr_set devlink handler
+ * @port: devlink port structure
+ * @hw_addr: Mac address of the port
+ * @hw_addr_len: length of mac address
+ * @extack: extended netdev ack structure
+ *
+ * Callback for the devlink .port_fn_hw_addr_set operation
+ * Return: zero on success or an error code on failure.
+ */
+static int ice_devlink_port_set_vf_mac_address(struct devlink_port *port,
+ const u8 *hw_addr,
+ int hw_addr_len,
+ struct netlink_ext_ack *extack)
+{
+ struct devlink *devlink = port->devlink;
+ struct net_device *netdev = port->type_eth.netdev;
+ struct ice_pf *pf = devlink_priv(devlink);
+ struct ice_vsi *vsi = *pf->vsi;
+ struct ice_hw *hw = &pf->hw;
+ struct device *dev = ice_pf_to_dev(pf);
+ u8 old_mac[ETH_ALEN];
+ u8 flags = 0;
+ const u8 *mac = hw_addr;
+ int err;
+
+ if (!netdev)
+ return -EADDRNOTAVAIL;
+
+ if (!is_valid_ether_addr(mac))
+ return -EADDRNOTAVAIL;
+
+ if (ether_addr_equal(netdev->dev_addr, mac)) {
+ dev_dbg(dev, "already using mac %pM\n", mac);
+ return 0;
+ }
+
+ if (test_bit(ICE_DOWN, pf->state) ||
+ ice_is_reset_in_progress(pf->state)) {
+ dev_err(dev, "can't set mac %pM. device not ready\n", mac);
+ return -EBUSY;
+ }
+
+ if (ice_chnl_dmac_fltr_cnt(pf)) {
+ dev_err(dev, "can't set mac %pM. Device has tc-flower filters,
delete all of them and try again\n",
+ mac);
+ return -EAGAIN;
+ }
+
+ netif_addr_lock_bh(netdev);
+ ether_addr_copy(old_mac, netdev->dev_addr);
+ /* change the netdev's MAC address */
The comment seems redundant.
+ eth_hw_addr_set(netdev, mac);
+ netif_addr_unlock_bh(netdev);
+
+ /* Clean up old MAC filter. Not an error if old filter doesn't exist */
+ err = ice_fltr_remove_mac(vsi, old_mac, ICE_FWD_TO_VSI);
+ if (err && err != -ENOENT) {
+ err = -EADDRNOTAVAIL;
+ goto err_update_filters;
+ }
+
+ /* Add filter for new MAC. If filter exists, return success */
+ err = ice_fltr_add_mac(vsi, mac, ICE_FWD_TO_VSI);
+ if (err == -EEXIST) {
+ /* Although this MAC filter is already present in hardware it's
+* possible in some cases (e.g. bonding) that dev_addr was
+* modified outside of the driver and needs to be restored back
+* to this value.
+*/
+ dev_dbg(dev, "filter
Re: [Intel-wired-lan] i40e XDP program stops transmitting after link down/up
On Tue, Jan 30, 2024 at 11:06:07PM +0100, Maciej Fijalkowski wrote: > On Tue, Jan 30, 2024 at 08:28:24PM +0100, Maciej Fijalkowski wrote: > > On Tue, Jan 30, 2024 at 10:59:13AM -0600, Seth Forshee wrote: > > > On Tue, Jan 30, 2024 at 05:14:23PM +0100, Paul Menzel wrote: > > > > Dear Seth, > > > > > > > > > > > > Thank you for bring this up. > > > > > > > > Am 30.01.24 um 15:17 schrieb Seth Forshee: > > > > > I got a inquiry from a colleague about a behavior he's seeing with > > > > > i40e > > > > > but not with other NICs. The interfaces are bonded with a XDP > > > > > load-balancer program attached to them. After 'ip link set ethX down; > > > > > ip > > > > > link set ethX up' on one of the interfaces the XDP program on that > > > > > interface is no longer transmitting packets. He found that tx starts > > > > > again after running 'sudo ethtool -t ethX'. > > > > > > > > > > There's a 'i40e :d8:00.1: VSI seid 391 XDP Tx ring 0 disable > > > > > timeout' message in dmesg when disabling the interface. I've included > > > > > the relevant portions from dmesg below. > > > > > > > > > > This was first observed with a 6.1 kernel, but we've confirmed that > > > > > the > > > > > behavior is the same in 6.7. I realize the firmware is pretty old, so > > > > > far our attempts to update the NVM have failed. > > > > > > > > Does that mean, the problem didn’t happen before Linux 6.1? If so, if > > > > you > > > > have the reproducer and the time, bisecting the issue is normally the > > > > fastest way to solve the issue. > > > > > > No, sorry, I should have worded that better. I meant that they were > > > using 6.1 when they noticed the issue, not that kernels before 6.1 did > > > not have that issue. We've also tried a 5.15 kernel build now and still > > > see the issue there, we haven't tested anything older than that. > > > > Hey Seth, > > > > I am observing same thing on my side with xdpsock in txonly mode, so I'll > > take a look at this and will keep you updated. > > Can you try this diff on your side? That fixes the problem! Thanks, Seth
Re: [Intel-wired-lan] i40e XDP program stops transmitting after link down/up
On Wed, Jan 31, 2024 at 10:26:07AM -0600, Seth Forshee wrote: > On Tue, Jan 30, 2024 at 11:06:07PM +0100, Maciej Fijalkowski wrote: > > On Tue, Jan 30, 2024 at 08:28:24PM +0100, Maciej Fijalkowski wrote: > > > On Tue, Jan 30, 2024 at 10:59:13AM -0600, Seth Forshee wrote: > > > > On Tue, Jan 30, 2024 at 05:14:23PM +0100, Paul Menzel wrote: > > > > > Dear Seth, > > > > > > > > > > > > > > > Thank you for bring this up. > > > > > > > > > > Am 30.01.24 um 15:17 schrieb Seth Forshee: > > > > > > I got a inquiry from a colleague about a behavior he's seeing with > > > > > > i40e > > > > > > but not with other NICs. The interfaces are bonded with a XDP > > > > > > load-balancer program attached to them. After 'ip link set ethX > > > > > > down; ip > > > > > > link set ethX up' on one of the interfaces the XDP program on that > > > > > > interface is no longer transmitting packets. He found that tx starts > > > > > > again after running 'sudo ethtool -t ethX'. > > > > > > > > > > > > There's a 'i40e :d8:00.1: VSI seid 391 XDP Tx ring 0 disable > > > > > > timeout' message in dmesg when disabling the interface. I've > > > > > > included > > > > > > the relevant portions from dmesg below. > > > > > > > > > > > > This was first observed with a 6.1 kernel, but we've confirmed that > > > > > > the > > > > > > behavior is the same in 6.7. I realize the firmware is pretty old, > > > > > > so > > > > > > far our attempts to update the NVM have failed. > > > > > > > > > > Does that mean, the problem didn’t happen before Linux 6.1? If so, if > > > > > you > > > > > have the reproducer and the time, bisecting the issue is normally the > > > > > fastest way to solve the issue. > > > > > > > > No, sorry, I should have worded that better. I meant that they were > > > > using 6.1 when they noticed the issue, not that kernels before 6.1 did > > > > not have that issue. We've also tried a 5.15 kernel build now and still > > > > see the issue there, we haven't tested anything older than that. > > > > > > Hey Seth, > > > > > > I am observing same thing on my side with xdpsock in txonly mode, so I'll > > > take a look at this and will keep you updated. > > > > Can you try this diff on your side? > > That fixes the problem! Awesome. I'll send a proper fix then and will keep you in loop. > > Thanks, > Seth
Re: [Intel-wired-lan] [PATCH net] ice: fix unaligned access in ice_create_lag_recipe
From: Jiri Pirko
Date: Wed, 31 Jan 2024 13:17:44 +0100
> Wed, Jan 31, 2024 at 12:58:23PM CET, mschm...@redhat.com wrote:
>> new_rcp->recipe_bitmap was written to as if it were an aligned bitmap.
>> It is an 8-byte array, but aligned only to 4.
>> Use put_unaligned to set its value.
>>
>> Additionally, values in ice commands are typically in little-endian.
>> I assume the recipe bitmap should be too, so use the *_le64 conversion.
>> I don't have a big-endian system with ice to test this.
>>
>> I tested that the driver does not crash when probing on aarch64 anymore,
>> which is good enough for me. I don't know if the LAG feature actually
>> works.
>>
>> This is what the crash looked like without the fix:
>> [ 17.599009] Unable to handle kernel paging request at virtual address
>> 07ff9c6dc004
>> [ 17.599011] Mem abort info:
>> [ 17.599011] ESR = 0x9621
>> [ 17.599012] EC = 0x25: DABT (current EL), IL = 32 bits
>> [ 17.599013] SET = 0, FnV = 0
>> [ 17.599014] EA = 0, S1PTW = 0
>> [ 17.599014] FSC = 0x21: alignment fault
>> [ 17.599015] Data abort info:
>> [ 17.599016] ISV = 0, ISS = 0x0021, ISS2 = 0x
>> [ 17.599016] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
>> [ 17.599017] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
>> [ 17.599019] swapper pgtable: 4k pages, 48-bit VAs, pgdp=080dd6bd
>> [ 17.599020] [07ff9c6dc004] pgd=1800083fffacf003,
>> p4d=1800083fffacf003, pud=1800083ffface003, pmd=1800083fff9ea003,
>> pte=006808001c6dcf07
>> [ 17.599025] Internal error: Oops: 9621 [#1] SMP
>> [ 17.599027] Modules linked in: crct10dif_ce ghash_ce sha2_ce sha256_arm64
>> mlx5_core sha1_ce sbsa_gwdt ice(+) nvme nvme_core mlxfw igb tls nvme_common
>> psample i2c_algo_bit gnss pci_hyperv_intf i2c_designware_platform
>> i2c_designware_core xgene_hwmon dm_mirror dm_region_hash dm_log dm_mod
>> [ 17.599043] CPU: 0 PID: 18 Comm: kworker/0:1 Not tainted
>> 5.14.0-407.el9.aarch64 #1
>> [ 17.599044] Hardware name: GIGABYTE R272-P31-00/MP32-AR1-00, BIOS F31L
>> (SCP: 2.10.20220531) 09/29/2022
>> [ 17.599046] Workqueue: events work_for_cpu_fn
>> [ 17.599051] pstate: 6049 (nZCv daif +PAN -UAO -TCO -DIT -SSBS
>> BTYPE=--)
>> [ 17.599053] pc : ice_create_lag_recipe.constprop.0+0xbc/0x11c [ice]
>> [ 17.599091] lr : ice_create_lag_recipe.constprop.0+0x54/0x11c [ice]
>> [ 17.599121] sp : 884a3c50
>> [ 17.599122] x29: 884a3c50 x28: abc4a6790f00 x27:
>> abc4a6200fa0
>> [ 17.599124] x26: 07ff809e5c34 x25: 083e5f41980d x24:
>> 07ff8610a0c0
>> [ 17.599126] x23: x22: 07ff9fe894c0 x21:
>> 07ffb771a460
>> [ 17.599128] x20: 07ff9c6dc000 x19: x18:
>> 0014
>> [ 17.599130] x17: c3142fa2 x16: 7e77e163 x15:
>> 18c66856
>> [ 17.599132] x14: b8afd426 x13: 7e8b3b19 x12:
>> 4a34fdf7
>> [ 17.599134] x11: a7cb2fcc x10: ff8a x9 :
>>
>> [ 17.599136] x8 : 0025 x7 : 0001 x6 :
>> abc487a054d8
>> [ 17.599138] x5 : 07ff9c6dc004 x4 : 000a x3 :
>>
>> [ 17.599140] x2 : x1 : 0400 x0 :
>> 07ff9c6dc004
>> [ 17.599142] Call trace:
>> [ 17.599143] ice_create_lag_recipe.constprop.0+0xbc/0x11c [ice]
>> [ 17.599172] ice_init_lag+0xcc/0x22c [ice]
>> [ 17.599201] ice_init_features+0x160/0x2b4 [ice]
>> [ 17.599230] ice_probe+0x2d0/0x30c [ice]
>> [ 17.599258] local_pci_probe+0x58/0xb0
>> [ 17.599262] work_for_cpu_fn+0x20/0x30
>> [ 17.599264] process_one_work+0x1e4/0x4c0
>> [ 17.599266] worker_thread+0x220/0x450
>> [ 17.599268] kthread+0xe8/0xf4
>> [ 17.599270] ret_from_fork+0x10/0x20
>> [ 17.599273] Code: 380044a4 f800429f 8b000ca0 d503201f (f821301f)
>> [ 17.599274] ---[ end trace 168d79e2ecf9f7e3 ]---
>> [ 17.599275] Kernel panic - not syncing: Oops: Fatal exception
>> [ 17.893321] SMP: stopping secondary CPUs
>> [ 17.897374] Kernel Offset: 0x2bc49c40 from 0x8800
>> [ 17.903453] PHYS_OFFSET: 0x8000
>> [ 17.906928] CPU features: 0x0,0001,70028143,1041720b
>> [ 17.912226] Memory Limit: none
>> [ 17.915268] ---[ end Kernel panic - not syncing: Oops: Fatal exception
>> ]---
>>
>> Fixes: 1e0f9881ef79 ("ice: Flesh out implementation of support for SRIOV on
>> bonded interface")
>> Signed-off-by: Michal Schmidt
>> ---
>> drivers/net/ethernet/intel/ice/ice_lag.c | 4 +---
>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/intel/ice/ice_lag.c
>> b/drivers/net/ethernet/intel/ice/ice_lag.c
>> index 2a25323105e5..d4848f6fe919 100644
>> --- a/drivers/net/ethernet/intel/ice/ice_lag.c
>> +++ b/drivers/net/ethernet/intel/ice/ice_lag.c
>> @@ -1829,9 +1829,7 @@ static int ice_create_lag_recipe(struct ice_hw *hw,
>> u16 *rid,
>> new_rcp->content.act_ctrl_fwd_p
Re: [Intel-wired-lan] [PATCH iwl-net v4] i40e: fix livelocks in i40e_reset_subtask()
On 1/31/2024 12:08 AM, Ivan Vecera wrote: Tony, why this is marked in IWL patchwork as ChangesRequested? There were no comments and the patch disappeared from dev-queue. Are you planning to process it? Hi Ivan, Our validation found that issues still existed even with these patches applied. I thought there was a response stating that, but I'm not seeing it. :( Apologies for that. Thanks, Tony Thanks, Ivan
Re: [Intel-wired-lan] [PATCH v2 0/7 iwl-next] idpf: refactor virtchnl messages
On 1/29/2024 7:43 AM, Alexander Lobakin wrote: From: Brady, Alan Date: Mon, 29 Jan 2024 16:12:06 +0100 -Original Message- From: Lobakin, Aleksander Sent: Monday, January 29, 2024 5:24 AM To: Brady, Alan Cc: intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; willemdebruijn.ker...@gmail.com; Bagnucki, Igor ; Kitszel, Przemyslaw Subject: Re: [Intel-wired-lan] [PATCH v2 0/7 iwl-next] idpf: refactor virtchnl messages From: Alan Brady Date: Thu, 25 Jan 2024 21:47:40 -0800 The motivation for this series has two primary goals. We want to enable support of multiple simultaneous messages and make the channel more robust. The way it works right now, the driver can only send and receive a single message at a time and if something goes really wrong, it can lead to data corruption and strange bugs. [...] There are a fistful of functions in this series and IDPF's virtchnl code in general that allocate a memory chunk via kzalloc() family and then free it at the end of the function, i.e. the lifetime of those buffers are the lifetime of the function. Since recently, we have auto-variables in the kernel, so that the pieces I described could be converted to: struct x *ptr __free(kfree) = NULL; ptr = kzalloc(sizeof(*x), GPF_KERNEL); // some code return 0; // kfree() is not needed anymore err: return err; // here as well That would allow to simplify the code and reduce its size. I'd like you to convert such functions to use auto-variables. Certainly, should be straightforward and make the code much better, sounds good to me. Just to clarify I'm only going to mess with the virtchnl functions I've otherwise altered in this patch series to maintain appropriate scope, yes? Yes, only virtchnl functions. New functions that you introduce 100%, the rest only if you touch them. I've gone ahead and submitted a v3 with the suggested changes. However, I would also like to follow this up with another series that addresses the entire idpf driver where we can not only use the automatic variables for kfree, but also make the various locks we have much better. I do end up touching some of the locks I introduced here, but I need to add a guard to include/linux/spinlock.h to convert all of it. I think it still makes sense to not include those changes in this series to avoid polluting it if possible, but there will be a dependency. Also thank you for pointing this out, I think it's a massive improvement to the driver code.
Re: [Intel-wired-lan] [PATCH v3 0/7 iwl-next] idpf: refactor virtchnl messages
From: Alan Brady Date: Mon, 29 Jan 2024 16:59:16 -0800 > The motivation for this series has two primary goals. We want to enable > support of multiple simultaneous messages and make the channel more > robust. The way it works right now, the driver can only send and receive > a single message at a time and if something goes really wrong, it can > lead to data corruption and strange bugs. Have you tested v3? I have this on my system (net-next + your series), no other patches applied: > [alobakin@GK3153-KR1-CYP-38282-U39-ETH1 ~]$ sudo modprobe idpf > [ 89.785966] idpf :83:00.0: Device HW Reset initiated > [alobakin@GK3153-KR1-CYP-38282-U39-ETH1 ~]$ [ 90.241658] BUG: unable to > handle page fault for address: ff8e1df48200 > [ 90.241704] #PF: supervisor write access in kernel mode > [ 90.241728] #PF: error_code(0x0002) - not-present page > [ 90.241751] PGD 107ffc8067 P4D 107ffc7067 PUD 207fdc8067 PMD 0 > [ 90.241782] Oops: 0002 [#1] PREEMPT SMP NOPTI > [ 90.241805] CPU: 32 PID: 847 Comm: kworker/32:1 Kdump: loaded Not tainted > 6.8.0-rc1-libeth+ #1 > [ 90.241841] Hardware name: Intel Corporation M50CYP2SBSTD/M50CYP2SBSTD, > BIOS SE5C620.86B.01.01.0008.2305172341 05/17/2023 > [ 90.241879] Workqueue: idpf-:83:00.0-vc_ev idpf_vc_event_task [idpf] > [ 90.241932] RIP: 0010:__free_pages_ok+0x338/0x4f0 > [ 90.241962] Code: e6 06 45 31 e4 41 bd 40 00 00 00 45 85 ff 74 13 4b 8d 34 > 28 4c 89 c7 e8 36 97 00 00 8b 74 24 04 41 01 c4 66 90 4c 8b 44 24 08 <43> 81 > 24 28 00 00 80 c0 49 83 c5 40 4d 39 ee 75 d0 e9 7c fd ff ff > [ 90.242027] RSP: 0018:ff3f281b098d7b78 EFLAGS: 00010246 > [ 90.242053] RAX: 0010 RBX: ff8e1df4 RCX: > 0034 > [ 90.242084] RDX: 0d80 RSI: 0034 RDI: > ff8e1df481d980c0 > [ 90.242115] RBP: R08: ff8e1df481d980c0 R09: > > [ 90.242145] R10: ff25062537f9fe00 R11: 0020 R12: > > [ 90.242174] R13: 00267f40 R14: 0400 R15: > > [ 90.242206] FS: () GS:ff2506253ec0() > knlGS: > [ 90.242240] CS: 0010 DS: ES: CR0: 80050033 > [ 90.242266] CR2: ff8e1df48200 CR3: 00207d420006 CR4: > 00771ef0 > [ 90.242297] DR0: DR1: DR2: > > [ 90.242327] DR3: DR6: fffe0ff0 DR7: > 0400 > [ 90.242357] PKRU: 5554 > [ 90.242378] Call Trace: > [ 90.242393] > [ 90.242410] ? __die_body+0x68/0xb0 > [ 90.242437] ? page_fault_oops+0x3a6/0x400 > [ 90.242467] ? exc_page_fault+0xb2/0x1b0 > [ 90.242496] ? asm_exc_page_fault+0x26/0x30 > [ 90.242527] ? __free_pages_ok+0x338/0x4f0 > [ 90.242554] idpf_mb_clean+0xc1/0x110 [idpf] > [ 90.242600] idpf_send_mb_msg+0x50/0x1b0 [idpf] > [ 90.242643] idpf_vc_xn_exec+0x189/0x350 [idpf] > [ 90.242688] idpf_vc_core_init+0x32c/0x6d0 [idpf] > [ 90.242735] idpf_vc_event_task+0x2da/0x390 [idpf] > [ 90.242779] process_scheduled_works+0x251/0x460 > [ 90.242807] worker_thread+0x21c/0x2d0 > [ 90.242830] ? __pfx_worker_thread+0x10/0x10 > [ 90.242855] kthread+0xe8/0x110 > [ 90.242878] ? __pfx_kthread+0x10/0x10 > [ 90.242902] ret_from_fork+0x37/0x50 > [ 90.242925] ? __pfx_kthread+0x10/0x10 > [ 90.243802] ret_from_fork_asm+0x1b/0x30 > [ 90.244598] > [ 90.245361] Modules linked in: idpf libeth rpcrdma rdma_cm ib_cm iw_cm > ib_core qrtr rfkill intel_rapl_msr intel_rapl_common intel_uncore_frequency > intel_uncore_frequency_common i10nm_edac nfit libnvdimm x86_pkg_temp_thermal > intel_powerclamp coretemp kvm_intel binfmt_misc vfat fat kvm irqbypass rapl > ipmi_ssif iTCO_wdt intel_cstate intel_pmc_bxt iTCO_vendor_support dax_hmem > cxl_acpi nfsd ioatdma intel_uncore mei_me isst_if_mmio cxl_core i2c_i801 > isst_if_mbox_pci mei acpi_ipmi pcspkr intel_vsec isst_if_common i2c_smbus > joydev dca ipmi_si intel_pch_thermal ipmi_devintf auth_rpcgss ipmi_msghandler > acpi_power_meter acpi_pad nfs_acl lockd sunrpc loop grace zram xfs > crct10dif_pclmul crc32_pclmul crc32c_intel polyval_clmulni polyval_generic > ghash_clmulni_intel nvme bnxt_en sha512_ssse3 ast nvme_core sha256_ssse3 > sha1_ssse3 i2c_algo_bit wmi scsi_dh_rdac scsi_dh_emc scsi_dh_alua ip6_tables > ip_tables dm_multipath fuse > [ 90.252381] CR2: ff8e1df48200 > [ 90.253263] ---[ end trace ]--- > [ 90.314201] pstore: backend (erst) writing error (-28) > [ 90.314686] RIP: 0010:__free_pages_ok+0x338/0x4f0 > [ 90.314970] Code: e6 06 45 31 e4 41 bd 40 00 00 00 45 85 ff 74 13 4b 8d 34 > 28 4c 89 c7 e8 36 97 00 00 8b 74 24 04 41 01 c4 66 90 4c 8b 44 24 08 <43> 81 > 24 28 00 00 80 c0 49 83 c5 40 4d 39 ee 75 d0 e9 7c fd ff ff > [ 90.315511] RSP: 0018:ff3f281b098d7b78 EFLAGS: 00010246 > [ 90.315778] RAX: 0010 RBX: ff8e1df4 RCX: > 0034 > [ 90.3160
Re: [Intel-wired-lan] [PATCH net-next v6] ethtool: ice: Support for RSS settings to GTP from ethtool
On Wed, 31 Jan 2024 13:46:22 + Takeru Hayasaka wrote: > .../device_drivers/ethernet/intel/ice.rst | 21 - > drivers/net/ethernet/intel/ice/ice_ethtool.c | 82 +++ > drivers/net/ethernet/intel/ice/ice_flow.h | 31 +-- > drivers/net/ethernet/intel/ice/ice_lib.c | 37 + > include/uapi/linux/ethtool.h | 48 +++ Could you split the uAPI changes and the driver changes to two separate commits? You should post them as a patch series, but combining them into a single commit makes the uAPI addition to easy to miss. -- pw-bot: cr
[Intel-wired-lan] [PATCH iwl-net] ice: virtchnl: stop pretending to support RSS over AQ or registers
The E800 series hardware uses the same iAVF driver as older devices,
including the virtchnl negotiation scheme.
This negotiation scheme includes a mechanism to determine what type of RSS
should be supported, including RSS over PF virtchnl messages, RSS over
firmware AdminQ messages, and RSS via direct register access.
The PF driver will always prefer VIRTCHNL_VF_OFFLOAD_RSS_PF if its
supported by the VF driver. However, if an older VF driver is loaded, it
may request only VIRTCHNL_VF_OFFLOAD_RSS_REG or VIRTCHNL_VF_OFFLOAD_RSS_AQ.
The ice driver happily agrees to support these methods. Unfortunately, the
underlying hardware does not support these mechanisms. The E800 series VFs
don't have the appropriate registers for RSS_REG. The mailbox queue used by
VFs for VF to PF communication blocks messages which do not have the
VF-to-PF opcode.
Stop lying to the VF that it could support RSS over AdminQ or registers, as
these interfaces do not work when the hardware is operating on an E800
series device.
In practice this is unlikely to be hit by any normal user. The iAVF driver
has supported RSS over PF virtchnl commands since 2016, and always defaults
to using RSS_PF if possible.
In principle, nothing actually stops the existing VF from attempting to
access the registers or send an AQ command. However a properly coded VF
will check the capability flags and will report a more useful error if it
detects a case where the driver does not support the RSS offloads that it
does.
Fixes: 1071a8358a28 ("ice: Implement virtchnl commands for AVF support")
Signed-off-by: Jacob Keller
Reviewed-by: Alan Brady
---
drivers/net/ethernet/intel/ice/ice_virtchnl.c | 9 +
drivers/net/ethernet/intel/ice/ice_virtchnl_allowlist.c | 2 --
2 files changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_virtchnl.c
b/drivers/net/ethernet/intel/ice/ice_virtchnl.c
index c925813ec9ca..6f2328a049bf 100644
--- a/drivers/net/ethernet/intel/ice/ice_virtchnl.c
+++ b/drivers/net/ethernet/intel/ice/ice_virtchnl.c
@@ -440,7 +440,6 @@ static int ice_vc_get_vf_res_msg(struct ice_vf *vf, u8 *msg)
vf->driver_caps = *(u32 *)msg;
else
vf->driver_caps = VIRTCHNL_VF_OFFLOAD_L2 |
- VIRTCHNL_VF_OFFLOAD_RSS_REG |
VIRTCHNL_VF_OFFLOAD_VLAN;
vfres->vf_cap_flags = VIRTCHNL_VF_OFFLOAD_L2;
@@ -453,14 +452,8 @@ static int ice_vc_get_vf_res_msg(struct ice_vf *vf, u8
*msg)
vfres->vf_cap_flags |= ice_vc_get_vlan_caps(hw, vf, vsi,
vf->driver_caps);
- if (vf->driver_caps & VIRTCHNL_VF_OFFLOAD_RSS_PF) {
+ if (vf->driver_caps & VIRTCHNL_VF_OFFLOAD_RSS_PF)
vfres->vf_cap_flags |= VIRTCHNL_VF_OFFLOAD_RSS_PF;
- } else {
- if (vf->driver_caps & VIRTCHNL_VF_OFFLOAD_RSS_AQ)
- vfres->vf_cap_flags |= VIRTCHNL_VF_OFFLOAD_RSS_AQ;
- else
- vfres->vf_cap_flags |= VIRTCHNL_VF_OFFLOAD_RSS_REG;
- }
if (vf->driver_caps & VIRTCHNL_VF_OFFLOAD_RX_FLEX_DESC)
vfres->vf_cap_flags |= VIRTCHNL_VF_OFFLOAD_RX_FLEX_DESC;
diff --git a/drivers/net/ethernet/intel/ice/ice_virtchnl_allowlist.c
b/drivers/net/ethernet/intel/ice/ice_virtchnl_allowlist.c
index 5e19d48a05b4..d796dbd2a440 100644
--- a/drivers/net/ethernet/intel/ice/ice_virtchnl_allowlist.c
+++ b/drivers/net/ethernet/intel/ice/ice_virtchnl_allowlist.c
@@ -13,8 +13,6 @@
* - opcodes needed by VF when caps are activated
*
* Caps that don't use new opcodes (no opcodes should be allowed):
- * - VIRTCHNL_VF_OFFLOAD_RSS_AQ
- * - VIRTCHNL_VF_OFFLOAD_RSS_REG
* - VIRTCHNL_VF_OFFLOAD_WB_ON_ITR
* - VIRTCHNL_VF_OFFLOAD_CRC
* - VIRTCHNL_VF_OFFLOAD_RX_POLLING
base-commit: d0005e76b73b095138cee9d662831761ffde84a8
--
2.41.0
Re: [Intel-wired-lan] [PATCH v3 0/7 iwl-next] idpf: refactor virtchnl messages
On 1/31/2024 10:33 AM, Alexander Lobakin wrote: From: Alan Brady Date: Mon, 29 Jan 2024 16:59:16 -0800 The motivation for this series has two primary goals. We want to enable support of multiple simultaneous messages and make the channel more robust. The way it works right now, the driver can only send and receive a single message at a time and if something goes really wrong, it can lead to data corruption and strange bugs. Have you tested v3? I have this on my system (net-next + your series), no other patches applied: Mea culpa I have made a grave error. We did test the vast majority of change and it was all fine. At last minute I noticed it looked like we could clean up idpf_send_mb_msg as well. I had confidence in the other changes weren't a problem so this seemed innocent to me. I was very wrong. There's some complications here with how idpf_mb_clean works that I think need to be worked out separately before we can do this change to idpf_send_mb_msg. I would like to revert the change to idpf_send_mb_msg I did in v3 and instead investigate it further in a follow up series that attempts to address all cases where automatic variables would be a good idea. Apologies and thanks. -Alan [...] Thanks, Olek
Re: [Intel-wired-lan] [PATCH net-next v6] ethtool: ice: Support for RSS settings to GTP from ethtool
Hi Jakub-san Thank you for your review. I apologize for the delay in resubmitting the patch. > Could you split the uAPI changes and the driver changes to two separate > commits? You should post them as a patch series, but combining them > into a single commit makes the uAPI addition to easy to miss. Understood. I will split the patches and submit them separately in v7. Thanks Takeru 2024年2月1日(木) 6:13 Jakub Kicinski : > > On Wed, 31 Jan 2024 13:46:22 + Takeru Hayasaka wrote: > > .../device_drivers/ethernet/intel/ice.rst | 21 - > > drivers/net/ethernet/intel/ice/ice_ethtool.c | 82 +++ > > drivers/net/ethernet/intel/ice/ice_flow.h | 31 +-- > > drivers/net/ethernet/intel/ice/ice_lib.c | 37 + > > include/uapi/linux/ethtool.h | 48 +++ > > Could you split the uAPI changes and the driver changes to two separate > commits? You should post them as a patch series, but combining them > into a single commit makes the uAPI addition to easy to miss. > -- > pw-bot: cr
[Intel-wired-lan] [PATCH net-next v6 1/2] ethtool: Add GTP RSS hash options to ethtool.h
This is a patch that enables RSS functionality for GTP packets using ethtool. A user can include TEID and make RSS work for GTP-U over IPv4 by doing the following:`ethtool -N ens3 rx-flow-hash gtpu4 sde` In addition to gtpu(4|6), we now support gtpc(4|6),gtpc(4|6)t,gtpu(4|6)e, gtpu(4|6)u, and gtpu(4|6)d. gtpc(4|6): Used for GTP-C in IPv4 and IPv6, where the GTP header format does not include a TEID. gtpc(4|6)t: Used for GTP-C in IPv4 and IPv6, with a GTP header format that includes a TEID. gtpu(4|6): Used for GTP-U in both IPv4 and IPv6 scenarios. gtpu(4|6)e: Used for GTP-U with extended headers in both IPv4 and IPv6. gtpu(4|6)u: Used when the PSC (PDU session container) in the GTP-U extended header includes Uplink, applicable to both IPv4 and IPv6. gtpu(4|6)d: Used when the PSC in the GTP-U extended header includes Downlink, for both IPv4 and IPv6. GTP generates a flow that includes an ID called TEID to identify the tunnel. This tunnel is created for each UE (User Equipment).By performing RSS based on this flow, it is possible to apply RSS for each communication unit from the UE. Without this, RSS would only be effective within the range of IP addresses. For instance, the PGW can only perform RSS within the IP range of the SGW. Problematic from a load distribution perspective, especially if there's a bias in the terminals connected to a particular base station.This case can be solved by using this patch. Signed-off-by: Takeru Hayasaka --- v2->v3: Based on Harald-san's review, I added documentation and comments to ethtool.h and ice.rst. v3->v4: Based on Marcin-san's review, I added the missing code for GTPC and GTPC_TEID, and revised the documentation and comments. v4->v5: Based on Marcin-san's review, I fixed rename and wrong code regarding GTPC v5->v6: Based on Marcin-san's review, Undoing the addition of unnecessary blank lines.Minor fixes. v6->v7 Based on Jakub-san's review, Split the patch. include/uapi/linux/ethtool.h | 48 1 file changed, 48 insertions(+) diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h index 06ef6b78b7de..11fc18988bc2 100644 --- a/include/uapi/linux/ethtool.h +++ b/include/uapi/linux/ethtool.h @@ -2023,6 +2023,53 @@ static inline int ethtool_validate_duplex(__u8 duplex) #defineIPV4_FLOW 0x10/* hash only */ #defineIPV6_FLOW 0x11/* hash only */ #defineETHER_FLOW 0x12/* spec only (ether_spec) */ + +/* Used for GTP-U IPv4 and IPv6. + * The format of GTP packets only includes + * elements such as TEID and GTP version. + * It is primarily intended for data communication of the UE. + */ +#define GTPU_V4_FLOW 0x13 /* hash only */ +#define GTPU_V6_FLOW 0x14 /* hash only */ + +/* Use for GTP-C IPv4 and v6. + * The format of these GTP packets does not include TEID. + * Primarily expected to be used for communication + * to create sessions for UE data communication, + * commonly referred to as CSR (Create Session Request). + */ +#define GTPC_V4_FLOW 0x15 /* hash only */ +#define GTPC_V6_FLOW 0x16 /* hash only */ + +/* Use for GTP-C IPv4 and v6. + * Unlike GTPC_V4_FLOW, the format of these GTP packets includes TEID. + * After session creation, it becomes this packet. + * This is mainly used for requests to realize UE handover. + */ +#define GTPC_TEID_V4_FLOW 0x17 /* hash only */ +#define GTPC_TEID_V6_FLOW 0x18 /* hash only */ + +/* Use for GTP-U and extended headers for the PSC (PDU Session Container). + * The format of these GTP packets includes TEID and QFI. + * In 5G communication using UPF (User Plane Function), + * data communication with this extended header is performed. + */ +#define GTPU_EH_V4_FLOW 0x19 /* hash only */ +#define GTPU_EH_V6_FLOW 0x1a /* hash only */ + +/* Use for GTP-U IPv4 and v6 PSC (PDU Session Container) extended headers. + * This differs from GTPU_EH_V(4|6)_FLOW in that it is distinguished by + * UL/DL included in the PSC. + * There are differences in the data included based on Downlink/Uplink, + * and can be used to distinguish packets. + * The functions described so far are useful when you want to + * handle communication from the mobile network in UPF, PGW, etc. + */ +#define GTPU_UL_V4_FLOW 0x1b /* hash only */ +#define GTPU_UL_V6_FLOW 0x1c /* hash only */ +#define GTPU_DL_V4_FLOW 0x1d /* hash only */ +#define GTPU_DL_V6_FLOW 0x1e /* hash only */ + /* Flag to enable additional fields in struct ethtool_rx_flow_spec */ #defineFLOW_EXT0x8000 #defineFLOW_MAC_EXT0x4000 @@ -2037,6 +2084,7 @@ static inline int ethtool_validate_duplex(__u8 duplex) #defineRXH_IP_DST (1 << 5) #defineRXH_L4_B_0_1(1 << 6) /* src port in case of TCP/UDP/SCTP */ #defineRXH_L4_B_2_3(1 << 7) /* dst port in case of TCP/UDP/SCTP */ +#defineRXH_GTP_TEID(1 << 8) /* teid in case of GTP */ #defineRXH_DISCARD (1 << 31) #defineRX_CLS
[Intel-wired-lan] [PATCH net-next v6 2/2] ice: Implement RSS settings for GTP using ethtool
Following the addition of new GTP RSS hash options to ethtool.h, this patch implements the corresponding RSS settings for GTP packets in the Intel ice driver. It enables users to configure RSS for GTP-U and GTP-C traffic over IPv4 and IPv6, utilizing the newly defined hash options. The implementation covers the handling of gtpu(4|6), gtpc(4|6), gtpc(4|6)t, gtpu(4|6)e, gtpu(4|6)u, and gtpu(4|6)d traffic, providing enhanced load distribution for GTP traffic across multiple processing units. Signed-off-by: Takeru Hayasaka --- .../device_drivers/ethernet/intel/ice.rst | 21 - drivers/net/ethernet/intel/ice/ice_ethtool.c | 82 +++ drivers/net/ethernet/intel/ice/ice_flow.h | 31 +-- drivers/net/ethernet/intel/ice/ice_lib.c | 37 + 4 files changed, 162 insertions(+), 9 deletions(-) diff --git a/Documentation/networking/device_drivers/ethernet/intel/ice.rst b/Documentation/networking/device_drivers/ethernet/intel/ice.rst index 5038e54586af..934752f675ba 100644 --- a/Documentation/networking/device_drivers/ethernet/intel/ice.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/ice.rst @@ -368,15 +368,28 @@ more options for Receive Side Scaling (RSS) hash byte configuration. # ethtool -N rx-flow-hash Where is: -tcp4 signifying TCP over IPv4 -udp4 signifying UDP over IPv4 -tcp6 signifying TCP over IPv6 -udp6 signifying UDP over IPv6 +tcp4signifying TCP over IPv4 +udp4signifying UDP over IPv4 +gtpc4 signifying GTP-C over IPv4 +gtpc4t signifying GTP-C (include TEID) over IPv4 +gtpu4 signifying GTP-U over IPV4 +gtpu4e signifying GTP-U and Extension Header over IPV4 +gtpu4u signifying GTP-U PSC Uplink over IPV4 +gtpu4d signifying GTP-U PSC Downlink over IPV4 +tcp6signifying TCP over IPv6 +udp6signifying UDP over IPv6 +gtpc6 signifying GTP-C over IPv6 +gtpc6t signifying GTP-C (include TEID) over IPv6 +gtpu6 signifying GTP-U over IPV6 +gtpu6e signifying GTP-U and Extension Header over IPV6 +gtpu6u signifying GTP-U PSC Uplink over IPV6 +gtpu6d signifying GTP-U PSC Downlink over IPV6 And is one or more of: s Hash on the IP source address of the Rx packet. d Hash on the IP destination address of the Rx packet. f Hash on bytes 0 and 1 of the Layer 4 header of the Rx packet. n Hash on bytes 2 and 3 of the Layer 4 header of the Rx packet. +e Hash on GTP Packet on TEID (4bytes) of the Rx packet. Accelerated Receive Flow Steering (aRFS) diff --git a/drivers/net/ethernet/intel/ice/ice_ethtool.c b/drivers/net/ethernet/intel/ice/ice_ethtool.c index a19b06f18e40..d0e05032f464 100644 --- a/drivers/net/ethernet/intel/ice/ice_ethtool.c +++ b/drivers/net/ethernet/intel/ice/ice_ethtool.c @@ -2486,6 +2486,24 @@ static u32 ice_parse_hdrs(struct ethtool_rxnfc *nfc) case SCTP_V4_FLOW: hdrs |= ICE_FLOW_SEG_HDR_SCTP | ICE_FLOW_SEG_HDR_IPV4; break; + case GTPU_V4_FLOW: + hdrs |= ICE_FLOW_SEG_HDR_GTPU_IP | ICE_FLOW_SEG_HDR_IPV4; + break; + case GTPC_V4_FLOW: + hdrs |= ICE_FLOW_SEG_HDR_GTPC | ICE_FLOW_SEG_HDR_IPV4; + break; + case GTPC_TEID_V4_FLOW: + hdrs |= ICE_FLOW_SEG_HDR_GTPC_TEID | ICE_FLOW_SEG_HDR_IPV4; + break; + case GTPU_EH_V4_FLOW: + hdrs |= ICE_FLOW_SEG_HDR_GTPU_EH | ICE_FLOW_SEG_HDR_IPV4; + break; + case GTPU_UL_V4_FLOW: + hdrs |= ICE_FLOW_SEG_HDR_GTPU_UP | ICE_FLOW_SEG_HDR_IPV4; + break; + case GTPU_DL_V4_FLOW: + hdrs |= ICE_FLOW_SEG_HDR_GTPU_DWN | ICE_FLOW_SEG_HDR_IPV4; + break; case TCP_V6_FLOW: hdrs |= ICE_FLOW_SEG_HDR_TCP | ICE_FLOW_SEG_HDR_IPV6; break; @@ -2495,6 +2513,24 @@ static u32 ice_parse_hdrs(struct ethtool_rxnfc *nfc) case SCTP_V6_FLOW: hdrs |= ICE_FLOW_SEG_HDR_SCTP | ICE_FLOW_SEG_HDR_IPV6; break; + case GTPU_V6_FLOW: + hdrs |= ICE_FLOW_SEG_HDR_GTPU_IP | ICE_FLOW_SEG_HDR_IPV6; + break; + case GTPC_V6_FLOW: + hdrs |= ICE_FLOW_SEG_HDR_GTPC | ICE_FLOW_SEG_HDR_IPV6; + break; + case GTPC_TEID_V6_FLOW: + hdrs |= ICE_FLOW_SEG_HDR_GTPC_TEID | ICE_FLOW_SEG_HDR_IPV6; + break; + case GTPU_EH_V6_FLOW: + hdrs |= ICE_FLOW_SEG_HDR_GTPU_EH | ICE_FLOW_SEG_HDR_IPV6; + break; + case GTPU_UL_V6_FLOW: + hdrs |= ICE_FLOW_SEG_HDR_GTPU_UP | ICE_FLOW_SEG_HDR_IPV6; + break; + case GTPU_DL_V6_FLOW: + hdrs |= ICE_FLOW_SEG_HDR_GTPU_DWN | ICE_FLOW_SEG_HDR_IPV6; + break; default: break; } @@ -2518,6 +2554,12 @@ static u64 ice_parse_hash_flds(struct ethtool_rxn
[Intel-wired-lan] [PATCH net-next v7 1/2] ethtool: Add GTP RSS hash options to ethtool.h
This is a patch that enables RSS functionality for GTP packets using ethtool. A user can include TEID and make RSS work for GTP-U over IPv4 by doing the following:`ethtool -N ens3 rx-flow-hash gtpu4 sde` In addition to gtpu(4|6), we now support gtpc(4|6),gtpc(4|6)t,gtpu(4|6)e, gtpu(4|6)u, and gtpu(4|6)d. gtpc(4|6): Used for GTP-C in IPv4 and IPv6, where the GTP header format does not include a TEID. gtpc(4|6)t: Used for GTP-C in IPv4 and IPv6, with a GTP header format that includes a TEID. gtpu(4|6): Used for GTP-U in both IPv4 and IPv6 scenarios. gtpu(4|6)e: Used for GTP-U with extended headers in both IPv4 and IPv6. gtpu(4|6)u: Used when the PSC (PDU session container) in the GTP-U extended header includes Uplink, applicable to both IPv4 and IPv6. gtpu(4|6)d: Used when the PSC in the GTP-U extended header includes Downlink, for both IPv4 and IPv6. GTP generates a flow that includes an ID called TEID to identify the tunnel. This tunnel is created for each UE (User Equipment).By performing RSS based on this flow, it is possible to apply RSS for each communication unit from the UE. Without this, RSS would only be effective within the range of IP addresses. For instance, the PGW can only perform RSS within the IP range of the SGW. Problematic from a load distribution perspective, especially if there's a bias in the terminals connected to a particular base station.This case can be solved by using this patch. Signed-off-by: Takeru Hayasaka --- v2->v3: Based on Harald-san's review, I added documentation and comments to ethtool.h and ice.rst. v3->v4: Based on Marcin-san's review, I added the missing code for GTPC and GTPC_TEID, and revised the documentation and comments. v4->v5: Based on Marcin-san's review, I fixed rename and wrong code regarding GTPC v5->v6: Based on Marcin-san's review, Undoing the addition of unnecessary blank lines.Minor fixes. v6->v7 Based on Jakub-san's review, Split the patch. include/uapi/linux/ethtool.h | 48 1 file changed, 48 insertions(+) diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h index 06ef6b78b7de..11fc18988bc2 100644 --- a/include/uapi/linux/ethtool.h +++ b/include/uapi/linux/ethtool.h @@ -2023,6 +2023,53 @@ static inline int ethtool_validate_duplex(__u8 duplex) #defineIPV4_FLOW 0x10/* hash only */ #defineIPV6_FLOW 0x11/* hash only */ #defineETHER_FLOW 0x12/* spec only (ether_spec) */ + +/* Used for GTP-U IPv4 and IPv6. + * The format of GTP packets only includes + * elements such as TEID and GTP version. + * It is primarily intended for data communication of the UE. + */ +#define GTPU_V4_FLOW 0x13 /* hash only */ +#define GTPU_V6_FLOW 0x14 /* hash only */ + +/* Use for GTP-C IPv4 and v6. + * The format of these GTP packets does not include TEID. + * Primarily expected to be used for communication + * to create sessions for UE data communication, + * commonly referred to as CSR (Create Session Request). + */ +#define GTPC_V4_FLOW 0x15 /* hash only */ +#define GTPC_V6_FLOW 0x16 /* hash only */ + +/* Use for GTP-C IPv4 and v6. + * Unlike GTPC_V4_FLOW, the format of these GTP packets includes TEID. + * After session creation, it becomes this packet. + * This is mainly used for requests to realize UE handover. + */ +#define GTPC_TEID_V4_FLOW 0x17 /* hash only */ +#define GTPC_TEID_V6_FLOW 0x18 /* hash only */ + +/* Use for GTP-U and extended headers for the PSC (PDU Session Container). + * The format of these GTP packets includes TEID and QFI. + * In 5G communication using UPF (User Plane Function), + * data communication with this extended header is performed. + */ +#define GTPU_EH_V4_FLOW 0x19 /* hash only */ +#define GTPU_EH_V6_FLOW 0x1a /* hash only */ + +/* Use for GTP-U IPv4 and v6 PSC (PDU Session Container) extended headers. + * This differs from GTPU_EH_V(4|6)_FLOW in that it is distinguished by + * UL/DL included in the PSC. + * There are differences in the data included based on Downlink/Uplink, + * and can be used to distinguish packets. + * The functions described so far are useful when you want to + * handle communication from the mobile network in UPF, PGW, etc. + */ +#define GTPU_UL_V4_FLOW 0x1b /* hash only */ +#define GTPU_UL_V6_FLOW 0x1c /* hash only */ +#define GTPU_DL_V4_FLOW 0x1d /* hash only */ +#define GTPU_DL_V6_FLOW 0x1e /* hash only */ + /* Flag to enable additional fields in struct ethtool_rx_flow_spec */ #defineFLOW_EXT0x8000 #defineFLOW_MAC_EXT0x4000 @@ -2037,6 +2084,7 @@ static inline int ethtool_validate_duplex(__u8 duplex) #defineRXH_IP_DST (1 << 5) #defineRXH_L4_B_0_1(1 << 6) /* src port in case of TCP/UDP/SCTP */ #defineRXH_L4_B_2_3(1 << 7) /* dst port in case of TCP/UDP/SCTP */ +#defineRXH_GTP_TEID(1 << 8) /* teid in case of GTP */ #defineRXH_DISCARD (1 << 31) #defineRX_CLS_F
[Intel-wired-lan] [PATCH net-next v7 2/2] ice: Implement RSS settings for GTP using ethtool
Following the addition of new GTP RSS hash options to ethtool.h, this patch implements the corresponding RSS settings for GTP packets in the Intel ice driver. It enables users to configure RSS for GTP-U and GTP-C traffic over IPv4 and IPv6, utilizing the newly defined hash options. The implementation covers the handling of gtpu(4|6), gtpc(4|6), gtpc(4|6)t, gtpu(4|6)e, gtpu(4|6)u, and gtpu(4|6)d traffic, providing enhanced load distribution for GTP traffic across multiple processing units. Signed-off-by: Takeru Hayasaka --- .../device_drivers/ethernet/intel/ice.rst | 21 - drivers/net/ethernet/intel/ice/ice_ethtool.c | 82 +++ drivers/net/ethernet/intel/ice/ice_flow.h | 31 +-- drivers/net/ethernet/intel/ice/ice_lib.c | 37 + 4 files changed, 162 insertions(+), 9 deletions(-) diff --git a/Documentation/networking/device_drivers/ethernet/intel/ice.rst b/Documentation/networking/device_drivers/ethernet/intel/ice.rst index 5038e54586af..934752f675ba 100644 --- a/Documentation/networking/device_drivers/ethernet/intel/ice.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/ice.rst @@ -368,15 +368,28 @@ more options for Receive Side Scaling (RSS) hash byte configuration. # ethtool -N rx-flow-hash Where is: -tcp4 signifying TCP over IPv4 -udp4 signifying UDP over IPv4 -tcp6 signifying TCP over IPv6 -udp6 signifying UDP over IPv6 +tcp4signifying TCP over IPv4 +udp4signifying UDP over IPv4 +gtpc4 signifying GTP-C over IPv4 +gtpc4t signifying GTP-C (include TEID) over IPv4 +gtpu4 signifying GTP-U over IPV4 +gtpu4e signifying GTP-U and Extension Header over IPV4 +gtpu4u signifying GTP-U PSC Uplink over IPV4 +gtpu4d signifying GTP-U PSC Downlink over IPV4 +tcp6signifying TCP over IPv6 +udp6signifying UDP over IPv6 +gtpc6 signifying GTP-C over IPv6 +gtpc6t signifying GTP-C (include TEID) over IPv6 +gtpu6 signifying GTP-U over IPV6 +gtpu6e signifying GTP-U and Extension Header over IPV6 +gtpu6u signifying GTP-U PSC Uplink over IPV6 +gtpu6d signifying GTP-U PSC Downlink over IPV6 And is one or more of: s Hash on the IP source address of the Rx packet. d Hash on the IP destination address of the Rx packet. f Hash on bytes 0 and 1 of the Layer 4 header of the Rx packet. n Hash on bytes 2 and 3 of the Layer 4 header of the Rx packet. +e Hash on GTP Packet on TEID (4bytes) of the Rx packet. Accelerated Receive Flow Steering (aRFS) diff --git a/drivers/net/ethernet/intel/ice/ice_ethtool.c b/drivers/net/ethernet/intel/ice/ice_ethtool.c index a19b06f18e40..d0e05032f464 100644 --- a/drivers/net/ethernet/intel/ice/ice_ethtool.c +++ b/drivers/net/ethernet/intel/ice/ice_ethtool.c @@ -2486,6 +2486,24 @@ static u32 ice_parse_hdrs(struct ethtool_rxnfc *nfc) case SCTP_V4_FLOW: hdrs |= ICE_FLOW_SEG_HDR_SCTP | ICE_FLOW_SEG_HDR_IPV4; break; + case GTPU_V4_FLOW: + hdrs |= ICE_FLOW_SEG_HDR_GTPU_IP | ICE_FLOW_SEG_HDR_IPV4; + break; + case GTPC_V4_FLOW: + hdrs |= ICE_FLOW_SEG_HDR_GTPC | ICE_FLOW_SEG_HDR_IPV4; + break; + case GTPC_TEID_V4_FLOW: + hdrs |= ICE_FLOW_SEG_HDR_GTPC_TEID | ICE_FLOW_SEG_HDR_IPV4; + break; + case GTPU_EH_V4_FLOW: + hdrs |= ICE_FLOW_SEG_HDR_GTPU_EH | ICE_FLOW_SEG_HDR_IPV4; + break; + case GTPU_UL_V4_FLOW: + hdrs |= ICE_FLOW_SEG_HDR_GTPU_UP | ICE_FLOW_SEG_HDR_IPV4; + break; + case GTPU_DL_V4_FLOW: + hdrs |= ICE_FLOW_SEG_HDR_GTPU_DWN | ICE_FLOW_SEG_HDR_IPV4; + break; case TCP_V6_FLOW: hdrs |= ICE_FLOW_SEG_HDR_TCP | ICE_FLOW_SEG_HDR_IPV6; break; @@ -2495,6 +2513,24 @@ static u32 ice_parse_hdrs(struct ethtool_rxnfc *nfc) case SCTP_V6_FLOW: hdrs |= ICE_FLOW_SEG_HDR_SCTP | ICE_FLOW_SEG_HDR_IPV6; break; + case GTPU_V6_FLOW: + hdrs |= ICE_FLOW_SEG_HDR_GTPU_IP | ICE_FLOW_SEG_HDR_IPV6; + break; + case GTPC_V6_FLOW: + hdrs |= ICE_FLOW_SEG_HDR_GTPC | ICE_FLOW_SEG_HDR_IPV6; + break; + case GTPC_TEID_V6_FLOW: + hdrs |= ICE_FLOW_SEG_HDR_GTPC_TEID | ICE_FLOW_SEG_HDR_IPV6; + break; + case GTPU_EH_V6_FLOW: + hdrs |= ICE_FLOW_SEG_HDR_GTPU_EH | ICE_FLOW_SEG_HDR_IPV6; + break; + case GTPU_UL_V6_FLOW: + hdrs |= ICE_FLOW_SEG_HDR_GTPU_UP | ICE_FLOW_SEG_HDR_IPV6; + break; + case GTPU_DL_V6_FLOW: + hdrs |= ICE_FLOW_SEG_HDR_GTPU_DWN | ICE_FLOW_SEG_HDR_IPV6; + break; default: break; } @@ -2518,6 +2554,12 @@ static u64 ice_parse_hash_flds(struct ethtool_rxn
Re: [Intel-wired-lan] [PATCH net-next v7 2/2] ice: Implement RSS settings for GTP using ethtool
Hi reviews. I made a mistake in sending the patch without increasing the version, so I will send it again as v7. Thanks Takeru 2024年2月1日(木) 12:33 Takeru Hayasaka : > > Following the addition of new GTP RSS hash options to ethtool.h, this patch > implements the corresponding RSS settings for GTP packets in the Intel ice > driver. It enables users to configure RSS for GTP-U and GTP-C traffic over > IPv4 > and IPv6, utilizing the newly defined hash options. > > The implementation covers the handling of gtpu(4|6), gtpc(4|6), gtpc(4|6)t, > gtpu(4|6)e, gtpu(4|6)u, and gtpu(4|6)d traffic, providing enhanced load > distribution for GTP traffic across multiple processing units. > > Signed-off-by: Takeru Hayasaka > --- > .../device_drivers/ethernet/intel/ice.rst | 21 - > drivers/net/ethernet/intel/ice/ice_ethtool.c | 82 +++ > drivers/net/ethernet/intel/ice/ice_flow.h | 31 +-- > drivers/net/ethernet/intel/ice/ice_lib.c | 37 + > 4 files changed, 162 insertions(+), 9 deletions(-) > > diff --git a/Documentation/networking/device_drivers/ethernet/intel/ice.rst > b/Documentation/networking/device_drivers/ethernet/intel/ice.rst > index 5038e54586af..934752f675ba 100644 > --- a/Documentation/networking/device_drivers/ethernet/intel/ice.rst > +++ b/Documentation/networking/device_drivers/ethernet/intel/ice.rst > @@ -368,15 +368,28 @@ more options for Receive Side Scaling (RSS) hash byte > configuration. ># ethtool -N rx-flow-hash > >Where is: > -tcp4 signifying TCP over IPv4 > -udp4 signifying UDP over IPv4 > -tcp6 signifying TCP over IPv6 > -udp6 signifying UDP over IPv6 > +tcp4signifying TCP over IPv4 > +udp4signifying UDP over IPv4 > +gtpc4 signifying GTP-C over IPv4 > +gtpc4t signifying GTP-C (include TEID) over IPv4 > +gtpu4 signifying GTP-U over IPV4 > +gtpu4e signifying GTP-U and Extension Header over IPV4 > +gtpu4u signifying GTP-U PSC Uplink over IPV4 > +gtpu4d signifying GTP-U PSC Downlink over IPV4 > +tcp6signifying TCP over IPv6 > +udp6signifying UDP over IPv6 > +gtpc6 signifying GTP-C over IPv6 > +gtpc6t signifying GTP-C (include TEID) over IPv6 > +gtpu6 signifying GTP-U over IPV6 > +gtpu6e signifying GTP-U and Extension Header over IPV6 > +gtpu6u signifying GTP-U PSC Uplink over IPV6 > +gtpu6d signifying GTP-U PSC Downlink over IPV6 >And is one or more of: > s Hash on the IP source address of the Rx packet. > d Hash on the IP destination address of the Rx packet. > f Hash on bytes 0 and 1 of the Layer 4 header of the Rx packet. > n Hash on bytes 2 and 3 of the Layer 4 header of the Rx packet. > +e Hash on GTP Packet on TEID (4bytes) of the Rx packet. > > > Accelerated Receive Flow Steering (aRFS) > diff --git a/drivers/net/ethernet/intel/ice/ice_ethtool.c > b/drivers/net/ethernet/intel/ice/ice_ethtool.c > index a19b06f18e40..d0e05032f464 100644 > --- a/drivers/net/ethernet/intel/ice/ice_ethtool.c > +++ b/drivers/net/ethernet/intel/ice/ice_ethtool.c > @@ -2486,6 +2486,24 @@ static u32 ice_parse_hdrs(struct ethtool_rxnfc *nfc) > case SCTP_V4_FLOW: > hdrs |= ICE_FLOW_SEG_HDR_SCTP | ICE_FLOW_SEG_HDR_IPV4; > break; > + case GTPU_V4_FLOW: > + hdrs |= ICE_FLOW_SEG_HDR_GTPU_IP | ICE_FLOW_SEG_HDR_IPV4; > + break; > + case GTPC_V4_FLOW: > + hdrs |= ICE_FLOW_SEG_HDR_GTPC | ICE_FLOW_SEG_HDR_IPV4; > + break; > + case GTPC_TEID_V4_FLOW: > + hdrs |= ICE_FLOW_SEG_HDR_GTPC_TEID | ICE_FLOW_SEG_HDR_IPV4; > + break; > + case GTPU_EH_V4_FLOW: > + hdrs |= ICE_FLOW_SEG_HDR_GTPU_EH | ICE_FLOW_SEG_HDR_IPV4; > + break; > + case GTPU_UL_V4_FLOW: > + hdrs |= ICE_FLOW_SEG_HDR_GTPU_UP | ICE_FLOW_SEG_HDR_IPV4; > + break; > + case GTPU_DL_V4_FLOW: > + hdrs |= ICE_FLOW_SEG_HDR_GTPU_DWN | ICE_FLOW_SEG_HDR_IPV4; > + break; > case TCP_V6_FLOW: > hdrs |= ICE_FLOW_SEG_HDR_TCP | ICE_FLOW_SEG_HDR_IPV6; > break; > @@ -2495,6 +2513,24 @@ static u32 ice_parse_hdrs(struct ethtool_rxnfc *nfc) > case SCTP_V6_FLOW: > hdrs |= ICE_FLOW_SEG_HDR_SCTP | ICE_FLOW_SEG_HDR_IPV6; > break; > + case GTPU_V6_FLOW: > + hdrs |= ICE_FLOW_SEG_HDR_GTPU_IP | ICE_FLOW_SEG_HDR_IPV6; > + break; > + case GTPC_V6_FLOW: > + hdrs |= ICE_FLOW_SEG_HDR_GTPC | ICE_FLOW_SEG_HDR_IPV6; > + break; > + case GTPC_TEID_V6_FLOW: > + hdrs |= ICE_FLOW_SEG_HDR_GTPC_TEID | ICE_FLOW_SEG_HDR_IPV6; > + break; > + case GTPU_EH_V6_FLOW: > + hdrs |= ICE_FLOW_SEG_HDR_GTPU_EH | ICE_FLOW_SEG_HDR_IPV6; > + break; > + c
Re: [Intel-wired-lan] [PATCH] ice: Add get/set hw address for VF representor ports
On Wed, Jan 31, 2024 at 01:00:04PM +0100, Jiri Pirko wrote: > Wed, Jan 31, 2024 at 11:43:44AM CET, michal.swiatkow...@linux.intel.com wrote: > >On Wed, Jan 31, 2024 at 01:38:47PM +0530, karthiksundaravel wrote: > >> Changing the mac address of the VF representor ports are not > >> available via devlink. Add the function handlers to set and get > >> the HW address for the VF representor ports. > >> > >> Signed-off-by: karthiksundaravel > >> --- > >> drivers/net/ethernet/intel/ice/ice_devlink.c | 134 ++- > >> 1 file changed, 132 insertions(+), 2 deletions(-) > >> > >> diff --git a/drivers/net/ethernet/intel/ice/ice_devlink.c > >> b/drivers/net/ethernet/intel/ice/ice_devlink.c > >> index 80dc5445b50d..56d81836c469 100644 > >> --- a/drivers/net/ethernet/intel/ice/ice_devlink.c > >> +++ b/drivers/net/ethernet/intel/ice/ice_devlink.c > >> @@ -9,6 +9,8 @@ > > > >As Jiri already wrote, you are not changing MAC of VF in your code. Try > >to look at ice_set_vf_mac in ice_sriov.c. In current implementation you > >nedd to set new MAC value for VF and reset it. You shouldn't use PF VSI. > > > >Pointer to VF you can get from representor struct (through parent VSI). > > What if it is in a different host? Would you still be able to change the > mac? > In current VF MAC changing implementation yes, because it is done by resetting the VF. After the reset new MAC will be sent via virtchnl. But I think resetting VF may be incorrect here, as it leads to reset also port representor. > > > > >You shouldn't manage the rules during MAC changing, as in switchdev > >slow-path there shouldn't be VF MAC rules. It can be problematic as user > >already can have MAC + sth rule (which also needs to be change). I will > >leave it to user (most probably the MAC change happens before adding any > >rules). > > Rules are on the representor, not the VF, correct? Seems unrelated to > me. > I pointed it out because it was in the code. Rules added on representor points to corresponding VF. My point was that there shouldn't be any changes to rules after changing MAC. > > > > >In few days we will send patchset for subfunction support where the > >subfunction MAC chaning is implementing from devlink API. I will add you > >to the CC. > > > >Thanks for working on it, it is a gap in our solution. > > > >Thanks, > >Michal > >
Re: [Intel-wired-lan] [iwl-next v1 4/8] ice: control default Tx rule in lag
On Mon, Jan 29, 2024 at 10:55:41AM +, Simon Horman wrote:
> On Thu, Jan 25, 2024 at 01:53:10PM +0100, Michal Swiatkowski wrote:
> > Tx rule in switchdev was changed to use PF instead of additional control
> > plane VSI. Because of that during lag we should control it. Control
> > means to add and remove the default Tx rule during lag active/inactive
> > switching.
> >
> > It can be done the same way as default Rx rule.
>
> Hi Michal,
>
> Can I confirm that LAG TX/RX works both before and after this patch?
>
Hi Simon,
This part of LAG code is related to the LAG + switchdev feature (it
isn't chaning LAG core code). Hope that normal LAG also works well. This
is the scenario when you have PF in switchdev, bond created of two PFs
connected to the bridge with representors. Switching between interfaces
from bond needs to add default Rx rule, and after my changes also
default Tx rule.
Do you think I should add this description to commit message?
Thanks,
Michal
> >
> > Reviewed-by: Wojciech Drewek
> > Reviewed-by: Marcin Szycik
> > Signed-off-by: Michal Swiatkowski
> > ---
> > drivers/net/ethernet/intel/ice/ice_lag.c | 39 ++--
> > drivers/net/ethernet/intel/ice/ice_lag.h | 3 +-
> > 2 files changed, 32 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/intel/ice/ice_lag.c
> > b/drivers/net/ethernet/intel/ice/ice_lag.c
>
> ...
>
> > @@ -266,9 +274,22 @@ ice_lag_cfg_dflt_fltr(struct ice_lag *lag, bool add)
> > {
> > u32 act = ICE_SINGLE_ACT_VSI_FORWARDING |
> > ICE_SINGLE_ACT_VALID_BIT | ICE_SINGLE_ACT_LAN_ENABLE;
> > + int err;
> > +
> > + err = ice_lag_cfg_fltr(lag, act, lag->pf_recipe, &lag->pf_rx_rule_id,
> > + ICE_FLTR_RX, add);
> > + if (err)
> > + return err;
> > +
> > + err = ice_lag_cfg_fltr(lag, act, lag->pf_recipe, &lag->pf_tx_rule_id,
> > + ICE_FLTR_TX, add);
> > + if (err) {
> > + ice_lag_cfg_fltr(lag, act, lag->pf_recipe, &lag->pf_rx_rule_id,
> > +ICE_FLTR_RX, !add);
> > + return err;
> > + }
> >
> > - return ice_lag_cfg_fltr(lag, act, lag->pf_recipe,
> > - &lag->pf_rule_id, add);
> > + return 0;
> > }
>
> nit: perhaps this could be more idiomatically written using a
> goto to unwind on error.
>
Thanks, I will rewrite it.
> ...
[Intel-wired-lan] [tnguy-net-queue:main] BUILD SUCCESS c9ec85153fea6873c52ed4f5055c87263f1b54f9
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue.git main branch HEAD: c9ec85153fea6873c52ed4f5055c87263f1b54f9 selftests: net: add missing config for GENEVE elapsed time: 796m configs tested: 169 configs skipped: 4 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: alpha allnoconfig gcc alphaallyesconfig gcc alpha defconfig gcc arc allmodconfig gcc arc allnoconfig gcc arc allyesconfig gcc arc defconfig gcc archsdk_defconfig gcc arc randconfig-001-20240201 gcc arc randconfig-002-20240201 gcc arm allmodconfig gcc arm allnoconfig gcc arm allyesconfig gcc arm defconfig clang arm randconfig-001-20240201 gcc arm randconfig-002-20240201 gcc arm randconfig-003-20240201 gcc arm randconfig-004-20240201 gcc arm sama5_defconfig gcc arm64allmodconfig clang arm64 allnoconfig gcc arm64 defconfig gcc arm64 randconfig-001-20240201 gcc arm64 randconfig-002-20240201 gcc arm64 randconfig-003-20240201 gcc arm64 randconfig-004-20240201 gcc csky allmodconfig gcc csky allnoconfig gcc csky allyesconfig gcc cskydefconfig gcc csky randconfig-001-20240201 gcc csky randconfig-002-20240201 gcc hexagon allmodconfig clang hexagon allnoconfig clang hexagon allyesconfig clang hexagon defconfig clang i386 allmodconfig clang i386 allnoconfig clang i386 allyesconfig clang i386defconfig gcc i386 randconfig-011-20240201 clang i386 randconfig-012-20240201 clang i386 randconfig-013-20240201 clang i386 randconfig-014-20240201 clang i386 randconfig-015-20240201 clang i386 randconfig-016-20240201 clang loongarchallmodconfig gcc loongarch allnoconfig gcc loongarchallyesconfig gcc loongarch defconfig gcc loongarch randconfig-001-20240201 gcc loongarch randconfig-002-20240201 gcc m68k allmodconfig gcc m68k allnoconfig gcc m68k allyesconfig gcc m68kdefconfig gcc m68kmac_defconfig gcc m68kq40_defconfig gcc microblaze allmodconfig gcc microblazeallnoconfig gcc microblaze allyesconfig gcc microblaze defconfig gcc microblaze mmu_defconfig gcc mips allmodconfig gcc mips allnoconfig clang mips allyesconfig gcc mips gcw0_defconfig gcc mipsgpr_defconfig gcc mips loongson3_defconfig gcc nios2 10m50_defconfig gcc nios2allmodconfig gcc nios2 allnoconfig gcc nios2allyesconfig gcc nios2 defconfig gcc nios2 randconfig-001-20240201 gcc nios2 randconfig-002-20240201 gcc openrisc allmodconfig gcc openrisc allnoconfig gcc openrisc allyesconfig gcc openriscdefconfig gcc parisc allmodconfig gcc pariscallnoconfig gcc parisc allyesconfig gcc parisc defconfig gcc pariscgeneric-64bit_defconfig gcc pariscrandconfig-001-202402
Re: [Intel-wired-lan] [PATCH] ice: Add get/set hw address for VF representor ports
Wed, Jan 31, 2024 at 05:15:46PM CET, pmen...@molgen.mpg.de wrote:
>Dear karthiksundaravel,
>
>
>Thank you for your patch.
>
>
>Am 31.01.24 um 09:08 schrieb karthiksundaravel:
>> Changing the mac address of the VF representor ports are not
>
>Do you mean “is not possible”?
>
>> available via devlink. Add the function handlers to set and get
>> the HW address for the VF representor ports.
>
>How did you test this? It’d be great if you documented it.
>
>> Signed-off-by: karthiksundaravel
>
>Is “karthiksundaravel” the official spelling of your name. If not, you can
>change it with
>
>git config --global user.name "Your Name"
>git commit -s --amend --author="Your Name "
>
>> ---
>> drivers/net/ethernet/intel/ice/ice_devlink.c | 134 ++-
>> 1 file changed, 132 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/intel/ice/ice_devlink.c
>> b/drivers/net/ethernet/intel/ice/ice_devlink.c
>> index 80dc5445b50d..56d81836c469 100644
>> --- a/drivers/net/ethernet/intel/ice/ice_devlink.c
>> +++ b/drivers/net/ethernet/intel/ice/ice_devlink.c
>> @@ -9,6 +9,8 @@
>> #include "ice_eswitch.h"
>> #include "ice_fw_update.h"
>> #include "ice_dcb_lib.h"
>> +#include "ice_fltr.h"
>> +#include "ice_tc_lib.h"
>> static int ice_active_port_option = -1;
>> @@ -1576,6 +1578,134 @@ void ice_devlink_destroy_pf_port(struct ice_pf *pf)
>> devlink_port_unregister(&pf->devlink_port);
>> }
>> +/**
>> + * ice_devlink_port_get_vf_mac_address - .port_fn_hw_addr_get devlink
>> handler
>> + * @port: devlink port structure
>> + * @hw_addr: Mac address of the port
>> + * @hw_addr_len: length of mac address
>
>Mac/mac is spelled differently. (Also below.)
>
>> + * @extack: extended netdev ack structure
>> + *
>> + * Callback for the devlink .port_fn_hw_addr_get operation
>> + * Return: zero on success or an error code on failure.
>> + */
>> +
>> +static int ice_devlink_port_get_vf_mac_address(struct devlink_port *port,
>> + u8 *hw_addr, int *hw_addr_len,
>> + struct netlink_ext_ack *extack)
>> +{
>> +struct net_device *netdev = port->type_eth.netdev;
>> +
>> +if (!netdev || !netdev->dev_addr)
>> +return -EADDRNOTAVAIL;
>> +
>> +ether_addr_copy(hw_addr, netdev->dev_addr);
>> +*hw_addr_len = ETH_ALEN;
>> +return 0;
>> +}
>> +
>> +/**
>> + * ice_devlink_port_set_vf_mac_address - .port_fn_hw_addr_set devlink
>> handler
>> + * @port: devlink port structure
>> + * @hw_addr: Mac address of the port
>> + * @hw_addr_len: length of mac address
>> + * @extack: extended netdev ack structure
>> + *
>> + * Callback for the devlink .port_fn_hw_addr_set operation
>> + * Return: zero on success or an error code on failure.
>> + */
>> +static int ice_devlink_port_set_vf_mac_address(struct devlink_port *port,
>> + const u8 *hw_addr,
>> + int hw_addr_len,
>> + struct netlink_ext_ack *extack)
>> +{
>> +struct devlink *devlink = port->devlink;
>> +struct net_device *netdev = port->type_eth.netdev;
>> +struct ice_pf *pf = devlink_priv(devlink);
>> +struct ice_vsi *vsi = *pf->vsi;
>> +struct ice_hw *hw = &pf->hw;
>> +struct device *dev = ice_pf_to_dev(pf);
>> +u8 old_mac[ETH_ALEN];
>> +u8 flags = 0;
>> +const u8 *mac = hw_addr;
>> +int err;
>> +
>> +if (!netdev)
>> +return -EADDRNOTAVAIL;
>> +
>> +if (!is_valid_ether_addr(mac))
>> +return -EADDRNOTAVAIL;
>> +
>> +if (ether_addr_equal(netdev->dev_addr, mac)) {
>> +dev_dbg(dev, "already using mac %pM\n", mac);
>> +return 0;
>> +}
>> +
>> +if (test_bit(ICE_DOWN, pf->state) ||
>> +ice_is_reset_in_progress(pf->state)) {
>> +dev_err(dev, "can't set mac %pM. device not ready\n", mac);
>> +return -EBUSY;
>> +}
>> +
>> +if (ice_chnl_dmac_fltr_cnt(pf)) {
>> +dev_err(dev, "can't set mac %pM. Device has tc-flower filters,
>> delete all of them and try again\n",
>> +mac);
>> +return -EAGAIN;
>> +}
>> +
>> +netif_addr_lock_bh(netdev);
>> +ether_addr_copy(old_mac, netdev->dev_addr);
>> +/* change the netdev's MAC address */
>
>The comment seems redundant.
>
>> +eth_hw_addr_set(netdev, mac);
>> +netif_addr_unlock_bh(netdev);
>> +
>> +/* Clean up old MAC filter. Not an error if old filter doesn't exist */
>> +err = ice_fltr_remove_mac(vsi, old_mac, ICE_FWD_TO_VSI);
>> +if (err && err != -ENOENT) {
>> +err = -EADDRNOTAVAIL;
>> +goto err_update_filters;
>> +}
>> +
>> +/* Add filter for new MAC. If filter exists, return success */
>> +err = ice_fltr_add_mac(vsi, mac, ICE_FWD_TO_VSI);
>> +if (err == -EEXIST) {
>> +/* Although this MAC filter is already present in hardw
