[Intel-wired-lan] [tnguy-next-queue:dev-queue] BUILD SUCCESS d462a76d72369fd26d1a5ab7b66be365bb0dca9e

2023-10-06 Thread kernel test robot
tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue.git dev-queue
branch HEAD: d462a76d72369fd26d1a5ab7b66be365bb0dca9e  intel: fix format 
warnings

elapsed time: 844m

configs tested: 113
configs skipped: 2

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  alldefconfig   gcc  
arc  allmodconfig   gcc  
arc   allnoconfig   gcc  
arc  allyesconfig   gcc  
arc defconfig   gcc  
arc   randconfig-001-20231006   gcc  
arm  allmodconfig   gcc  
arm   allnoconfig   gcc  
arm  allyesconfig   gcc  
arm axm55xx_defconfig   gcc  
arm defconfig   gcc  
arm   randconfig-001-20231006   gcc  
arm   u8500_defconfig   gcc  
arm64allmodconfig   gcc  
arm64 allnoconfig   gcc  
arm64allyesconfig   gcc  
arm64   defconfig   gcc  
csky allmodconfig   gcc  
csky  allnoconfig   gcc  
csky allyesconfig   gcc  
cskydefconfig   gcc  
i386 allmodconfig   gcc  
i386  allnoconfig   gcc  
i386 allyesconfig   gcc  
i386 buildonly-randconfig-001-20231006   gcc  
i386 buildonly-randconfig-002-20231006   gcc  
i386 buildonly-randconfig-003-20231006   gcc  
i386 buildonly-randconfig-004-20231006   gcc  
i386 buildonly-randconfig-005-20231006   gcc  
i386 buildonly-randconfig-006-20231006   gcc  
i386  debian-10.3   gcc  
i386defconfig   gcc  
i386  randconfig-001-20231006   gcc  
i386  randconfig-002-20231006   gcc  
i386  randconfig-003-20231006   gcc  
i386  randconfig-004-20231006   gcc  
i386  randconfig-005-20231006   gcc  
i386  randconfig-006-20231006   gcc  
loongarchallmodconfig   gcc  
loongarch allnoconfig   gcc  
loongarchallyesconfig   gcc  
loongarch   defconfig   gcc  
loongarch randconfig-001-20231006   gcc  
m68k allmodconfig   gcc  
m68k  allnoconfig   gcc  
m68k allyesconfig   gcc  
m68kdefconfig   gcc  
microblaze   allmodconfig   gcc  
microblazeallnoconfig   gcc  
microblaze   allyesconfig   gcc  
microblaze  defconfig   gcc  
mips allmodconfig   gcc  
mips  allnoconfig   gcc  
mips allyesconfig   gcc  
nios2allmodconfig   gcc  
nios2 allnoconfig   gcc  
nios2allyesconfig   gcc  
nios2   defconfig   gcc  
openrisc allmodconfig   gcc  
openrisc  allnoconfig   gcc  
openrisc allyesconfig   gcc  
openriscdefconfig   gcc  
parisc   allmodconfig   gcc  
pariscallnoconfig   gcc  
parisc   allyesconfig   gcc  
parisc  defconfig   gcc  
parisc64defconfig   gcc  
powerpc  allmodconfig   gcc  
powerpc   allnoconfig   gcc  
powerpc  allyesconfig   gcc  
powerpc kmeter1_defconfig   clang
riscvallmodconfig   gcc  
riscv allnoconfig   gcc  
riscvallyesconfig   gcc  
riscv   defconfig   gcc  
riscv  rv32_defconfig   gcc  
s390 allmodconfig   gcc  
s390  allnoconfig   gcc  
s390 allyesconfig   gcc  
s390defconfig   gcc  
sh   allmodconfig   gcc  
shallnoconfig   gcc  
sh   allyesconfig

[Intel-wired-lan] [PATCH iwl-net v1] docs: update info about representor identification

2023-10-06 Thread Mateusz Polchlopek
Update the "How are representors identified?" documentation
subchapter. For newer kernels driver developers should use
SET_NETDEV_DEVLINK_PORT instead of ndo_get_devlink_port()
callback.

Signed-off-by: Mateusz Polchlopek 
Reviewed-by: Wojciech Drewek 
---
 Documentation/networking/representors.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/networking/representors.rst 
b/Documentation/networking/representors.rst
index ee1f5cd54496..2d6b7b493fa6 100644
--- a/Documentation/networking/representors.rst
+++ b/Documentation/networking/representors.rst
@@ -162,9 +162,9 @@ How are representors identified?
 The representor netdevice should *not* directly refer to a PCIe device (e.g.
 through ``net_dev->dev.parent`` / ``SET_NETDEV_DEV()``), either of the
 representee or of the switchdev function.
-Instead, it should implement the ``ndo_get_devlink_port()`` netdevice op, which
-the kernel uses to provide the ``phys_switch_id`` and ``phys_port_name`` sysfs
-nodes.  (Some legacy drivers implement ``ndo_get_port_parent_id()`` and
+Instead, driver developers should use ``SET_NETDEV_DEVLINK_PORT`` macro to
+assign devlink port instance to a netdevice before it registers the netdevice.
+(Some legacy drivers implement ``ndo_get_port_parent_id()`` and
 ``ndo_get_phys_port_name()`` directly, but this is deprecated.)  See
 :ref:`Documentation/networking/devlink/devlink-port.rst ` for the
 details of this API.
-- 
2.38.1

___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan


Re: [Intel-wired-lan] [PATCH net-next 2/4] dpll: spec: add support for pin-dpll signal phase offset/adjust

2023-10-06 Thread Kubalewski, Arkadiusz
>From: Jiri Pirko 
>Sent: Monday, October 2, 2023 4:53 PM
>
>Wed, Sep 27, 2023 at 11:24:33AM CEST, arkadiusz.kubalew...@intel.com wrote:
>>Add new pin's attributes to dpll netlink spec:
>>- phase-offset - measured difference between phase of signals on pin
>>  and dpll
>>- phase-adjust - adjustable value of pin's signal phase
>>- phase-adjust-min / phase-adjust-max - values for determining limits
>>  for phase-adjust
>>
>>Signed-off-by: Arkadiusz Kubalewski 
>>---
>> Documentation/netlink/specs/dpll.yaml | 33 ++-
>> drivers/dpll/dpll_nl.c|  8 ---
>> drivers/dpll/dpll_nl.h|  2 +-
>> include/uapi/linux/dpll.h |  8 ++-
>> 4 files changed, 45 insertions(+), 6 deletions(-)
>>
>>diff --git a/Documentation/netlink/specs/dpll.yaml
>>b/Documentation/netlink/specs/dpll.yaml
>>index 8b86b28b47a6..dc057494101f 100644
>>--- a/Documentation/netlink/specs/dpll.yaml
>>+++ b/Documentation/netlink/specs/dpll.yaml
>>@@ -1,7 +1,7 @@
>> # SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-
>Clause)
>>
>> name: dpll
>>-
>>+version: 2
>
>How is this supposed to work. You bump the version with every uapi
>extension? First time I see this.
>

Well, wasn't sure if this needs to be updated, but sure will remove this part.

Thank you!
Arkadiusz

>[...]
>
>
>>diff --git a/include/uapi/linux/dpll.h b/include/uapi/linux/dpll.h
>>index 20ef0718f8dc..050f51b48ef8 100644
>>--- a/include/uapi/linux/dpll.h
>>+++ b/include/uapi/linux/dpll.h
>>@@ -7,7 +7,7 @@
>> #define _UAPI_LINUX_DPLL_H
>>
>> #define DPLL_FAMILY_NAME "dpll"
>>-#define DPLL_FAMILY_VERSION  1
>>+#define DPLL_FAMILY_VERSION  2
___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan


Re: [Intel-wired-lan] [PATCH net-next v2 2/5] dpll: spec: add support for pin-dpll signal phase offset/adjust

2023-10-06 Thread Kubalewski, Arkadiusz
>From: Jiri Pirko 
>Sent: Wednesday, October 4, 2023 12:42 PM
>
>Wed, Oct 04, 2023 at 11:05:44AM CEST, arkadiusz.kubalew...@intel.com wrote:
>>Add attributes for providing the user with:
>>- measurement of signals phase offset between pin and dpll
>>- ability to adjust the phase of pin signal
>>
>>Signed-off-by: Arkadiusz Kubalewski 
>>---
>> Documentation/netlink/specs/dpll.yaml | 33 ++-
>> drivers/dpll/dpll_nl.c|  8 ---
>> drivers/dpll/dpll_nl.h|  2 +-
>> include/uapi/linux/dpll.h |  8 ++-
>> 4 files changed, 45 insertions(+), 6 deletions(-)
>>
>>diff --git a/Documentation/netlink/specs/dpll.yaml
>>b/Documentation/netlink/specs/dpll.yaml
>>index 8b86b28b47a6..dc057494101f 100644
>>--- a/Documentation/netlink/specs/dpll.yaml
>>+++ b/Documentation/netlink/specs/dpll.yaml
>>@@ -1,7 +1,7 @@
>> # SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-
>Clause)
>>
>> name: dpll
>>-
>>+version: 2
>
>Could you reply to my comment about this in V1 please?

Thanks for pointing this out, I have missed that thread..
I will fix it as suggested with v3.

Thank you!
Arkadiusz
___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan


[Intel-wired-lan] [PATCH iwl-next v2 0/5] ice: Support 5 layer Tx scheduler topology

2023-10-06 Thread Mateusz Polchlopek
For performance reasons there is a need to have support for selectable
Tx scheduler topology. Currently firmware supports only the default
9-layer and 5-layer topology. This patch series enables switch from
default to 5-layer topology, if user decides to opt-in.

---
v2:
- updated documentation
- reorder of variables list (default-init first)
- comments changed to be more descriptive
- added elseif's instead of few if's
- returned error when ice_request_fw fails
- ice_cfg_tx_topo() changed to take const u8 as parameter (get rid of copy
  buffer)
- renamed all "balance" occurences to the new one
- prevent fail of ice_aq_read_nvm() function
- unified variables names (int err instead of int status in few
  functions)
- some smaller fixes, typo fixes

v1: 
https://lore.kernel.org/netdev/20230523174008.3585300-1-anthony.l.ngu...@intel.com/
---

Lukasz Czapnik (1):
  ice: Add tx_scheduling_layers devlink param

Michal Wilczynski (2):
  ice: Enable switching default Tx scheduler topology
  ice: Document tx_scheduling_layers parameter

Raj Victor (2):
  ice: Support 5 layer topology
  ice: Adjust the VSI/Aggregator layers

 Documentation/networking/devlink/ice.rst  |  50 +
 .../net/ethernet/intel/ice/ice_adminq_cmd.h   |  32 +++
 drivers/net/ethernet/intel/ice/ice_common.c   |   5 +
 drivers/net/ethernet/intel/ice/ice_ddp.c  | 199 ++
 drivers/net/ethernet/intel/ice/ice_ddp.h  |   7 +-
 drivers/net/ethernet/intel/ice/ice_devlink.c  | 174 ++-
 .../net/ethernet/intel/ice/ice_fw_update.c|   7 +-
 .../net/ethernet/intel/ice/ice_fw_update.h|   3 +
 drivers/net/ethernet/intel/ice/ice_main.c |  97 +++--
 drivers/net/ethernet/intel/ice/ice_nvm.c  |   2 +-
 drivers/net/ethernet/intel/ice/ice_nvm.h  |   3 +
 drivers/net/ethernet/intel/ice/ice_sched.c|  37 ++--
 drivers/net/ethernet/intel/ice/ice_sched.h|   3 +
 drivers/net/ethernet/intel/ice/ice_type.h |   1 +
 14 files changed, 575 insertions(+), 45 deletions(-)

-- 
2.38.1

___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan


[Intel-wired-lan] [PATCH iwl-net v2 1/5] ice: Support 5 layer topology

2023-10-06 Thread Mateusz Polchlopek
From: Raj Victor 

There is a performance issue when the number of VSIs are not multiple
of 8. This is caused due to the max children limitation per node(8) in
9 layer topology. The BW credits are shared evenly among the children
by default. Assume one node has 8 children and the other has 1.
The parent of these nodes share the BW credit equally among them.
Apparently this causes a problem for the first node which has 8 children.
The 9th VM get more BW credits than the first 8 VMs.

Example:

1) With 8 VM's:
for x in 0 1 2 3 4 5 6 7;
do taskset -c ${x} netperf -P0 -H 172.68.169.125 &  sleep .1 ; done

tx_queue_0_packets: 23283027
tx_queue_1_packets: 23292289
tx_queue_2_packets: 23276136
tx_queue_3_packets: 23279828
tx_queue_4_packets: 23279828
tx_queue_5_packets: 23279333
tx_queue_6_packets: 23277745
tx_queue_7_packets: 23279950
tx_queue_8_packets: 0

2) With 9 VM's:
for x in 0 1 2 3 4 5 6 7 8;
do taskset -c ${x} netperf -P0 -H 172.68.169.125 &  sleep .1 ; done

tx_queue_0_packets: 24163396
tx_queue_1_packets: 24164623
tx_queue_2_packets: 24163188
tx_queue_3_packets: 24163701
tx_queue_4_packets: 24163683
tx_queue_5_packets: 24164668
tx_queue_6_packets: 23327200
tx_queue_7_packets: 24163853
tx_queue_8_packets: 91101417

So on average queue 8 statistics show that 3.7 times more packets were
send there than to the other queues.

The FW starting with version 3.20, has increased the max number of
children per node by reducing the number of layers from 9 to 5. Reflect
this on driver side.

Signed-off-by: Raj Victor 
Co-developed-by: Michal Wilczynski 
Signed-off-by: Michal Wilczynski 
Reviewed-by: Przemek Kitszel 
Signed-off-by: Mateusz Polchlopek 
---
 .../net/ethernet/intel/ice/ice_adminq_cmd.h   |  23 ++
 drivers/net/ethernet/intel/ice/ice_common.c   |   5 +
 drivers/net/ethernet/intel/ice/ice_ddp.c  | 199 ++
 drivers/net/ethernet/intel/ice/ice_ddp.h  |   7 +-
 drivers/net/ethernet/intel/ice/ice_sched.h|   3 +
 drivers/net/ethernet/intel/ice/ice_type.h |   1 +
 6 files changed, 236 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h 
b/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
index eb4c13b754a4..cea1f6f7053f 100644
--- a/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
+++ b/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
@@ -120,6 +120,7 @@ struct ice_aqc_list_caps_elem {
 #define ICE_AQC_CAPS_PCIE_RESET_AVOIDANCE  0x0076
 #define ICE_AQC_CAPS_POST_UPDATE_RESET_RESTRICT0x0077
 #define ICE_AQC_CAPS_NVM_MGMT  0x0080
+#define ICE_AQC_CAPS_TX_SCHED_TOPO_COMP_MODE   0x0085
 #define ICE_AQC_CAPS_FW_LAG_SUPPORT0x0092
 #define ICE_AQC_BIT_ROCEV2_LAG 0x01
 #define ICE_AQC_BIT_SRIOV_LAG  0x02
@@ -806,6 +807,23 @@ struct ice_aqc_get_topo {
__le32 addr_low;
 };
 
+/* Get/Set Tx Topology (indirect 0x0418/0x0417) */
+struct ice_aqc_get_set_tx_topo {
+   u8 set_flags;
+#define ICE_AQC_TX_TOPO_FLAGS_CORRER   BIT(0)
+#define ICE_AQC_TX_TOPO_FLAGS_SRC_RAM  BIT(1)
+#define ICE_AQC_TX_TOPO_FLAGS_LOAD_NEW BIT(4)
+#define ICE_AQC_TX_TOPO_FLAGS_ISSUED   BIT(5)
+
+   u8 get_flags;
+#define ICE_AQC_TX_TOPO_GET_RAM2
+
+   __le16 reserved1;
+   __le32 reserved2;
+   __le32 addr_high;
+   __le32 addr_low;
+};
+
 /* Update TSE (indirect 0x0403)
  * Get TSE (indirect 0x0404)
  * Add TSE (indirect 0x0401)
@@ -2469,6 +2487,7 @@ struct ice_aq_desc {
struct ice_aqc_get_link_topo get_link_topo;
struct ice_aqc_i2c read_write_i2c;
struct ice_aqc_read_i2c_resp read_i2c_resp;
+   struct ice_aqc_get_set_tx_topo get_set_tx_topo;
} params;
 };
 
@@ -2575,6 +2594,10 @@ enum ice_adminq_opc {
ice_aqc_opc_query_sched_res = 0x0412,
ice_aqc_opc_remove_rl_profiles  = 0x0415,
 
+   /* tx topology commands */
+   ice_aqc_opc_set_tx_topo = 0x0417,
+   ice_aqc_opc_get_tx_topo = 0x0418,
+
/* PHY commands */
ice_aqc_opc_get_phy_caps= 0x0600,
ice_aqc_opc_set_phy_cfg = 0x0601,
diff --git a/drivers/net/ethernet/intel/ice/ice_common.c 
b/drivers/net/ethernet/intel/ice/ice_common.c
index d4e259b816b9..b4afdbc3e596 100644
--- a/drivers/net/ethernet/intel/ice/ice_common.c
+++ b/drivers/net/ethernet/intel/ice/ice_common.c
@@ -1549,6 +1549,8 @@ ice_aq_send_cmd(struct ice_hw *hw, struct ice_aq_desc 
*desc, void *buf,
case ice_aqc_opc_set_port_params:
case ice_aqc_opc_get_vlan_mode_parameters:
case ice_aqc_opc_set_vlan_mode_parameters:
+   case ice_aqc_opc_set_tx_topo:
+   case ice_aqc_opc_get_tx_topo:
case ice_aqc_opc_add_recipe:
case ice_aqc_opc_recipe_to_profile:
case ice_aqc_opc_get_rec

[Intel-wired-lan] [PATCH iwl-net v2 2/5] ice: Adjust the VSI/Aggregator layers

2023-10-06 Thread Mateusz Polchlopek
From: Raj Victor 

Adjust the VSI/Aggregator layers based on the number of logical layers
supported by the FW. Currently the VSI and Aggregator layers are
fixed based on the 9 layer scheduler tree layout. Due to performance
reasons the number of layers of the scheduler tree is changing from
9 to 5. It requires a readjustment of these VSI/Aggregator layer values.

Signed-off-by: Raj Victor 
Co-developed-by: Michal Wilczynski 
Signed-off-by: Michal Wilczynski 
Reviewed-by: Przemek Kitszel 
Signed-off-by: Mateusz Polchlopek 
---
 drivers/net/ethernet/intel/ice/ice_sched.c | 37 +++---
 1 file changed, 19 insertions(+), 18 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_sched.c 
b/drivers/net/ethernet/intel/ice/ice_sched.c
index c0533d7b66b9..5a65cf8a1806 100644
--- a/drivers/net/ethernet/intel/ice/ice_sched.c
+++ b/drivers/net/ethernet/intel/ice/ice_sched.c
@@ -1140,12 +1140,11 @@ u8 ice_sched_get_vsi_layer(struct ice_hw *hw)
 * 5 or less   sw_entry_point_layer
 */
/* calculate the VSI layer based on number of layers. */
-   if (hw->num_tx_sched_layers > ICE_VSI_LAYER_OFFSET + 1) {
-   u8 layer = hw->num_tx_sched_layers - ICE_VSI_LAYER_OFFSET;
-
-   if (layer > hw->sw_entry_point_layer)
-   return layer;
-   }
+   if (hw->num_tx_sched_layers == ICE_SCHED_9_LAYERS)
+   return hw->num_tx_sched_layers - ICE_VSI_LAYER_OFFSET;
+   else if (hw->num_tx_sched_layers == ICE_SCHED_5_LAYERS)
+   /* qgroup and VSI layers are same */
+   return hw->num_tx_sched_layers - ICE_QGRP_LAYER_OFFSET;
return hw->sw_entry_point_layer;
 }
 
@@ -1162,13 +1161,10 @@ u8 ice_sched_get_agg_layer(struct ice_hw *hw)
 * 7 or less   sw_entry_point_layer
 */
/* calculate the aggregator layer based on number of layers. */
-   if (hw->num_tx_sched_layers > ICE_AGG_LAYER_OFFSET + 1) {
-   u8 layer = hw->num_tx_sched_layers - ICE_AGG_LAYER_OFFSET;
-
-   if (layer > hw->sw_entry_point_layer)
-   return layer;
-   }
-   return hw->sw_entry_point_layer;
+   if (hw->num_tx_sched_layers == ICE_SCHED_9_LAYERS)
+   return hw->num_tx_sched_layers - ICE_AGG_LAYER_OFFSET;
+   else
+   return hw->sw_entry_point_layer;
 }
 
 /**
@@ -1523,10 +1519,11 @@ ice_sched_get_free_qparent(struct ice_port_info *pi, 
u16 vsi_handle, u8 tc,
 {
struct ice_sched_node *vsi_node, *qgrp_node;
struct ice_vsi_ctx *vsi_ctx;
+   u8 qgrp_layer, vsi_layer;
u16 max_children;
-   u8 qgrp_layer;
 
qgrp_layer = ice_sched_get_qgrp_layer(pi->hw);
+   vsi_layer = ice_sched_get_vsi_layer(pi->hw);
max_children = pi->hw->max_children[qgrp_layer];
 
vsi_ctx = ice_get_vsi_ctx(pi->hw, vsi_handle);
@@ -1537,6 +1534,12 @@ ice_sched_get_free_qparent(struct ice_port_info *pi, u16 
vsi_handle, u8 tc,
if (!vsi_node)
return NULL;
 
+   /* If the queue group and VSI layer are same then queues
+* are all attached directly to VSI
+*/
+   if (qgrp_layer == vsi_layer)
+   return vsi_node;
+
/* get the first queue group node from VSI sub-tree */
qgrp_node = ice_sched_get_first_node(pi, vsi_node, qgrp_layer);
while (qgrp_node) {
@@ -3220,7 +3223,7 @@ ice_sched_add_rl_profile(struct ice_port_info *pi,
u8 profile_type;
int status;
 
-   if (layer_num >= ICE_AQC_TOPO_MAX_LEVEL_NUM)
+   if (!pi || layer_num >= pi->hw->num_tx_sched_layers)
return NULL;
switch (rl_type) {
case ICE_MIN_BW:
@@ -3236,8 +3239,6 @@ ice_sched_add_rl_profile(struct ice_port_info *pi,
return NULL;
}
 
-   if (!pi)
-   return NULL;
hw = pi->hw;
list_for_each_entry(rl_prof_elem, &pi->rl_prof_list[layer_num],
list_entry)
@@ -3467,7 +3468,7 @@ ice_sched_rm_rl_profile(struct ice_port_info *pi, u8 
layer_num, u8 profile_type,
struct ice_aqc_rl_profile_info *rl_prof_elem;
int status = 0;
 
-   if (layer_num >= ICE_AQC_TOPO_MAX_LEVEL_NUM)
+   if (layer_num >= pi->hw->num_tx_sched_layers)
return -EINVAL;
/* Check the existing list for RL profile */
list_for_each_entry(rl_prof_elem, &pi->rl_prof_list[layer_num],
-- 
2.38.1

___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan


[Intel-wired-lan] [PATCH iwl-net v2 3/5] ice: Enable switching default Tx scheduler topology

2023-10-06 Thread Mateusz Polchlopek
From: Michal Wilczynski 

Introduce support for Tx scheduler topology change, based on user
selection, from default 9-layer to 5-layer.
Change requires NVM (version 3.20 or newer) and DDP package (OS Package
1.3.30 or newer - available for over a year in linux-firmware, since
commit aed71f296637 in linux-firmware ("ice: Update package to 1.3.30.0"))
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=aed71f296637

Enable 5-layer topology switch in init path of the driver. To accomplish
that upload of the DDP package needs to be delayed, until change in Tx
topology is finished. To trigger the Tx change user selection should be
changed in NVM using devlink. Then the platform should be rebooted.

Signed-off-by: Michal Wilczynski 
Reviewed-by: Przemek Kitszel 
Co-developed-by: Mateusz Polchlopek 
Signed-off-by: Mateusz Polchlopek 
---
 drivers/net/ethernet/intel/ice/ice_ddp.c  |  2 +-
 drivers/net/ethernet/intel/ice/ice_ddp.h  |  2 +-
 drivers/net/ethernet/intel/ice/ice_main.c | 97 ++-
 3 files changed, 80 insertions(+), 21 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_ddp.c 
b/drivers/net/ethernet/intel/ice/ice_ddp.c
index 95c7712b56b8..44591bcdb537 100644
--- a/drivers/net/ethernet/intel/ice/ice_ddp.c
+++ b/drivers/net/ethernet/intel/ice/ice_ddp.c
@@ -1950,7 +1950,7 @@ ice_get_set_tx_topo(struct ice_hw *hw, u8 *buf, u16 
buf_size,
  * The function will apply the new Tx topology from the package buffer
  * if available.
  */
-int ice_cfg_tx_topo(struct ice_hw *hw, u8 *buf, u32 len)
+int ice_cfg_tx_topo(struct ice_hw *hw, const u8 *buf, u32 len)
 {
u8 *current_topo, *new_topo = NULL;
struct ice_run_time_cfg_seg *seg;
diff --git a/drivers/net/ethernet/intel/ice/ice_ddp.h 
b/drivers/net/ethernet/intel/ice/ice_ddp.h
index c00203df35da..b6f126e11dea 100644
--- a/drivers/net/ethernet/intel/ice/ice_ddp.h
+++ b/drivers/net/ethernet/intel/ice/ice_ddp.h
@@ -432,6 +432,6 @@ u16 ice_pkg_buf_get_active_sections(struct ice_buf_build 
*bld);
 void *ice_pkg_enum_section(struct ice_seg *ice_seg, struct ice_pkg_enum *state,
   u32 sect_type);
 
-int ice_cfg_tx_topo(struct ice_hw *hw, u8 *buf, u32 len);
+int ice_cfg_tx_topo(struct ice_hw *hw, const u8 *buf, u32 len);
 
 #endif
diff --git a/drivers/net/ethernet/intel/ice/ice_main.c 
b/drivers/net/ethernet/intel/ice/ice_main.c
index 3363c69d49da..ad3a1572a635 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -4319,11 +4319,11 @@ static char *ice_get_opt_fw_name(struct ice_pf *pf)
 /**
  * ice_request_fw - Device initialization routine
  * @pf: pointer to the PF instance
+ * @firmware: double pointer to firmware struct
  */
-static void ice_request_fw(struct ice_pf *pf)
+static int ice_request_fw(struct ice_pf *pf, const struct firmware **firmware)
 {
char *opt_fw_filename = ice_get_opt_fw_name(pf);
-   const struct firmware *firmware = NULL;
struct device *dev = ice_pf_to_dev(pf);
int err = 0;
 
@@ -4332,29 +4332,86 @@ static void ice_request_fw(struct ice_pf *pf)
 * and warning messages for other errors.
 */
if (opt_fw_filename) {
-   err = firmware_request_nowarn(&firmware, opt_fw_filename, dev);
-   if (err) {
-   kfree(opt_fw_filename);
-   goto dflt_pkg_load;
-   }
-
-   /* request for firmware was successful. Download to device */
-   ice_load_pkg(firmware, pf);
+   err = firmware_request_nowarn(firmware, opt_fw_filename, dev);
kfree(opt_fw_filename);
-   release_firmware(firmware);
-   return;
+   if (!err)
+   return err;
}
+   err = request_firmware(firmware, ICE_DDP_PKG_FILE, dev);
+   if (err)
+   dev_err(dev, "The DDP package file was not found or could not 
be read. Entering Safe Mode\n");
+
+   return err;
+}
+
+/**
+ * ice_init_tx_topology - performs Tx topology initialization
+ * @hw: pointer to the hardware structure
+ * @firmware: pointer to firmware structure
+ */
+static int
+ice_init_tx_topology(struct ice_hw *hw, const struct firmware *firmware)
+{
+   u8 num_tx_sched_layers = hw->num_tx_sched_layers;
+   struct ice_pf *pf = hw->back;
+   struct device *dev;
+   int err;
+
+   dev = ice_pf_to_dev(pf);
 
-dflt_pkg_load:
-   err = request_firmware(&firmware, ICE_DDP_PKG_FILE, dev);
+   err = ice_cfg_tx_topo(hw, firmware->data, firmware->size);
+   if (!err) {
+   if (hw->num_tx_sched_layers > num_tx_sched_layers)
+   dev_info(dev, "Tx scheduling layers switching feature 
disabled\n");
+   else
+   dev_info(dev, "Tx scheduling layers switching feature 
enabled\n");
+   /* if there was a change in topology ice_cfg_tx_topo trigger

[Intel-wired-lan] [PATCH iwl-net v2 4/5] ice: Add tx_scheduling_layers devlink param

2023-10-06 Thread Mateusz Polchlopek
From: Lukasz Czapnik 

It was observed that Tx performance was inconsistent across all queues
and/or VSIs and that it was directly connected to existing 9-layer
topology of the Tx scheduler.

Introduce new private devlink param - tx_scheduling_layers. This parameter
gives user flexibility to choose the 5-layer transmit scheduler topology
which helps to smooth out the transmit performance.

Allowed parameter values are 5 and 9.

Example usage:

Show:
devlink dev param show pci/:4b:00.0 name tx_scheduling_layers
pci/:4b:00.0:
  name tx_scheduling_layers type driver-specific
values:
  cmode permanent value 9

Set:
devlink dev param set pci/:4b:00.0 name tx_scheduling_layers value 5
cmode permanent

devlink dev param set pci/:4b:00.0 name tx_scheduling_layers value 9
cmode permanent

Signed-off-by: Lukasz Czapnik 
Reviewed-by: Przemek Kitszel 
Co-developed-by: Mateusz Polchlopek 
Signed-off-by: Mateusz Polchlopek 
---
 .../net/ethernet/intel/ice/ice_adminq_cmd.h   |   9 +
 drivers/net/ethernet/intel/ice/ice_devlink.c  | 174 +-
 .../net/ethernet/intel/ice/ice_fw_update.c|   7 +-
 .../net/ethernet/intel/ice/ice_fw_update.h|   3 +
 drivers/net/ethernet/intel/ice/ice_nvm.c  |   2 +-
 drivers/net/ethernet/intel/ice/ice_nvm.h  |   3 +
 6 files changed, 192 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h 
b/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
index cea1f6f7053f..1202abfb9eb3 100644
--- a/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
+++ b/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
@@ -1616,6 +1616,15 @@ struct ice_aqc_nvm {
 };
 
 #define ICE_AQC_NVM_START_POINT0
+#define ICE_AQC_NVM_TX_TOPO_MOD_ID 0x14B
+
+struct ice_aqc_nvm_tx_topo_user_sel {
+   __le16 length;
+   u8 data;
+#define ICE_AQC_NVM_TX_TOPO_USER_SEL   BIT(4)
+
+   u8 reserved;
+};
 
 /* NVM Checksum Command (direct, 0x0706) */
 struct ice_aqc_nvm_checksum {
diff --git a/drivers/net/ethernet/intel/ice/ice_devlink.c 
b/drivers/net/ethernet/intel/ice/ice_devlink.c
index 80dc5445b50d..55974079aa3f 100644
--- a/drivers/net/ethernet/intel/ice/ice_devlink.c
+++ b/drivers/net/ethernet/intel/ice/ice_devlink.c
@@ -736,6 +736,172 @@ ice_devlink_port_unsplit(struct devlink *devlink, struct 
devlink_port *port,
return ice_devlink_port_split(devlink, port, 1, extack);
 }
 
+enum ice_devlink_param_id {
+   ICE_DEVLINK_PARAM_ID_BASE = DEVLINK_PARAM_GENERIC_ID_MAX,
+   ICE_DEVLINK_PARAM_ID_TX_BALANCE,
+};
+
+/**
+ * ice_get_tx_topo_user_sel - Read user's choice from flash
+ * @pf: pointer to pf structure
+ * @layers: value read from flash will be saved here
+ *
+ * Reads user's preference for Tx Scheduler Topology Tree from PFA TLV.
+ *
+ * Returns zero when read was successful, negative values otherwise.
+ */
+static int ice_get_tx_topo_user_sel(struct ice_pf *pf, uint8_t *layers)
+{
+   struct ice_aqc_nvm_tx_topo_user_sel usr_sel = {};
+   struct ice_hw *hw = &pf->hw;
+   int err;
+
+   err = ice_acquire_nvm(hw, ICE_RES_READ);
+   if (err)
+   return err;
+
+   err = ice_aq_read_nvm(hw, ICE_AQC_NVM_TX_TOPO_MOD_ID, 0,
+ sizeof(usr_sel), &usr_sel, true, true, NULL);
+   if (err)
+   goto exit_release_res;
+
+   if (usr_sel.data & ICE_AQC_NVM_TX_TOPO_USER_SEL)
+   *layers = ICE_SCHED_5_LAYERS;
+   else
+   *layers = ICE_SCHED_9_LAYERS;
+
+exit_release_res:
+   ice_release_nvm(hw);
+
+   return err;
+}
+
+/**
+ * ice_update_tx_topo_user_sel - Save user's preference in flash
+ * @pf: pointer to pf structure
+ * @layers: value to be saved in flash
+ *
+ * Variable "layers" defines user's preference about number of layers in Tx
+ * Scheduler Topology Tree. This choice should be stored in PFA TLV field
+ * and be picked up by driver, next time during init.
+ *
+ * Returns zero when save was successful, negative values otherwise.
+ */
+static int ice_update_tx_topo_user_sel(struct ice_pf *pf, int layers)
+{
+   struct ice_aqc_nvm_tx_topo_user_sel usr_sel = {};
+   struct ice_hw *hw = &pf->hw;
+   int err;
+
+   err = ice_acquire_nvm(hw, ICE_RES_WRITE);
+   if (err)
+   return err;
+
+   err = ice_aq_read_nvm(hw, ICE_AQC_NVM_TX_TOPO_MOD_ID, 0,
+ sizeof(usr_sel), &usr_sel, true, true, NULL);
+   if (err)
+   goto exit_release_res;
+
+   if (layers == ICE_SCHED_5_LAYERS)
+   usr_sel.data |= ICE_AQC_NVM_TX_TOPO_USER_SEL;
+   else
+   usr_sel.data &= ~ICE_AQC_NVM_TX_TOPO_USER_SEL;
+
+   err = ice_write_one_nvm_block(pf, ICE_AQC_NVM_TX_TOPO_MOD_ID, 2,
+ sizeof(usr_sel.data), &usr_sel.data,
+ true, NULL, NULL);
+   if (err)
+   err = -EIO;
+
+exit_release_res:
+   ice_releas

[Intel-wired-lan] [PATCH iwl-net v2 5/5] ice: Document tx_scheduling_layers parameter

2023-10-06 Thread Mateusz Polchlopek
From: Michal Wilczynski 

New driver specific parameter 'tx_scheduling_layers' was introduced.
Describe parameter in the documentation.

Signed-off-by: Michal Wilczynski 
Reviewed-by: Przemek Kitszel 
Co-developed-by: Mateusz Polchlopek 
Signed-off-by: Mateusz Polchlopek 
---
 Documentation/networking/devlink/ice.rst | 50 
 1 file changed, 50 insertions(+)

diff --git a/Documentation/networking/devlink/ice.rst 
b/Documentation/networking/devlink/ice.rst
index 2f60e34ab926..328a728d197b 100644
--- a/Documentation/networking/devlink/ice.rst
+++ b/Documentation/networking/devlink/ice.rst
@@ -22,6 +22,56 @@ Parameters
  - runtime
  - mutually exclusive with ``enable_roce``
 
+.. list-table:: Driver-specific parameters implemented
+   :widths: 5 5 5 85
+
+   * - Name
+ - Type
+ - Mode
+ - Description
+   * - ``tx_scheduling_layers``
+ - u8
+ - permanent
+   The ice hardware uses hierarchical scheduling for Tx with a fixed
+   number of layers in the scheduling tree. Root node is representing a
+   port, while all the leaves represents the queues. This way of
+   configuring Tx scheduler allows features like DCB or devlink-rate
+   (documented below) for fine-grained configuration how much BW is given
+   to any given queue or group of queues, as scheduling parameters can be
+   configured at any given layer of the tree. By default 9-layer tree
+   topology was deemed best for most workloads, as it gives optimal
+   performance to configurability ratio. However for some specific cases,
+   this might not be the case. A great example would be sending traffic to
+   queues that is not a multiple of 8. Since in 9-layer topology maximum
+   number of children is limited to 8, the 9th queue has a different parent
+   than the rest, and it's given more BW credits. This causes a problem
+   when the system is sending traffic to 9 queues:
+
+   | tx_queue_0_packets: 24163396
+   | tx_queue_1_packets: 24164623
+   | tx_queue_2_packets: 24163188
+   | tx_queue_3_packets: 24163701
+   | tx_queue_4_packets: 24163683
+   | tx_queue_5_packets: 24164668
+   | tx_queue_6_packets: 23327200
+   | tx_queue_7_packets: 24163853
+   | tx_queue_8_packets: 91101417 < Too much traffic is sent to 9th
+
+   Sometimes this might be a big concern, so the idea is to empower the
+   user to switch to 5-layer topology, enabling performance gains but
+   sacrificing configurability for features like DCB and devlink-rate.
+
+   This parameter gives user flexibility to choose the 5-layer transmit
+   scheduler topology. After switching parameter reboot is required for
+   the feature to start working.
+
+   User could choose 9 (the default) or 5 as a value of parameter, e.g.:
+   $ devlink dev param set pci/:16:00.0 name tx_scheduling_layers
+ value 5 cmode permanent
+
+   And verify that value has been set:
+   $ devlink dev param show pci/:16:00.0 name tx_scheduling_layers
+
 Info versions
 =
 
-- 
2.38.1

___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan


[Intel-wired-lan] [PATCH net] i40e: prevent crash on probe if hw registers have invalid values

2023-10-06 Thread Michal Schmidt
The hardware provides the indexes of the first and the last available
queue and VF. From the indexes, the driver calculates the numbers of
queues and VFs. In theory, a faulty device might say the last index is
smaller than the first index. In that case, the driver's calculation
would underflow, it would attempt to write to non-existent registers
outside of the ioremapped range and crash.

I ran into this not by having a faulty device, but by an operator error.
I accidentally ran a QE test meant for i40e devices on an ice device.
The test used 'echo i40e > /sys/...ice PCI device.../driver_override',
bound the driver to the device and crashed in one of the wr32 calls in
i40e_clear_hw.

Add checks to prevent underflows in the calculations of num_queues and
num_vfs. With this fix, the wrong device probing reports errors and
returns a failure without crashing.

Fixes: 838d41d92a90 ("i40e: clear all queues and interrupts")
Signed-off-by: Michal Schmidt 
---
 drivers/net/ethernet/intel/i40e/i40e_common.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_common.c 
b/drivers/net/ethernet/intel/i40e/i40e_common.c
index eeef20f77106..1b493854f522 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_common.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_common.c
@@ -1082,7 +1082,7 @@ void i40e_clear_hw(struct i40e_hw *hw)
 I40E_PFLAN_QALLOC_FIRSTQ_SHIFT;
j = (val & I40E_PFLAN_QALLOC_LASTQ_MASK) >>
I40E_PFLAN_QALLOC_LASTQ_SHIFT;
-   if (val & I40E_PFLAN_QALLOC_VALID_MASK)
+   if (val & I40E_PFLAN_QALLOC_VALID_MASK && j >= base_queue)
num_queues = (j - base_queue) + 1;
else
num_queues = 0;
@@ -1092,7 +1092,7 @@ void i40e_clear_hw(struct i40e_hw *hw)
I40E_PF_VT_PFALLOC_FIRSTVF_SHIFT;
j = (val & I40E_PF_VT_PFALLOC_LASTVF_MASK) >>
I40E_PF_VT_PFALLOC_LASTVF_SHIFT;
-   if (val & I40E_PF_VT_PFALLOC_VALID_MASK)
+   if (val & I40E_PF_VT_PFALLOC_VALID_MASK && j >= i)
num_vfs = (j - i) + 1;
else
num_vfs = 0;
-- 
2.41.0

___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan


Re: [Intel-wired-lan] [PATCH net] ixgbe: fix crash with empty VF macvlan list

2023-10-06 Thread Simon Horman
On Thu, Oct 05, 2023 at 04:57:02PM +0300, Dan Carpenter wrote:
> The adapter->vf_mvs.l list needs to be initialized even if the list is
> empty.  Otherwise it will lead to crashes.
> 
> Fixes: c6bda30a06d9 ("ixgbe: Reconfigure SR-IOV Init")

Hi Dan,

I see that the patch cited above added the line you are changing.
But it also seems to me that patch was moving it from elsewhere.

Perhaps I am mistaken, but I wonder if this is a better tag.

Fixes: a1cbb15c1397 ("ixgbe: Add macvlan support for VF")

> Signed-off-by: Dan Carpenter 
> ---
>  drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c 
> b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
> index a703ba975205..9cfdfa8a4355 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
> @@ -28,6 +28,9 @@ static inline void ixgbe_alloc_vf_macvlans(struct 
> ixgbe_adapter *adapter,
>   struct vf_macvlans *mv_list;
>   int num_vf_macvlans, i;
>  
> + /* Initialize list of VF macvlans */
> + INIT_LIST_HEAD(&adapter->vf_mvs.l);
> +
>   num_vf_macvlans = hw->mac.num_rar_entries -
> (IXGBE_MAX_PF_MACVLANS + 1 + num_vfs);
>   if (!num_vf_macvlans)
> @@ -36,8 +39,6 @@ static inline void ixgbe_alloc_vf_macvlans(struct 
> ixgbe_adapter *adapter,
>   mv_list = kcalloc(num_vf_macvlans, sizeof(struct vf_macvlans),
> GFP_KERNEL);
>   if (mv_list) {

I'm not sure it it is worth it, but perhaps more conventional error
handling could be used here:

if (!mv_list)
return;

for (i = 0; i < num_vf_macvlans; i++) {
...

> - /* Initialize list of VF macvlans */
> - INIT_LIST_HEAD(&adapter->vf_mvs.l);
>   for (i = 0; i < num_vf_macvlans; i++) {
>   mv_list[i].vf = -1;
>   mv_list[i].free = true;
> -- 
> 2.39.2
> 
> 
___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan


Re: [Intel-wired-lan] [PATCH net-next 1/2] igb: Fix an end of loop test

2023-10-06 Thread Simon Horman
On Thu, Oct 05, 2023 at 04:57:21PM +0300, Dan Carpenter wrote:
> When we exit a list_for_each_entry() without hitting a break statement,
> the list iterator isn't NULL, it just point to an offset off the
> list_head.  In that situation, it wouldn't be too surprising for
> entry->free to be true and we end up corrupting memory.
> 
> The way to test for these is to just set a flag.
> 
> Fixes: c1fec890458a ("ethernet/intel: Use list_for_each_entry() helper")
> Signed-off-by: Dan Carpenter 

Reviewed-by: Simon Horman 
___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan


Re: [Intel-wired-lan] [PATCH net-next 2/2] ixgbe: fix end of loop test in ixgbe_set_vf_macvlan()

2023-10-06 Thread Simon Horman
On Thu, Oct 05, 2023 at 04:58:01PM +0300, Dan Carpenter wrote:
> The list iterator in a list_for_each_entry() loop can never be NULL.
> If the loop exits without hitting a break then the iterator points
> to an offset off the list head and dereferencing it is an out of
> bounds access.
> 
> Before we transitioned to using list_for_each_entry() loops, then
> it was possible for "entry" to be NULL and the comments mention
> this.  I have updated the comments to match the new code.
> 
> Fixes: c1fec890458a ("ethernet/intel: Use list_for_each_entry() helper")
> Signed-off-by: Dan Carpenter 

Reviewed-by: Simon Horman 

___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan


[Intel-wired-lan] [PATCH net-next v3 0/5] dpll: add phase-offset and phase-adjust

2023-10-06 Thread Arkadiusz Kubalewski
Improve monitoring and control over dpll devices.
Allow user to receive measurement of phase difference between signals on
pin and dpll (phase-offset).
Allow user to receive and control adjustable value of pin's signal
phase (phase-adjust).

v2->v3:
- do not increase do version of uAPI header as it is not needed

v1->v2:
- improve handling for error case of requesting the phase adjust set
- align handling for error case of frequency set request with the
approach introduced for phase adjust

Arkadiusz Kubalewski (5):
  dpll: docs: add support for pin signal phase offset/adjust
  dpll: spec: add support for pin-dpll signal phase offset/adjust
  dpll: netlink/core: add support for pin-dpll signal phase
offset/adjust
  ice: dpll: implement phase related callbacks
  dpll: netlink/core: change pin frequency set behavior

 Documentation/driver-api/dpll.rst |  53 -
 Documentation/netlink/specs/dpll.yaml |  33 +++-
 drivers/dpll/dpll_netlink.c   | 180 +++--
 drivers/dpll/dpll_nl.c|   8 +-
 drivers/dpll/dpll_nl.h|   2 +-
 drivers/net/ethernet/intel/ice/ice_dpll.c | 224 +-
 drivers/net/ethernet/intel/ice/ice_dpll.h |  10 +-
 include/linux/dpll.h  |  18 ++
 include/uapi/linux/dpll.h |   8 +-
 9 files changed, 514 insertions(+), 22 deletions(-)

-- 
2.38.1

___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan


[Intel-wired-lan] [PATCH net-next v3 1/5] dpll: docs: add support for pin signal phase offset/adjust

2023-10-06 Thread Arkadiusz Kubalewski
Add documentation on:
- measurment of phase of signal between pin and dpll
- adjustment of pin signal phase

Signed-off-by: Arkadiusz Kubalewski 
---
 Documentation/driver-api/dpll.rst | 53 ++-
 1 file changed, 52 insertions(+), 1 deletion(-)

diff --git a/Documentation/driver-api/dpll.rst 
b/Documentation/driver-api/dpll.rst
index 69670deb8c4e..564997373437 100644
--- a/Documentation/driver-api/dpll.rst
+++ b/Documentation/driver-api/dpll.rst
@@ -173,6 +173,47 @@ in order to configure active input of a MUX-type pin, the 
user needs to
 request desired pin state of the child pin on the parent pin,
 as described in the ``MUX-type pins`` chapter.
 
+Phase offset measurement and adjustment
+
+
+Device may provide ability to measure a phase difference between signals
+on a pin and its parent dpll device. If pin-dpll phase offset measurement
+is supported, it shall be provided with ``DPLL_A_PIN_PHASE_OFFSET``
+attribute for each parent dpll device.
+
+Device may also provide ability to adjust a signal phase on a pin.
+If pin phase adjustment is supported, minimal and maximal values that pin
+handle shall be provide to the user on ``DPLL_CMD_PIN_GET`` respond
+with ``DPLL_A_PIN_PHASE_ADJUST_MIN`` and ``DPLL_A_PIN_PHASE_ADJUST_MAX``
+attributes. Configured phase adjust value is provided with
+``DPLL_A_PIN_PHASE_ADJUST`` attribute of a pin, and value change can be
+requested with the same attribute with ``DPLL_CMD_PIN_SET`` command.
+
+  === ==
+  ``DPLL_A_PIN_ID``   configured pin id
+  ``DPLL_A_PIN_PHASE_ADJUST_MIN`` attr minimum value of phase adjustment
+  ``DPLL_A_PIN_PHASE_ADJUST_MAX`` attr maximum value of phase adjustment
+  ``DPLL_A_PIN_PHASE_ADJUST`` attr configured value of phase
+  adjustment on parent dpll device
+  ``DPLL_A_PIN_PARENT_DEVICE``nested attribute for requesting
+  configuration on given parent dpll
+  device
+``DPLL_A_PIN_PARENT_ID``  parent dpll device id
+``DPLL_A_PIN_PHASE_OFFSET``   attr measured phase difference
+  between a pin and parent dpll device
+  === ==
+
+All phase related values are provided in pico seconds, which represents
+time differnece between signals phase. The negative value means that
+phase of signal on pin is earlier in time than dpll's signal. Positive
+value means that phase of signal on pin is later in time than signal of
+a dpll.
+
+Phase adjust (also min and max) values are integers, but measured phase
+offset values are fractional with 3-digit decimal places and shell be
+divided with ``DPLL_PIN_PHASE_OFFSET_DIVIDER`` to get integer part and
+modulo divided to get fractional part.
+
 Configuration commands group
 
 
@@ -263,6 +304,12 @@ according to attribute purpose.
frequencies
   ``DPLL_A_PIN_ANY_FREQUENCY_MIN`` attr minimum value of frequency
   ``DPLL_A_PIN_ANY_FREQUENCY_MAX`` attr maximum value of frequency
+``DPLL_A_PIN_PHASE_ADJUST_MIN``attr minimum value of phase
+   adjustment
+``DPLL_A_PIN_PHASE_ADJUST_MAX``attr maximum value of phase
+   adjustment
+``DPLL_A_PIN_PHASE_ADJUST``attr configured value of phase
+   adjustment on parent device
 ``DPLL_A_PIN_PARENT_DEVICE``   nested attr for each parent device
the pin is connected with
   ``DPLL_A_PIN_PARENT_ID`` attr parent dpll device id
@@ -270,8 +317,10 @@ according to attribute purpose.
dpll device
   ``DPLL_A_PIN_STATE`` attr state of pin on the parent
dpll device
- ``DPLL_A_PIN_DIRECTION``  attr direction of a pin on the
+  ``DPLL_A_PIN_DIRECTION`` attr direction of a pin on the
parent dpll device
+  ``DPLL_A_PIN_PHASE_OFFSET``  attr measured phase difference
+   between a pin and parent dpll
 ``DPLL_A_PIN_PARENT_PIN``  nested attr for each parent pin
the pin is connected with
   ``DPLL_A_PIN_PARENT_ID`` attr parent pin id
@@ -284,6 +333,8 @@ according to attribute purpose.
   ``DPLL_CMD_PIN_SET`` command to set pins configuration
 ``DPLL_A_PIN_ID``  attr unique a pin ID
 ``DPLL_A_PIN_FREQUENCY``   attr requested frequency of a pin
+``DPLL_A_PIN_PHASE_ADJUST``attr requested value of phase
+   adjustment on parent device
 

[Intel-wired-lan] [PATCH net-next v3 2/5] dpll: spec: add support for pin-dpll signal phase offset/adjust

2023-10-06 Thread Arkadiusz Kubalewski
Add attributes for providing the user with:
- measurement of signals phase offset between pin and dpll
- ability to adjust the phase of pin signal

Signed-off-by: Arkadiusz Kubalewski 
---
 Documentation/netlink/specs/dpll.yaml | 33 ++-
 drivers/dpll/dpll_nl.c|  8 ---
 drivers/dpll/dpll_nl.h|  2 +-
 include/uapi/linux/dpll.h |  8 ++-
 4 files changed, 45 insertions(+), 6 deletions(-)

diff --git a/Documentation/netlink/specs/dpll.yaml 
b/Documentation/netlink/specs/dpll.yaml
index 8b86b28b47a6..dc057494101f 100644
--- a/Documentation/netlink/specs/dpll.yaml
+++ b/Documentation/netlink/specs/dpll.yaml
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)
 
 name: dpll
-
+version: 2
 doc: DPLL subsystem.
 
 definitions:
@@ -164,6 +164,18 @@ definitions:
   -
 name: state-can-change
 doc: pin state can be changed
+  -
+type: const
+name: phase-offset-divider
+value: 1000
+doc: |
+  phase offset divider allows userspace to calculate a value of
+  measured signal phase difference between a pin and dpll device
+  as a fractional value with three digit decimal precision.
+  Value of (DPLL_A_PHASE_OFFSET / DPLL_PHASE_OFFSET_DIVIDER) is an
+  integer part of a measured phase offest value.
+  Value of (DPLL_A_PHASE_OFFSET % DPLL_PHASE_OFFSET_DIVIDER) is a
+  fractional part of a measured phase offest value.
 
 attribute-sets:
   -
@@ -272,6 +284,18 @@ attribute-sets:
 type: nest
 multi-attr: true
 nested-attributes: pin-parent-pin
+  -
+name: phase-adjust-min
+type: s32
+  -
+name: phase-adjust-max
+type: s32
+  -
+name: phase-adjust
+type: s32
+  -
+name: phase-offset
+type: s64
   -
 name: pin-parent-device
 subset-of: pin
@@ -288,6 +312,9 @@ attribute-sets:
   -
 name: state
 type: u32
+  -
+name: phase-offset
+type: s64
   -
 name: pin-parent-pin
 subset-of: pin
@@ -439,6 +466,9 @@ operations:
 - capabilities
 - parent-device
 - parent-pin
+- phase-adjust-min
+- phase-adjust-max
+- phase-adjust
 
   dump:
 pre: dpll-lock-dumpit
@@ -466,6 +496,7 @@ operations:
 - state
 - parent-device
 - parent-pin
+- phase-adjust
 -
   name: pin-create-ntf
   doc: Notification about pin appearing
diff --git a/drivers/dpll/dpll_nl.c b/drivers/dpll/dpll_nl.c
index 14064c8c783b..eaee5be7aa64 100644
--- a/drivers/dpll/dpll_nl.c
+++ b/drivers/dpll/dpll_nl.c
@@ -11,11 +11,12 @@
 #include 
 
 /* Common nested types */
-const struct nla_policy dpll_pin_parent_device_nl_policy[DPLL_A_PIN_STATE + 1] 
= {
+const struct nla_policy 
dpll_pin_parent_device_nl_policy[DPLL_A_PIN_PHASE_OFFSET + 1] = {
[DPLL_A_PIN_PARENT_ID] = { .type = NLA_U32, },
[DPLL_A_PIN_DIRECTION] = NLA_POLICY_RANGE(NLA_U32, 1, 2),
[DPLL_A_PIN_PRIO] = { .type = NLA_U32, },
[DPLL_A_PIN_STATE] = NLA_POLICY_RANGE(NLA_U32, 1, 3),
+   [DPLL_A_PIN_PHASE_OFFSET] = { .type = NLA_S64, },
 };
 
 const struct nla_policy dpll_pin_parent_pin_nl_policy[DPLL_A_PIN_STATE + 1] = {
@@ -61,7 +62,7 @@ static const struct nla_policy 
dpll_pin_get_dump_nl_policy[DPLL_A_PIN_ID + 1] =
 };
 
 /* DPLL_CMD_PIN_SET - do */
-static const struct nla_policy dpll_pin_set_nl_policy[DPLL_A_PIN_PARENT_PIN + 
1] = {
+static const struct nla_policy dpll_pin_set_nl_policy[DPLL_A_PIN_PHASE_ADJUST 
+ 1] = {
[DPLL_A_PIN_ID] = { .type = NLA_U32, },
[DPLL_A_PIN_FREQUENCY] = { .type = NLA_U64, },
[DPLL_A_PIN_DIRECTION] = NLA_POLICY_RANGE(NLA_U32, 1, 2),
@@ -69,6 +70,7 @@ static const struct nla_policy 
dpll_pin_set_nl_policy[DPLL_A_PIN_PARENT_PIN + 1]
[DPLL_A_PIN_STATE] = NLA_POLICY_RANGE(NLA_U32, 1, 3),
[DPLL_A_PIN_PARENT_DEVICE] = 
NLA_POLICY_NESTED(dpll_pin_parent_device_nl_policy),
[DPLL_A_PIN_PARENT_PIN] = 
NLA_POLICY_NESTED(dpll_pin_parent_pin_nl_policy),
+   [DPLL_A_PIN_PHASE_ADJUST] = { .type = NLA_S32, },
 };
 
 /* Ops table for dpll */
@@ -140,7 +142,7 @@ static const struct genl_split_ops dpll_nl_ops[] = {
.doit   = dpll_nl_pin_set_doit,
.post_doit  = dpll_pin_post_doit,
.policy = dpll_pin_set_nl_policy,
-   .maxattr= DPLL_A_PIN_PARENT_PIN,
+   .maxattr= DPLL_A_PIN_PHASE_ADJUST,
.flags  = GENL_ADMIN_PERM | GENL_CMD_CAP_DO,
},
 };
diff --git a/drivers/dpll/dpll_nl.h b/drivers/dpll/dpll_nl.h
index 1f67aaed4742..92d4c9c4f788 100644
--- a/drivers/dpll/dpll_nl.h
+++ b/drivers/dpll/dpll_nl.h
@@ -12,7 +12,7 @@
 #include 
 
 /* Common nested types */
-extern const struct nla_policy 
dpll_pin_parent_device_nl_pol

[Intel-wired-lan] [PATCH net-next v3 3/5] dpll: netlink/core: add support for pin-dpll signal phase offset/adjust

2023-10-06 Thread Arkadiusz Kubalewski
Add callback ops for pin-dpll phase measurment.
Add callback for pin signal phase adjustment.
Add min and max phase adjustment values to pin proprties.
Invoke callbacks in dpll_netlink.c when filling the pin details to
provide user with phase related attribute values.

Signed-off-by: Arkadiusz Kubalewski 
---
 drivers/dpll/dpll_netlink.c | 130 +++-
 include/linux/dpll.h|  18 +
 2 files changed, 147 insertions(+), 1 deletion(-)

diff --git a/drivers/dpll/dpll_netlink.c b/drivers/dpll/dpll_netlink.c
index e20daba6896a..97319a9e4667 100644
--- a/drivers/dpll/dpll_netlink.c
+++ b/drivers/dpll/dpll_netlink.c
@@ -212,6 +212,53 @@ dpll_msg_add_pin_direction(struct sk_buff *msg, struct 
dpll_pin *pin,
return 0;
 }
 
+static int
+dpll_msg_add_pin_phase_adjust(struct sk_buff *msg, struct dpll_pin *pin,
+ struct dpll_pin_ref *ref,
+ struct netlink_ext_ack *extack)
+{
+   const struct dpll_pin_ops *ops = dpll_pin_ops(ref);
+   struct dpll_device *dpll = ref->dpll;
+   s32 phase_adjust;
+   int ret;
+
+   if (!ops->phase_adjust_get)
+   return 0;
+   ret = ops->phase_adjust_get(pin, dpll_pin_on_dpll_priv(dpll, pin),
+   dpll, dpll_priv(dpll),
+   &phase_adjust, extack);
+   if (ret)
+   return ret;
+   if (nla_put_s32(msg, DPLL_A_PIN_PHASE_ADJUST, phase_adjust))
+   return -EMSGSIZE;
+
+   return 0;
+}
+
+static int
+dpll_msg_add_phase_offset(struct sk_buff *msg, struct dpll_pin *pin,
+ struct dpll_pin_ref *ref,
+ struct netlink_ext_ack *extack)
+{
+   const struct dpll_pin_ops *ops = dpll_pin_ops(ref);
+   struct dpll_device *dpll = ref->dpll;
+   s64 phase_offset;
+   int ret;
+
+   if (!ops->phase_offset_get)
+   return 0;
+   ret = ops->phase_offset_get(pin, dpll_pin_on_dpll_priv(dpll, pin),
+   dpll, dpll_priv(dpll), &phase_offset,
+   extack);
+   if (ret)
+   return ret;
+   if (nla_put_64bit(msg, DPLL_A_PIN_PHASE_OFFSET, sizeof(phase_offset),
+ &phase_offset, DPLL_A_PIN_PAD))
+   return -EMSGSIZE;
+
+   return 0;
+}
+
 static int
 dpll_msg_add_pin_freq(struct sk_buff *msg, struct dpll_pin *pin,
  struct dpll_pin_ref *ref, struct netlink_ext_ack *extack)
@@ -330,6 +377,9 @@ dpll_msg_add_pin_dplls(struct sk_buff *msg, struct dpll_pin 
*pin,
if (ret)
goto nest_cancel;
ret = dpll_msg_add_pin_direction(msg, pin, ref, extack);
+   if (ret)
+   goto nest_cancel;
+   ret = dpll_msg_add_phase_offset(msg, pin, ref, extack);
if (ret)
goto nest_cancel;
nla_nest_end(msg, attr);
@@ -377,6 +427,15 @@ dpll_cmd_pin_get_one(struct sk_buff *msg, struct dpll_pin 
*pin,
if (nla_put_u32(msg, DPLL_A_PIN_CAPABILITIES, prop->capabilities))
return -EMSGSIZE;
ret = dpll_msg_add_pin_freq(msg, pin, ref, extack);
+   if (ret)
+   return ret;
+   if (nla_put_s32(msg, DPLL_A_PIN_PHASE_ADJUST_MIN,
+   prop->phase_range.min))
+   return -EMSGSIZE;
+   if (nla_put_s32(msg, DPLL_A_PIN_PHASE_ADJUST_MAX,
+   prop->phase_range.max))
+   return -EMSGSIZE;
+   ret = dpll_msg_add_pin_phase_adjust(msg, pin, ref, extack);
if (ret)
return ret;
if (xa_empty(&pin->parent_refs))
@@ -416,7 +475,7 @@ dpll_device_get_one(struct dpll_device *dpll, struct 
sk_buff *msg,
if (nla_put_u32(msg, DPLL_A_TYPE, dpll->type))
return -EMSGSIZE;
 
-   return ret;
+   return 0;
 }
 
 static int
@@ -705,6 +764,70 @@ dpll_pin_direction_set(struct dpll_pin *pin, struct 
dpll_device *dpll,
return 0;
 }
 
+static int
+dpll_pin_phase_adj_set(struct dpll_pin *pin, struct nlattr *phase_adj_attr,
+  struct netlink_ext_ack *extack)
+{
+   struct dpll_pin_ref *ref, *failed;
+   const struct dpll_pin_ops *ops;
+   s32 phase_adj, old_phase_adj;
+   struct dpll_device *dpll;
+   unsigned long i;
+   int ret;
+
+   phase_adj = nla_get_s32(phase_adj_attr);
+   if (phase_adj > pin->prop->phase_range.max ||
+   phase_adj < pin->prop->phase_range.min) {
+   NL_SET_ERR_MSG(extack, "phase adjust value not supported");
+   return -EINVAL;
+   }
+   xa_for_each(&pin->dpll_refs, i, ref) {
+   ops = dpll_pin_ops(ref);
+   if (!ops->phase_adjust_set || !ops->phase_adjust_get)
+   return -EOPNOTSUPP;
+   }
+   ref = dpll_xa_ref_dpll_first(&pin->dpll_ref

[Intel-wired-lan] [PATCH net-next v3 4/5] ice: dpll: implement phase related callbacks

2023-10-06 Thread Arkadiusz Kubalewski
Implement new callback ops related to measurment and adjustment of
signal phase for pin-dpll in ice driver.

Signed-off-by: Arkadiusz Kubalewski 
---
 drivers/net/ethernet/intel/ice/ice_dpll.c | 224 +-
 drivers/net/ethernet/intel/ice/ice_dpll.h |  10 +-
 2 files changed, 230 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_dpll.c 
b/drivers/net/ethernet/intel/ice/ice_dpll.c
index 1faee9cb944d..6f7a2916f6c2 100644
--- a/drivers/net/ethernet/intel/ice/ice_dpll.c
+++ b/drivers/net/ethernet/intel/ice/ice_dpll.c
@@ -878,6 +878,203 @@ ice_dpll_output_direction(const struct dpll_pin *pin, 
void *pin_priv,
return 0;
 }
 
+/**
+ * ice_dpll_pin_phase_adjust_get - callback for get pin phase adjust value
+ * @pin: pointer to a pin
+ * @pin_priv: private data pointer passed on pin registration
+ * @dpll: registered dpll pointer
+ * @dpll_priv: private data pointer passed on dpll registration
+ * @phase_adjust: on success holds pin phase_adjust value
+ * @extack: error reporting
+ *
+ * Dpll subsystem callback. Handler for getting phase adjust value of a pin.
+ *
+ * Context: Acquires pf->dplls.lock
+ * Return:
+ * * 0 - success
+ * * negative - error
+ */
+static int
+ice_dpll_pin_phase_adjust_get(const struct dpll_pin *pin, void *pin_priv,
+ const struct dpll_device *dpll, void *dpll_priv,
+ s32 *phase_adjust,
+ struct netlink_ext_ack *extack)
+{
+   struct ice_dpll_pin *p = pin_priv;
+   struct ice_pf *pf = p->pf;
+
+   mutex_lock(&pf->dplls.lock);
+   *phase_adjust = p->phase_adjust;
+   mutex_unlock(&pf->dplls.lock);
+
+   return 0;
+}
+
+/**
+ * ice_dpll_pin_phase_adjust_set - helper for setting a pin phase adjust value
+ * @pin: pointer to a pin
+ * @pin_priv: private data pointer passed on pin registration
+ * @dpll: registered dpll pointer
+ * @dpll_priv: private data pointer passed on dpll registration
+ * @phase_adjust: phase_adjust to be set
+ * @extack: error reporting
+ * @type: type of a pin
+ *
+ * Helper for dpll subsystem callback. Handler for setting phase adjust value
+ * of a pin.
+ *
+ * Context: Acquires pf->dplls.lock
+ * Return:
+ * * 0 - success
+ * * negative - error
+ */
+static int
+ice_dpll_pin_phase_adjust_set(const struct dpll_pin *pin, void *pin_priv,
+ const struct dpll_device *dpll, void *dpll_priv,
+ s32 phase_adjust,
+ struct netlink_ext_ack *extack,
+ enum ice_dpll_pin_type type)
+{
+   struct ice_dpll_pin *p = pin_priv;
+   struct ice_dpll *d = dpll_priv;
+   struct ice_pf *pf = d->pf;
+   u8 flag, flags_en = 0;
+   int ret;
+
+   mutex_lock(&pf->dplls.lock);
+   if (phase_adjust == p->phase_adjust) {
+   mutex_unlock(&pf->dplls.lock);
+   return 0;
+   }
+   switch (type) {
+   case ICE_DPLL_PIN_TYPE_INPUT:
+   flag = ICE_AQC_SET_CGU_IN_CFG_FLG1_UPDATE_DELAY;
+   if (p->flags[0] & ICE_AQC_GET_CGU_IN_CFG_FLG2_ESYNC_EN)
+   flags_en |= ICE_AQC_SET_CGU_IN_CFG_FLG2_ESYNC_EN;
+   if (p->flags[0] & ICE_AQC_GET_CGU_IN_CFG_FLG2_INPUT_EN)
+   flags_en |= ICE_AQC_SET_CGU_IN_CFG_FLG2_INPUT_EN;
+   ret = ice_aq_set_input_pin_cfg(&pf->hw, p->idx, flag, flags_en,
+  0, phase_adjust);
+   break;
+   case ICE_DPLL_PIN_TYPE_OUTPUT:
+   flag = ICE_AQC_SET_CGU_OUT_CFG_UPDATE_PHASE;
+   if (p->flags[0] & ICE_AQC_GET_CGU_OUT_CFG_OUT_EN)
+   flag |= ICE_AQC_SET_CGU_OUT_CFG_OUT_EN;
+   if (p->flags[0] & ICE_AQC_GET_CGU_OUT_CFG_ESYNC_EN)
+   flag |= ICE_AQC_SET_CGU_OUT_CFG_ESYNC_EN;
+   ret = ice_aq_set_output_pin_cfg(&pf->hw, p->idx, flag, 0, 0,
+   phase_adjust);
+   break;
+   default:
+   ret = -EINVAL;
+   }
+   if (!ret)
+   p->phase_adjust = phase_adjust;
+   mutex_unlock(&pf->dplls.lock);
+   if (ret)
+   NL_SET_ERR_MSG_FMT(extack,
+  "err:%d %s failed to set pin phase_adjust:%d 
for pin:%u on dpll:%u\n",
+  ret,
+  ice_aq_str(pf->hw.adminq.sq_last_status),
+  phase_adjust, p->idx, d->dpll_idx);
+
+   return ret;
+}
+
+/**
+ * ice_dpll_input_phase_adjust_set - callback for set input pin phase adjust
+ * @pin: pointer to a pin
+ * @pin_priv: private data pointer passed on pin registration
+ * @dpll: registered dpll pointer
+ * @dpll_priv: private data pointer passed on dpll registration
+ * @phase_adjust: phase_adjust to be set
+ * @extack: error reporting
+ *
+ * Dpll subsystem callback. Wr

[Intel-wired-lan] [PATCH net-next v3 5/5] dpll: netlink/core: change pin frequency set behavior

2023-10-06 Thread Arkadiusz Kubalewski
Align the aproach of pin frequency set behavior with the approach
introduced with pin phase adjust set.
Fail the request if any of devices did not registered the callback ops.
If callback op on any pin's registered device fails, return error and
rollback the value to previous one.

Signed-off-by: Arkadiusz Kubalewski 
---
 drivers/dpll/dpll_netlink.c | 50 +
 1 file changed, 40 insertions(+), 10 deletions(-)

diff --git a/drivers/dpll/dpll_netlink.c b/drivers/dpll/dpll_netlink.c
index 97319a9e4667..8e5fea74aec1 100644
--- a/drivers/dpll/dpll_netlink.c
+++ b/drivers/dpll/dpll_netlink.c
@@ -615,30 +615,60 @@ static int
 dpll_pin_freq_set(struct dpll_pin *pin, struct nlattr *a,
  struct netlink_ext_ack *extack)
 {
-   u64 freq = nla_get_u64(a);
-   struct dpll_pin_ref *ref;
+   u64 freq = nla_get_u64(a), old_freq;
+   struct dpll_pin_ref *ref, *failed;
+   const struct dpll_pin_ops *ops;
+   struct dpll_device *dpll;
unsigned long i;
int ret;
 
if (!dpll_pin_is_freq_supported(pin, freq)) {
-   NL_SET_ERR_MSG_ATTR(extack, a, "frequency is not supported by 
the device");
+   NL_SET_ERR_MSG_ATTR(extack, a,
+   "frequency is not supported by the device");
return -EINVAL;
}
-
xa_for_each(&pin->dpll_refs, i, ref) {
-   const struct dpll_pin_ops *ops = dpll_pin_ops(ref);
-   struct dpll_device *dpll = ref->dpll;
-
-   if (!ops->frequency_set)
+   ops = dpll_pin_ops(ref);
+   if (!ops->frequency_set || !ops->frequency_get)
return -EOPNOTSUPP;
+   }
+   ref = dpll_xa_ref_dpll_first(&pin->dpll_refs);
+   ops = dpll_pin_ops(ref);
+   dpll = ref->dpll;
+   ret = ops->frequency_get(pin, dpll_pin_on_dpll_priv(dpll, pin), dpll,
+dpll_priv(dpll), &old_freq, extack);
+   if (ret) {
+   NL_SET_ERR_MSG(extack, "unable to get old frequency value");
+   return ret;
+   }
+   if (freq == old_freq)
+   return 0;
+
+   xa_for_each(&pin->dpll_refs, i, ref) {
+   ops = dpll_pin_ops(ref);
+   dpll = ref->dpll;
ret = ops->frequency_set(pin, dpll_pin_on_dpll_priv(dpll, pin),
 dpll, dpll_priv(dpll), freq, extack);
-   if (ret)
-   return ret;
+   if (ret) {
+   failed = ref;
+   goto rollback;
+   }
}
__dpll_pin_change_ntf(pin);
 
return 0;
+
+rollback:
+   xa_for_each(&pin->dpll_refs, i, ref) {
+   if (ref == failed)
+   break;
+   ops = dpll_pin_ops(ref);
+   dpll = ref->dpll;
+   if (ops->frequency_set(pin, dpll_pin_on_dpll_priv(dpll, pin),
+  dpll, dpll_priv(dpll), old_freq, extack))
+   NL_SET_ERR_MSG(extack, "set frequency rollback failed");
+   }
+   return ret;
 }
 
 static int
-- 
2.38.1

___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan


Re: [Intel-wired-lan] [PATCH net] i40e: prevent crash on probe if hw registers have invalid values

2023-10-06 Thread Simon Horman
On Fri, Oct 06, 2023 at 01:11:39PM +0200, Michal Schmidt wrote:
> The hardware provides the indexes of the first and the last available
> queue and VF. From the indexes, the driver calculates the numbers of
> queues and VFs. In theory, a faulty device might say the last index is
> smaller than the first index. In that case, the driver's calculation
> would underflow, it would attempt to write to non-existent registers
> outside of the ioremapped range and crash.
> 
> I ran into this not by having a faulty device, but by an operator error.
> I accidentally ran a QE test meant for i40e devices on an ice device.
> The test used 'echo i40e > /sys/...ice PCI device.../driver_override',
> bound the driver to the device and crashed in one of the wr32 calls in
> i40e_clear_hw.
> 
> Add checks to prevent underflows in the calculations of num_queues and
> num_vfs. With this fix, the wrong device probing reports errors and
> returns a failure without crashing.
> 
> Fixes: 838d41d92a90 ("i40e: clear all queues and interrupts")
> Signed-off-by: Michal Schmidt 

Reviewed-by: Simon Horman 

___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan


Re: [Intel-wired-lan] [PATCH net-next v3 2/5] dpll: spec: add support for pin-dpll signal phase offset/adjust

2023-10-06 Thread Jiri Pirko
Fri, Oct 06, 2023 at 01:40:58PM CEST, arkadiusz.kubalew...@intel.com wrote:
>Add attributes for providing the user with:
>- measurement of signals phase offset between pin and dpll
>- ability to adjust the phase of pin signal
>
>Signed-off-by: Arkadiusz Kubalewski 
>---
> Documentation/netlink/specs/dpll.yaml | 33 ++-
> drivers/dpll/dpll_nl.c|  8 ---
> drivers/dpll/dpll_nl.h|  2 +-
> include/uapi/linux/dpll.h |  8 ++-
> 4 files changed, 45 insertions(+), 6 deletions(-)
>
>diff --git a/Documentation/netlink/specs/dpll.yaml 
>b/Documentation/netlink/specs/dpll.yaml
>index 8b86b28b47a6..dc057494101f 100644
>--- a/Documentation/netlink/specs/dpll.yaml
>+++ b/Documentation/netlink/specs/dpll.yaml
>@@ -1,7 +1,7 @@
> # SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)
> 
> name: dpll
>-
>+version: 2

I'm confused. Didn't you say you'll remove this? If not, my question
from v1 still stands.

___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan


Re: [Intel-wired-lan] [PATCH net-next v3 4/5] ice: dpll: implement phase related callbacks

2023-10-06 Thread Simon Horman
On Fri, Oct 06, 2023 at 01:41:00PM +0200, Arkadiusz Kubalewski wrote:
> Implement new callback ops related to measurment and adjustment of
> signal phase for pin-dpll in ice driver.
> 
> Signed-off-by: Arkadiusz Kubalewski 

Hi Arkadiusz,

some minor feedback from my side.

If you do end up re-spinning the series, please consider
running checkpatch.pl --codespell.

> ---
>  drivers/net/ethernet/intel/ice/ice_dpll.c | 224 +-
>  drivers/net/ethernet/intel/ice/ice_dpll.h |  10 +-
>  2 files changed, 230 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/ethernet/intel/ice/ice_dpll.c 
> b/drivers/net/ethernet/intel/ice/ice_dpll.c

...

> +/**
> + * ice_dpll_phase_offset_get - callback for get dpll phase shift value
> + * @pin: pointer to a pin
> + * @pin_priv: private data pointer passed on pin registration
> + * @dpll: registered dpll pointer
> + * @dpll_priv: private data pointer passed on dpll registration
> + * @phase_adjust: on success holds pin phase_adjust value

nit: The parameter is called phase_offset, not phase_adjust in the code below

> + * @extack: error reporting
> + *
> + * Dpll subsystem callback. Handler for getting phase shift value between
> + * dpll's input and output.
> + *
> + * Context: Acquires pf->dplls.lock
> + * Return:
> + * * 0 - success
> + * * negative - error
> + */
> +static int
> +ice_dpll_phase_offset_get(const struct dpll_pin *pin, void *pin_priv,
> +   const struct dpll_device *dpll, void *dpll_priv,
> +   s64 *phase_offset, struct netlink_ext_ack *extack)
> +{
> + struct ice_dpll *d = dpll_priv;
> + struct ice_pf *pf = d->pf;
> +
> + mutex_lock(&pf->dplls.lock);
> + if (d->active_input == pin)
> + *phase_offset = d->phase_offset * ICE_DPLL_PHASE_OFFSET_FACTOR;
> + else
> + *phase_offset = 0;
> + mutex_unlock(&pf->dplls.lock);
> +
> + return 0;
> +}
> +
>  /**
>   * ice_dpll_rclk_state_on_pin_set - set a state on rclk pin
>   * @pin: pointer to a pin

...

> @@ -1656,6 +1867,15 @@ ice_dpll_init_info_direct_pins(struct ice_pf *pf,
>   return ret;
>   pins[i].prop.capabilities |=
>   DPLL_PIN_CAPABILITIES_PRIORITY_CAN_CHANGE;
> + pins[i].prop.phase_range.min =
> + pf->dplls.input_phase_adj_max;
> + pins[i].prop.phase_range.max =
> + -pf->dplls.input_phase_adj_max;
> + } else {
> + pins[i].prop.phase_range.min =
> + pf->dplls.output_phase_adj_max,

nit: It probably doesn't make any difference, but perhaps ',' should be ';'.

As flagged by clang-16 with -Wcomma

> + pins[i].prop.phase_range.max =
> + -pf->dplls.output_phase_adj_max;
>   }
>   pins[i].prop.capabilities |=
>   DPLL_PIN_CAPABILITIES_STATE_CAN_CHANGE;

...
___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan


Re: [Intel-wired-lan] [PATCH net-next v3 5/5] dpll: netlink/core: change pin frequency set behavior

2023-10-06 Thread Jiri Pirko
Fri, Oct 06, 2023 at 01:41:01PM CEST, arkadiusz.kubalew...@intel.com wrote:
>Align the aproach of pin frequency set behavior with the approach
>introduced with pin phase adjust set.
>Fail the request if any of devices did not registered the callback ops.
>If callback op on any pin's registered device fails, return error and
>rollback the value to previous one.
>
>Signed-off-by: Arkadiusz Kubalewski 
>---
> drivers/dpll/dpll_netlink.c | 50 +
> 1 file changed, 40 insertions(+), 10 deletions(-)
>
>diff --git a/drivers/dpll/dpll_netlink.c b/drivers/dpll/dpll_netlink.c
>index 97319a9e4667..8e5fea74aec1 100644
>--- a/drivers/dpll/dpll_netlink.c
>+++ b/drivers/dpll/dpll_netlink.c
>@@ -615,30 +615,60 @@ static int
> dpll_pin_freq_set(struct dpll_pin *pin, struct nlattr *a,
> struct netlink_ext_ack *extack)
> {
>-  u64 freq = nla_get_u64(a);
>-  struct dpll_pin_ref *ref;
>+  u64 freq = nla_get_u64(a), old_freq;
>+  struct dpll_pin_ref *ref, *failed;
>+  const struct dpll_pin_ops *ops;
>+  struct dpll_device *dpll;
>   unsigned long i;
>   int ret;
> 
>   if (!dpll_pin_is_freq_supported(pin, freq)) {
>-  NL_SET_ERR_MSG_ATTR(extack, a, "frequency is not supported by 
>the device");
>+  NL_SET_ERR_MSG_ATTR(extack, a,
>+  "frequency is not supported by the device");

No need for this wrapping. Seems unrelated to the rest of the patch
anyway.


>   return -EINVAL;
>   }
>-

No need for this too.



>   xa_for_each(&pin->dpll_refs, i, ref) {
>-  const struct dpll_pin_ops *ops = dpll_pin_ops(ref);
>-  struct dpll_device *dpll = ref->dpll;
>-
>-  if (!ops->frequency_set)
>+  ops = dpll_pin_ops(ref);
>+  if (!ops->frequency_set || !ops->frequency_get)
>   return -EOPNOTSUPP;

Add an extack msg while you are at it - could be a separate patch.


>+  }
>+  ref = dpll_xa_ref_dpll_first(&pin->dpll_refs);
>+  ops = dpll_pin_ops(ref);
>+  dpll = ref->dpll;
>+  ret = ops->frequency_get(pin, dpll_pin_on_dpll_priv(dpll, pin), dpll,
>+   dpll_priv(dpll), &old_freq, extack);
>+  if (ret) {
>+  NL_SET_ERR_MSG(extack, "unable to get old frequency value");
>+  return ret;
>+  }
>+  if (freq == old_freq)
>+  return 0;
>+
>+  xa_for_each(&pin->dpll_refs, i, ref) {
>+  ops = dpll_pin_ops(ref);
>+  dpll = ref->dpll;
>   ret = ops->frequency_set(pin, dpll_pin_on_dpll_priv(dpll, pin),
>dpll, dpll_priv(dpll), freq, extack);
>-  if (ret)
>-  return ret;
>+  if (ret) {
>+  failed = ref;

Extack msg.


>+  goto rollback;
>+  }
>   }
>   __dpll_pin_change_ntf(pin);
> 
>   return 0;
>+
>+rollback:
>+  xa_for_each(&pin->dpll_refs, i, ref) {
>+  if (ref == failed)
>+  break;
>+  ops = dpll_pin_ops(ref);
>+  dpll = ref->dpll;
>+  if (ops->frequency_set(pin, dpll_pin_on_dpll_priv(dpll, pin),
>+ dpll, dpll_priv(dpll), old_freq, extack))
>+  NL_SET_ERR_MSG(extack, "set frequency rollback failed");
>+  }
>+  return ret;
> }
> 
> static int
>-- 
>2.38.1
>
___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan


Re: [Intel-wired-lan] [PATCH net-next v3 3/5] dpll: netlink/core: add support for pin-dpll signal phase offset/adjust

2023-10-06 Thread Jiri Pirko
Fri, Oct 06, 2023 at 01:40:59PM CEST, arkadiusz.kubalew...@intel.com wrote:
>Add callback ops for pin-dpll phase measurment.
>Add callback for pin signal phase adjustment.
>Add min and max phase adjustment values to pin proprties.
>Invoke callbacks in dpll_netlink.c when filling the pin details to
>provide user with phase related attribute values.
>
>Signed-off-by: Arkadiusz Kubalewski 
>---
> drivers/dpll/dpll_netlink.c | 130 +++-
> include/linux/dpll.h|  18 +
> 2 files changed, 147 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/dpll/dpll_netlink.c b/drivers/dpll/dpll_netlink.c
>index e20daba6896a..97319a9e4667 100644
>--- a/drivers/dpll/dpll_netlink.c
>+++ b/drivers/dpll/dpll_netlink.c
>@@ -212,6 +212,53 @@ dpll_msg_add_pin_direction(struct sk_buff *msg, struct 
>dpll_pin *pin,
>   return 0;
> }
> 
>+static int
>+dpll_msg_add_pin_phase_adjust(struct sk_buff *msg, struct dpll_pin *pin,
>+struct dpll_pin_ref *ref,
>+struct netlink_ext_ack *extack)
>+{
>+  const struct dpll_pin_ops *ops = dpll_pin_ops(ref);
>+  struct dpll_device *dpll = ref->dpll;
>+  s32 phase_adjust;
>+  int ret;
>+
>+  if (!ops->phase_adjust_get)
>+  return 0;
>+  ret = ops->phase_adjust_get(pin, dpll_pin_on_dpll_priv(dpll, pin),
>+  dpll, dpll_priv(dpll),
>+  &phase_adjust, extack);
>+  if (ret)
>+  return ret;
>+  if (nla_put_s32(msg, DPLL_A_PIN_PHASE_ADJUST, phase_adjust))
>+  return -EMSGSIZE;
>+
>+  return 0;
>+}
>+
>+static int
>+dpll_msg_add_phase_offset(struct sk_buff *msg, struct dpll_pin *pin,
>+struct dpll_pin_ref *ref,
>+struct netlink_ext_ack *extack)
>+{
>+  const struct dpll_pin_ops *ops = dpll_pin_ops(ref);
>+  struct dpll_device *dpll = ref->dpll;
>+  s64 phase_offset;
>+  int ret;
>+
>+  if (!ops->phase_offset_get)
>+  return 0;
>+  ret = ops->phase_offset_get(pin, dpll_pin_on_dpll_priv(dpll, pin),
>+  dpll, dpll_priv(dpll), &phase_offset,
>+  extack);
>+  if (ret)
>+  return ret;
>+  if (nla_put_64bit(msg, DPLL_A_PIN_PHASE_OFFSET, sizeof(phase_offset),
>+&phase_offset, DPLL_A_PIN_PAD))
>+  return -EMSGSIZE;
>+
>+  return 0;
>+}
>+
> static int
> dpll_msg_add_pin_freq(struct sk_buff *msg, struct dpll_pin *pin,
> struct dpll_pin_ref *ref, struct netlink_ext_ack *extack)
>@@ -330,6 +377,9 @@ dpll_msg_add_pin_dplls(struct sk_buff *msg, struct 
>dpll_pin *pin,
>   if (ret)
>   goto nest_cancel;
>   ret = dpll_msg_add_pin_direction(msg, pin, ref, extack);
>+  if (ret)
>+  goto nest_cancel;
>+  ret = dpll_msg_add_phase_offset(msg, pin, ref, extack);
>   if (ret)
>   goto nest_cancel;
>   nla_nest_end(msg, attr);
>@@ -377,6 +427,15 @@ dpll_cmd_pin_get_one(struct sk_buff *msg, struct dpll_pin 
>*pin,
>   if (nla_put_u32(msg, DPLL_A_PIN_CAPABILITIES, prop->capabilities))
>   return -EMSGSIZE;
>   ret = dpll_msg_add_pin_freq(msg, pin, ref, extack);
>+  if (ret)
>+  return ret;
>+  if (nla_put_s32(msg, DPLL_A_PIN_PHASE_ADJUST_MIN,
>+  prop->phase_range.min))
>+  return -EMSGSIZE;
>+  if (nla_put_s32(msg, DPLL_A_PIN_PHASE_ADJUST_MAX,
>+  prop->phase_range.max))
>+  return -EMSGSIZE;
>+  ret = dpll_msg_add_pin_phase_adjust(msg, pin, ref, extack);
>   if (ret)
>   return ret;
>   if (xa_empty(&pin->parent_refs))
>@@ -416,7 +475,7 @@ dpll_device_get_one(struct dpll_device *dpll, struct 
>sk_buff *msg,
>   if (nla_put_u32(msg, DPLL_A_TYPE, dpll->type))
>   return -EMSGSIZE;
> 
>-  return ret;
>+  return 0;
> }
> 
> static int
>@@ -705,6 +764,70 @@ dpll_pin_direction_set(struct dpll_pin *pin, struct 
>dpll_device *dpll,
>   return 0;
> }
> 
>+static int
>+dpll_pin_phase_adj_set(struct dpll_pin *pin, struct nlattr *phase_adj_attr,
>+ struct netlink_ext_ack *extack)
>+{
>+  struct dpll_pin_ref *ref, *failed;
>+  const struct dpll_pin_ops *ops;
>+  s32 phase_adj, old_phase_adj;
>+  struct dpll_device *dpll;
>+  unsigned long i;
>+  int ret;
>+
>+  phase_adj = nla_get_s32(phase_adj_attr);
>+  if (phase_adj > pin->prop->phase_range.max ||
>+  phase_adj < pin->prop->phase_range.min) {
>+  NL_SET_ERR_MSG(extack, "phase adjust value not supported");
>+  return -EINVAL;
>+  }
>+  xa_for_each(&pin->dpll_refs, i, ref) {
>+  ops = dpll_pin_ops(ref);
>+  if (!ops->phase_adjust_set ||

Re: [Intel-wired-lan] [PATCH net-next v3 4/5] ice: dpll: implement phase related callbacks

2023-10-06 Thread Jiri Pirko
Fri, Oct 06, 2023 at 02:33:34PM CEST, ho...@kernel.org wrote:
>On Fri, Oct 06, 2023 at 01:41:00PM +0200, Arkadiusz Kubalewski wrote:
>> Implement new callback ops related to measurment and adjustment of
>> signal phase for pin-dpll in ice driver.
>> 
>> Signed-off-by: Arkadiusz Kubalewski 
>
>Hi Arkadiusz,
>
>some minor feedback from my side.
>
>If you do end up re-spinning the series, please consider
>running checkpatch.pl --codespell.
>
>> ---
>>  drivers/net/ethernet/intel/ice/ice_dpll.c | 224 +-
>>  drivers/net/ethernet/intel/ice/ice_dpll.h |  10 +-
>>  2 files changed, 230 insertions(+), 4 deletions(-)
>> 
>> diff --git a/drivers/net/ethernet/intel/ice/ice_dpll.c 
>> b/drivers/net/ethernet/intel/ice/ice_dpll.c
>
>...
>
>> +/**
>> + * ice_dpll_phase_offset_get - callback for get dpll phase shift value
>> + * @pin: pointer to a pin
>> + * @pin_priv: private data pointer passed on pin registration
>> + * @dpll: registered dpll pointer
>> + * @dpll_priv: private data pointer passed on dpll registration
>> + * @phase_adjust: on success holds pin phase_adjust value
>
>nit: The parameter is called phase_offset, not phase_adjust in the code below

Yeah, the non-sense static function docs and how buggy they are. Nobody
reads them anyway. Same old story for ice I guess


>
>> + * @extack: error reporting
>> + *
>> + * Dpll subsystem callback. Handler for getting phase shift value between
>> + * dpll's input and output.
>> + *
>> + * Context: Acquires pf->dplls.lock
>> + * Return:
>> + * * 0 - success
>> + * * negative - error
>> + */
>> +static int
>> +ice_dpll_phase_offset_get(const struct dpll_pin *pin, void *pin_priv,
>> +  const struct dpll_device *dpll, void *dpll_priv,
>> +  s64 *phase_offset, struct netlink_ext_ack *extack)
>> +{
>> +struct ice_dpll *d = dpll_priv;
>> +struct ice_pf *pf = d->pf;
>> +
>> +mutex_lock(&pf->dplls.lock);
>> +if (d->active_input == pin)
>> +*phase_offset = d->phase_offset * ICE_DPLL_PHASE_OFFSET_FACTOR;
>> +else
>> +*phase_offset = 0;
>> +mutex_unlock(&pf->dplls.lock);
>> +
>> +return 0;
>> +}
>> +
>>  /**
>>   * ice_dpll_rclk_state_on_pin_set - set a state on rclk pin
>>   * @pin: pointer to a pin
>
>...
>
>> @@ -1656,6 +1867,15 @@ ice_dpll_init_info_direct_pins(struct ice_pf *pf,
>>  return ret;
>>  pins[i].prop.capabilities |=
>>  DPLL_PIN_CAPABILITIES_PRIORITY_CAN_CHANGE;
>> +pins[i].prop.phase_range.min =
>> +pf->dplls.input_phase_adj_max;
>> +pins[i].prop.phase_range.max =
>> +-pf->dplls.input_phase_adj_max;
>> +} else {
>> +pins[i].prop.phase_range.min =
>> +pf->dplls.output_phase_adj_max,
>
>nit: It probably doesn't make any difference, but perhaps ',' should be ';'.
>
>As flagged by clang-16 with -Wcomma
>
>> +pins[i].prop.phase_range.max =
>> +-pf->dplls.output_phase_adj_max;
>>  }
>>  pins[i].prop.capabilities |=
>>  DPLL_PIN_CAPABILITIES_STATE_CAN_CHANGE;
>
>...
___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan


Re: [Intel-wired-lan] [PATCH net] ixgbe: fix crash with empty VF macvlan list

2023-10-06 Thread Dan Carpenter
On Fri, Oct 06, 2023 at 01:16:27PM +0200, Simon Horman wrote:
> On Thu, Oct 05, 2023 at 04:57:02PM +0300, Dan Carpenter wrote:
> > The adapter->vf_mvs.l list needs to be initialized even if the list is
> > empty.  Otherwise it will lead to crashes.
> > 
> > Fixes: c6bda30a06d9 ("ixgbe: Reconfigure SR-IOV Init")
> 
> Hi Dan,
> 
> I see that the patch cited above added the line you are changing.
> But it also seems to me that patch was moving it from elsewhere.
> 
> Perhaps I am mistaken, but I wonder if this is a better tag.
> 
> Fixes: a1cbb15c1397 ("ixgbe: Add macvlan support for VF")
> 

Yeah.  You're right.  I'll resend.


> > Signed-off-by: Dan Carpenter 
> > ---
> >  drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c 
> > b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
> > index a703ba975205..9cfdfa8a4355 100644
> > --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
> > +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
> > @@ -28,6 +28,9 @@ static inline void ixgbe_alloc_vf_macvlans(struct 
> > ixgbe_adapter *adapter,
> > struct vf_macvlans *mv_list;
> > int num_vf_macvlans, i;
> >  
> > +   /* Initialize list of VF macvlans */
> > +   INIT_LIST_HEAD(&adapter->vf_mvs.l);
> > +
> > num_vf_macvlans = hw->mac.num_rar_entries -
> >   (IXGBE_MAX_PF_MACVLANS + 1 + num_vfs);
> > if (!num_vf_macvlans)
> > @@ -36,8 +39,6 @@ static inline void ixgbe_alloc_vf_macvlans(struct 
> > ixgbe_adapter *adapter,
> > mv_list = kcalloc(num_vf_macvlans, sizeof(struct vf_macvlans),
> >   GFP_KERNEL);
> > if (mv_list) {
> 
> I'm not sure it it is worth it, but perhaps more conventional error
> handling could be used here:
> 
>   if (!mv_list)
>   return;
> 
>   for (i = 0; i < num_vf_macvlans; i++) {
>   ...

I mean error handling is always cleaner than success handling but it's
probably not worth cleaning up in old code.  I say it's not worth
cleaning up old code and yet I secretly reversed two if statements like
this yesterday.  :P
https://lore.kernel.org/all/d9da4c97-0da9-499f-9a21-1f8e3f148dc1@moroto.mountain/
It really is nicer, yes.  But it just makes the patch too noisy.

regards,
dan carpenter

___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan


[Intel-wired-lan] [PATCH net v2] ixgbe: fix crash with empty VF macvlan list

2023-10-06 Thread Dan Carpenter
The adapter->vf_mvs.l list needs to be initialized even if the list is
empty.  Otherwise it will lead to crashes.

Fixes: a1cbb15c1397 ("ixgbe: Add macvlan support for VF")
Signed-off-by: Dan Carpenter 
---
v2: Use the correct fixes tag.  Thanks, Simon.

 drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
index a703ba975205..9cfdfa8a4355 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
@@ -28,6 +28,9 @@ static inline void ixgbe_alloc_vf_macvlans(struct 
ixgbe_adapter *adapter,
struct vf_macvlans *mv_list;
int num_vf_macvlans, i;
 
+   /* Initialize list of VF macvlans */
+   INIT_LIST_HEAD(&adapter->vf_mvs.l);
+
num_vf_macvlans = hw->mac.num_rar_entries -
  (IXGBE_MAX_PF_MACVLANS + 1 + num_vfs);
if (!num_vf_macvlans)
@@ -36,8 +39,6 @@ static inline void ixgbe_alloc_vf_macvlans(struct 
ixgbe_adapter *adapter,
mv_list = kcalloc(num_vf_macvlans, sizeof(struct vf_macvlans),
  GFP_KERNEL);
if (mv_list) {
-   /* Initialize list of VF macvlans */
-   INIT_LIST_HEAD(&adapter->vf_mvs.l);
for (i = 0; i < num_vf_macvlans; i++) {
mv_list[i].vf = -1;
mv_list[i].free = true;
-- 
2.39.2
___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan


Re: [Intel-wired-lan] [PATCH net] ixgbe: fix crash with empty VF macvlan list

2023-10-06 Thread Simon Horman
On Fri, Oct 06, 2023 at 03:49:39PM +0300, Dan Carpenter wrote:
> On Fri, Oct 06, 2023 at 01:16:27PM +0200, Simon Horman wrote:
> > On Thu, Oct 05, 2023 at 04:57:02PM +0300, Dan Carpenter wrote:
> > > The adapter->vf_mvs.l list needs to be initialized even if the list is
> > > empty.  Otherwise it will lead to crashes.
> > > 
> > > Fixes: c6bda30a06d9 ("ixgbe: Reconfigure SR-IOV Init")
> > 
> > Hi Dan,
> > 
> > I see that the patch cited above added the line you are changing.
> > But it also seems to me that patch was moving it from elsewhere.
> > 
> > Perhaps I am mistaken, but I wonder if this is a better tag.
> > 
> > Fixes: a1cbb15c1397 ("ixgbe: Add macvlan support for VF")
> > 
> 
> Yeah.  You're right.  I'll resend.

Thanks!

> > > Signed-off-by: Dan Carpenter 
> > > ---
> > >  drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 5 +++--
> > >  1 file changed, 3 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c 
> > > b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
> > > index a703ba975205..9cfdfa8a4355 100644
> > > --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
> > > +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
> > > @@ -28,6 +28,9 @@ static inline void ixgbe_alloc_vf_macvlans(struct 
> > > ixgbe_adapter *adapter,
> > >   struct vf_macvlans *mv_list;
> > >   int num_vf_macvlans, i;
> > >  
> > > + /* Initialize list of VF macvlans */
> > > + INIT_LIST_HEAD(&adapter->vf_mvs.l);
> > > +
> > >   num_vf_macvlans = hw->mac.num_rar_entries -
> > > (IXGBE_MAX_PF_MACVLANS + 1 + num_vfs);
> > >   if (!num_vf_macvlans)
> > > @@ -36,8 +39,6 @@ static inline void ixgbe_alloc_vf_macvlans(struct 
> > > ixgbe_adapter *adapter,
> > >   mv_list = kcalloc(num_vf_macvlans, sizeof(struct vf_macvlans),
> > > GFP_KERNEL);
> > >   if (mv_list) {
> > 
> > I'm not sure it it is worth it, but perhaps more conventional error
> > handling could be used here:
> > 
> > if (!mv_list)
> > return;
> > 
> > for (i = 0; i < num_vf_macvlans; i++) {
> > ...
> 
> I mean error handling is always cleaner than success handling but it's
> probably not worth cleaning up in old code.  I say it's not worth
> cleaning up old code and yet I secretly reversed two if statements like
> this yesterday.  :P
> https://lore.kernel.org/all/d9da4c97-0da9-499f-9a21-1f8e3f148dc1@moroto.mountain/
> It really is nicer, yes.  But it just makes the patch too noisy.

Yeah, I'm also worried about the noise in this case.
___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan


Re: [Intel-wired-lan] [PATCH net v2] ixgbe: fix crash with empty VF macvlan list

2023-10-06 Thread Simon Horman
On Fri, Oct 06, 2023 at 03:53:09PM +0300, Dan Carpenter wrote:
> The adapter->vf_mvs.l list needs to be initialized even if the list is
> empty.  Otherwise it will lead to crashes.
> 
> Fixes: a1cbb15c1397 ("ixgbe: Add macvlan support for VF")
> Signed-off-by: Dan Carpenter 
> ---
> v2: Use the correct fixes tag.  Thanks, Simon.

Reviewed-by: Simon Horman 
___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan


Re: [Intel-wired-lan] [PATCH net-next v3 2/5] dpll: spec: add support for pin-dpll signal phase offset/adjust

2023-10-06 Thread Jakub Kicinski
On Fri, 6 Oct 2023 14:30:00 +0200 Jiri Pirko wrote:
> >+version: 2  
> 
> I'm confused. Didn't you say you'll remove this? If not, my question
> from v1 still stands.

Perhaps we should dis-allow setting version in non-genetlink-legacy
specs? I thought it may be a useful thing to someone, at some point,
but so far the scoreboard is: legit uses: 0, confused uses: 1 :S

Thoughts?
___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan


[Intel-wired-lan] [tnguy-next-queue:40GbE] BUILD SUCCESS 190c3ad68f389ef06e82c3a08c1d0bea57379d93

2023-10-06 Thread kernel test robot
tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue.git 40GbE
branch HEAD: 190c3ad68f389ef06e82c3a08c1d0bea57379d93  i40e: Move DDP specific 
macros and structures to i40e_ddp.c

elapsed time: 1305m

configs tested: 115
configs skipped: 2

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  
arc   randconfig-001-20231006   gcc  
arm  allmodconfig   gcc  
arm   allnoconfig   gcc  
arm  allyesconfig   gcc  
arm at91_dt_defconfig   gcc  
arm defconfig   gcc  
arm  moxart_defconfig   clang
arm   randconfig-001-20231006   gcc  
arm   sama5_defconfig   gcc  
arm64allmodconfig   gcc  
arm64 allnoconfig   gcc  
arm64allyesconfig   gcc  
arm64   defconfig   gcc  
csky allmodconfig   gcc  
csky  allnoconfig   gcc  
csky allyesconfig   gcc  
cskydefconfig   gcc  
i386 allmodconfig   gcc  
i386  allnoconfig   gcc  
i386 allyesconfig   gcc  
i386 buildonly-randconfig-001-20231006   gcc  
i386 buildonly-randconfig-002-20231006   gcc  
i386 buildonly-randconfig-003-20231006   gcc  
i386 buildonly-randconfig-004-20231006   gcc  
i386 buildonly-randconfig-005-20231006   gcc  
i386 buildonly-randconfig-006-20231006   gcc  
i386  debian-10.3   gcc  
i386defconfig   gcc  
i386  randconfig-001-20231006   gcc  
i386  randconfig-002-20231006   gcc  
i386  randconfig-003-20231006   gcc  
i386  randconfig-004-20231006   gcc  
i386  randconfig-005-20231006   gcc  
i386  randconfig-006-20231006   gcc  
loongarchallmodconfig   gcc  
loongarch allnoconfig   gcc  
loongarchallyesconfig   gcc  
loongarch   defconfig   gcc  
loongarch randconfig-001-20231006   gcc  
m68k allmodconfig   gcc  
m68k  allnoconfig   gcc  
m68k allyesconfig   gcc  
m68kdefconfig   gcc  
microblaze   allmodconfig   gcc  
microblazeallnoconfig   gcc  
microblaze   allyesconfig   gcc  
microblaze  defconfig   gcc  
mips allmodconfig   gcc  
mips  allnoconfig   gcc  
mips allyesconfig   gcc  
mips loongson1b_defconfig   gcc  
nios2allmodconfig   gcc  
nios2 allnoconfig   gcc  
nios2allyesconfig   gcc  
nios2   defconfig   gcc  
openrisc allmodconfig   gcc  
openrisc  allnoconfig   gcc  
openrisc allyesconfig   gcc  
openriscdefconfig   gcc  
parisc   allmodconfig   gcc  
pariscallnoconfig   gcc  
parisc   allyesconfig   gcc  
parisc  defconfig   gcc  
parisc64defconfig   gcc  
powerpc  allmodconfig   gcc  
powerpc   allnoconfig   gcc  
powerpc  allyesconfig   gcc  
powerpcmvme5100_defconfig   clang
riscvallmodconfig   gcc  
riscv allnoconfig   gcc  
riscvallyesconfig   gcc  
riscv   defconfig   gcc  
riscv  rv32_defconfig   gcc  
s390 allmodconfig   gcc  
s390  allnoconfig   gcc  
s390 allyesconfig   gcc  
s390defconfig   gcc  
sh   allmodconfig   gcc  
sh

Re: [Intel-wired-lan] [PATCH iwl-next v1 0/2] intel: format specifier cleanups

2023-10-06 Thread Romanowski, Rafal
> -Original Message-
> From: Intel-wired-lan  On Behalf Of
> Simon Horman
> Sent: Wednesday, October 4, 2023 3:46 PM
> To: Brandeburg, Jesse 
> Cc: net...@vger.kernel.org; Christophe JAILLET
> ; intel-wired-...@lists.osuosl.org; Kitszel,
> Przemyslaw 
> Subject: Re: [Intel-wired-lan] [PATCH iwl-next v1 0/2] intel: format specifier
> cleanups
> 
> On Tue, Oct 03, 2023 at 11:36:01AM -0700, Jesse Brandeburg wrote:
> > Clean up some warnings from the W=1 build which moves the intel
> > directory back to "clean" state. This mostly involved converting to
> > using ethtool_sprintf where appropriate and kasprintf in other places.
> >
> > The second patch goes the extra mile and cleans up -Wformat=2 warnings
> > as suggested by Alex Lobakin, since those flags will likely be turned
> > on as well.
> >
> > gcc-12 runs clean after these changes, and clang-15 still has some
> > minor complaints as mentioned in patch-2.
> >
> > Jesse Brandeburg (2):
> >   intel: fix string truncation warnings
> >   intel: fix format warnings
> >
> >  .../net/ethernet/intel/i40e/i40e_ethtool.c|  6 ++-
> >  .../net/ethernet/intel/iavf/iavf_ethtool.c|  8 ++--
> >  .../net/ethernet/intel/iavf/iavf_virtchnl.c   | 22 ---
> >  drivers/net/ethernet/intel/ice/ice_ethtool.c  |  7 ++--
> >  drivers/net/ethernet/intel/ice/ice_ptp.c  |  4 +-
> >  drivers/net/ethernet/intel/igb/igb_ethtool.c  |  4 +-
> >  drivers/net/ethernet/intel/igb/igb_main.c | 37 +--
> >  drivers/net/ethernet/intel/igc/igc_ethtool.c  |  5 ++-
> > .../net/ethernet/intel/ixgbe/ixgbe_ethtool.c  |  4 +-
> >  9 files changed, 46 insertions(+), 51 deletions(-)
> 
> For series,
> 
> 
> Reviewed-by: Simon Horman 
> Tested-by: Simon Horman  # build-tested
> 
> ___
> Intel-wired-lan mailing list
> Intel-wired-lan@osuosl.org
> https://lists.osuosl.org/mailman/listinfo/intel-wired-lan


Tested-by: Rafal Romanowski 



___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan


Re: [Intel-wired-lan] [PATCH net-next v3 2/5] dpll: spec: add support for pin-dpll signal phase offset/adjust

2023-10-06 Thread Jiri Pirko
Fri, Oct 06, 2023 at 04:55:36PM CEST, k...@kernel.org wrote:
>On Fri, 6 Oct 2023 14:30:00 +0200 Jiri Pirko wrote:
>> >+version: 2  
>> 
>> I'm confused. Didn't you say you'll remove this? If not, my question
>> from v1 still stands.
>
>Perhaps we should dis-allow setting version in non-genetlink-legacy
>specs? I thought it may be a useful thing to someone, at some point,
>but so far the scoreboard is: legit uses: 0, confused uses: 1 :S
>
>Thoughts?

I don't know what the meaning of version is. I just never saw that being
touched. Is there any semantics documented for it?

Kuba, any opinion?
___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan


Re: [Intel-wired-lan] [PATCH net-next v3 2/5] dpll: spec: add support for pin-dpll signal phase offset/adjust

2023-10-06 Thread Kuba Kicinski
On Fri, 6 Oct 2023 18:53:04 +0200 Jiri Pirko wrote:
> Fri, Oct 06, 2023 at 04:55:36PM CEST, k...@kernel.org wrote:
> >> I'm confused. Didn't you say you'll remove this? If not, my question
> >> from v1 still stands.  
> >
> >Perhaps we should dis-allow setting version in non-genetlink-legacy
> >specs? I thought it may be a useful thing to someone, at some point,
> >but so far the scoreboard is: legit uses: 0, confused uses: 1 :S
> >
> >Thoughts?  
> 
> I don't know what the meaning of version is. I just never saw that being
> touched. Is there any semantics documented for it?
> 
> Kuba, any opinion?

/me switches the first name in From :P

I think it basically predates the op / policy introspection,
and allows people to break backward compat.

drop_monitor bumped to 2 in 2009:

  683703a26e46 ("drop_monitor: Update netlink protocol to include
netlink attribute header in alert message")

which breaks backward compat.

genetlink ctrl went to 2 in 2006:

  334c29a64507 ("[GENETLINK]: Move command capabilities to flags.")

which moves some info around in attrs, also breaks backward compat
if someone depended on the old placement.

ovs did it in 2013:

  44da5ae5fbea ("openvswitch: Drop user features if old user space
attempted to create datapath")

again, breaks backwards compat.


I guess it may still make one day to bump the version for some proto
which has very tight control over the user space. But it hasn't
happened for 10 years.
___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan


[Intel-wired-lan] [PATCH iwl-next] ice: Fix SRIOV LAG disable on non-compliant aggreagate

2023-10-06 Thread Dave Ertman
If an attribute of an aggregate interface disqualifies it from supporting
SRIOV, the driver will unwind the SRIOV support.  Currently the driver is
clearing the feature bit for all interfaces in the aggregate, but this is
not allowing the other interfaces to unwind successfully on driver unload.

Only clear the feature bit for the interface that is currently unwinding.

Fixes: bf65da2eb279 ("ice: enforce interface eligibility and add messaging for 
SRIOV LAG")
Signed-off-by: Dave Ertman 
---
 drivers/net/ethernet/intel/ice/ice_lag.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_lag.c 
b/drivers/net/ethernet/intel/ice/ice_lag.c
index 2c96d1883e19..c9071228b1ea 100644
--- a/drivers/net/ethernet/intel/ice/ice_lag.c
+++ b/drivers/net/ethernet/intel/ice/ice_lag.c
@@ -1513,17 +1513,12 @@ static void ice_lag_chk_disabled_bond(struct ice_lag 
*lag, void *ptr)
  */
 static void ice_lag_disable_sriov_bond(struct ice_lag *lag)
 {
-   struct ice_lag_netdev_list *entry;
struct ice_netdev_priv *np;
-   struct net_device *netdev;
struct ice_pf *pf;
 
-   list_for_each_entry(entry, lag->netdev_head, node) {
-   netdev = entry->netdev;
-   np = netdev_priv(netdev);
-   pf = np->vsi->back;
-
-   ice_clear_feature_support(pf, ICE_F_SRIOV_LAG);
+   np = netdev_priv(lag->netdev);
+   pf = np->vsi->back;
+   ice_clear_feature_support(pf, ICE_F_SRIOV_LAG);
}
 }
 
-- 
2.40.1

___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan


Re: [Intel-wired-lan] [PATCH iwl-net v1] docs: update info about representor identification

2023-10-06 Thread Keller, Jacob E



> -Original Message-
> From: Mateusz Polchlopek 
> Sent: Friday, October 6, 2023 2:14 AM
> To: intel-wired-...@lists.osuosl.org
> Cc: net...@vger.kernel.org; Polchlopek, Mateusz
> ; Drewek, Wojciech
> 
> Subject: [Intel-wired-lan] [PATCH iwl-net v1] docs: update info about 
> representor
> identification
> 
> Update the "How are representors identified?" documentation
> subchapter. For newer kernels driver developers should use
> SET_NETDEV_DEVLINK_PORT instead of ndo_get_devlink_port()
> callback.
> 
> Signed-off-by: Mateusz Polchlopek 
> Reviewed-by: Wojciech Drewek 
> ---

Since this doesn't change an Intel driver, I think this should just be sent 
directly targeting net tree without needing to go through Intel Wired LAN.

Thanks,
Jake

>  Documentation/networking/representors.rst | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/networking/representors.rst
> b/Documentation/networking/representors.rst
> index ee1f5cd54496..2d6b7b493fa6 100644
> --- a/Documentation/networking/representors.rst
> +++ b/Documentation/networking/representors.rst
> @@ -162,9 +162,9 @@ How are representors identified?
>  The representor netdevice should *not* directly refer to a PCIe device (e.g.
>  through ``net_dev->dev.parent`` / ``SET_NETDEV_DEV()``), either of the
>  representee or of the switchdev function.
> -Instead, it should implement the ``ndo_get_devlink_port()`` netdevice op, 
> which
> -the kernel uses to provide the ``phys_switch_id`` and ``phys_port_name`` 
> sysfs
> -nodes.  (Some legacy drivers implement ``ndo_get_port_parent_id()`` and
> +Instead, driver developers should use ``SET_NETDEV_DEVLINK_PORT`` macro to
> +assign devlink port instance to a netdevice before it registers the 
> netdevice.
> +(Some legacy drivers implement ``ndo_get_port_parent_id()`` and
>  ``ndo_get_phys_port_name()`` directly, but this is deprecated.)  See
>  :ref:`Documentation/networking/devlink/devlink-port.rst ` for 
> the
>  details of this API.
> --
> 2.38.1
> 

___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan


[Intel-wired-lan] [PATCH net-next v2 0/6] Support symmetric RSS (Toeplitz) hash

2023-10-06 Thread Ahmed Zaki
Patch 1 adds the support at the Kernel level, allowing the user to set a
symmetric RSS hash for any flow type via:

# ethtool -N|-U eth0 rx-flow-hash  s|d|f|n symmetric

Support for the new "symmetric" flag will be later sent to the "ethtool" 
user-space tool.

Patch 2 fixes a long standing bug with the register values. The bug has
been benign for now since only symmetric Toeplitz hash (Zero) has been
used.

Patches 3 and 4 lay some groundwork refactoring. While the first is
mainly cosmetic, the second is needed since there is no more room in the
previous 64-bit RSS profile ID for the symmetric attribute introduced in 
the next patch.

Finally, patches 5 and 6 add the symmetric Toeplitz support for the ice 
(E800 PFs) and the iAVF drivers.

---
v2: fixed a "Reviewed by" to "Reviewed-by", also need to cc maintainers.

Ahmed Zaki (4):
  net: ethtool: allow symmetric RSS hash for any flow type
  ice: fix ICE_AQ_VSI_Q_OPT_RSS_* register values
  ice: refactor the FD and RSS flow ID generation
  iavf: enable symmetric RSS Toeplitz hash

Jeff Guo (1):
  ice: enable symmetric RSS Toeplitz hash for any flow type

Qi Zhang (1):
  ice: refactor RSS configuration

 Documentation/networking/scaling.rst  |   6 +
 .../net/ethernet/intel/iavf/iavf_adv_rss.c|   8 +-
 .../net/ethernet/intel/iavf/iavf_adv_rss.h|   3 +-
 .../net/ethernet/intel/iavf/iavf_ethtool.c|  22 +-
 drivers/net/ethernet/intel/ice/ice.h  |   2 +
 .../net/ethernet/intel/ice/ice_adminq_cmd.h   |   8 +-
 drivers/net/ethernet/intel/ice/ice_common.h   |   1 +
 drivers/net/ethernet/intel/ice/ice_ethtool.c  |  14 +-
 .../net/ethernet/intel/ice/ice_ethtool_fdir.c |  35 +-
 .../net/ethernet/intel/ice/ice_flex_pipe.c|  43 +-
 .../net/ethernet/intel/ice/ice_flex_pipe.h|   4 +-
 .../net/ethernet/intel/ice/ice_flex_type.h|   7 +
 drivers/net/ethernet/intel/ice/ice_flow.c | 439 +-
 drivers/net/ethernet/intel/ice/ice_flow.h |  46 +-
 .../net/ethernet/intel/ice/ice_hw_autogen.h   |   4 +
 drivers/net/ethernet/intel/ice/ice_lib.c  | 117 ++---
 drivers/net/ethernet/intel/ice/ice_main.c |  49 +-
 drivers/net/ethernet/intel/ice/ice_type.h |   1 +
 drivers/net/ethernet/intel/ice/ice_virtchnl.c |  55 ++-
 .../ethernet/intel/ice/ice_virtchnl_fdir.c|  35 +-
 include/linux/avf/virtchnl.h  |  16 +-
 include/uapi/linux/ethtool.h  |   1 +
 net/ethtool/ioctl.c   |  11 +
 23 files changed, 629 insertions(+), 298 deletions(-)

-- 
2.34.1

___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan


[Intel-wired-lan] [PATCH net-next v2 1/6] net: ethtool: allow symmetric RSS hash for any flow type

2023-10-06 Thread Ahmed Zaki
Symmetric RSS hash functions are beneficial in applications that monitor
both Tx and Rx packets of the same flow (IDS, software firewalls, ..etc).
Getting all traffic of the same flow on the same RX queue results in
higher CPU cache efficiency.

Only fields that has counterparts in the other direction can be
accepted; IP src/dst and L4 src/dst ports.

The user may request RSS hash symmetry for a specific flow type, via:

# ethtool -N|-U eth0 rx-flow-hash  s|d|f|n symmetric

or turn symmetry off (asymmetric) by:

# ethtool -N|-U eth0 rx-flow-hash  s|d|f|n

Reviewed-by: Wojciech Drewek 
Signed-off-by: Ahmed Zaki 
---
 Documentation/networking/scaling.rst |  6 ++
 include/uapi/linux/ethtool.h |  1 +
 net/ethtool/ioctl.c  | 11 +++
 3 files changed, 18 insertions(+)

diff --git a/Documentation/networking/scaling.rst 
b/Documentation/networking/scaling.rst
index 92c9fb46d6a2..64f3d7566407 100644
--- a/Documentation/networking/scaling.rst
+++ b/Documentation/networking/scaling.rst
@@ -44,6 +44,12 @@ by masking out the low order seven bits of the computed hash 
for the
 packet (usually a Toeplitz hash), taking this number as a key into the
 indirection table and reading the corresponding value.
 
+Some NICs support symmetric RSS hashing where, if the IP (source address,
+destination address) and TCP/UDP (source port, destination port) tuples
+are swapped, the computed hash is the same. This is beneficial in some
+applications that monitor TCP/IP flows (IDS, firewalls, ...etc) and need
+both directions of the flow to land on the same Rx queue (and CPU).
+
 Some advanced NICs allow steering packets to queues based on
 programmable filters. For example, webserver bound TCP port 80 packets
 can be directed to their own receive queue. Such “n-tuple” filters can
diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index f7fba0dc87e5..bf67c8094ae0 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -2025,6 +2025,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_SYMMETRIC   (1 << 30)
 #defineRXH_DISCARD (1 << 31)
 
 #defineRX_CLS_FLOW_DISC0xULL
diff --git a/net/ethtool/ioctl.c b/net/ethtool/ioctl.c
index 0b0ce4f81c01..44742653a4bd 100644
--- a/net/ethtool/ioctl.c
+++ b/net/ethtool/ioctl.c
@@ -980,6 +980,17 @@ static noinline_for_stack int ethtool_set_rxnfc(struct 
net_device *dev,
if (rc)
return rc;
 
+   /* If a symmetric hash is requested, then:
+* 1 - no other fields besides IP src/dst and/or L4 src/dst
+* 2 - If src is set, dst must also be set
+*/
+   if ((info.data & RXH_SYMMETRIC) &&
+   ((info.data & ~(RXH_SYMMETRIC | RXH_IP_SRC | RXH_IP_DST |
+ RXH_L4_B_0_1 | RXH_L4_B_2_3)) ||
+(!!(info.data & RXH_IP_SRC) ^ !!(info.data & RXH_IP_DST)) ||
+(!!(info.data & RXH_L4_B_0_1) ^ !!(info.data & RXH_L4_B_2_3
+   return -EINVAL;
+
rc = dev->ethtool_ops->set_rxnfc(dev, &info);
if (rc)
return rc;
-- 
2.34.1

___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan


[Intel-wired-lan] [PATCH net-next v2 2/6] ice: fix ICE_AQ_VSI_Q_OPT_RSS_* register values

2023-10-06 Thread Ahmed Zaki
Fix the values of the ICE_AQ_VSI_Q_OPT_RSS_* registers. Shifting is
already done when the values are used, no need to double shift. Bug was
not discovered earlier since only ICE_AQ_VSI_Q_OPT_RSS_TPLZ (Zero) is
currently used.

Also, rename ICE_AQ_VSI_Q_OPT_RSS_XXX to ICE_AQ_VSI_Q_OPT_RSS_HASH_XXX
for consistency.

Fixes: 7bd527aa174f ("ice: Adjust naming for inner VLAN operations")
Co-developed-by: Jesse Brandeburg 
Signed-off-by: Jesse Brandeburg 
Reviewed-by: Wojciech Drewek 
Signed-off-by: Ahmed Zaki 
---
 drivers/net/ethernet/intel/ice/ice_adminq_cmd.h |  8 
 drivers/net/ethernet/intel/ice/ice_lib.c|  4 ++--
 drivers/net/ethernet/intel/ice/ice_virtchnl.c   | 12 +---
 3 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h 
b/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
index 51281b58ad72..56ec1897f4d8 100644
--- a/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
+++ b/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
@@ -491,10 +491,10 @@ struct ice_aqc_vsi_props {
 #define ICE_AQ_VSI_Q_OPT_RSS_GBL_LUT_M (0xF << 
ICE_AQ_VSI_Q_OPT_RSS_GBL_LUT_S)
 #define ICE_AQ_VSI_Q_OPT_RSS_HASH_S6
 #define ICE_AQ_VSI_Q_OPT_RSS_HASH_M(0x3 << 
ICE_AQ_VSI_Q_OPT_RSS_HASH_S)
-#define ICE_AQ_VSI_Q_OPT_RSS_TPLZ  (0x0 << 
ICE_AQ_VSI_Q_OPT_RSS_HASH_S)
-#define ICE_AQ_VSI_Q_OPT_RSS_SYM_TPLZ  (0x1 << 
ICE_AQ_VSI_Q_OPT_RSS_HASH_S)
-#define ICE_AQ_VSI_Q_OPT_RSS_XOR   (0x2 << 
ICE_AQ_VSI_Q_OPT_RSS_HASH_S)
-#define ICE_AQ_VSI_Q_OPT_RSS_JHASH (0x3 << 
ICE_AQ_VSI_Q_OPT_RSS_HASH_S)
+#define ICE_AQ_VSI_Q_OPT_RSS_HASH_TPLZ 0x0U
+#define ICE_AQ_VSI_Q_OPT_RSS_HASH_SYM_TPLZ 0x1U
+#define ICE_AQ_VSI_Q_OPT_RSS_HASH_XOR  0x2U
+#define ICE_AQ_VSI_Q_OPT_RSS_HASH_JHASH0x3U
u8 q_opt_tc;
 #define ICE_AQ_VSI_Q_OPT_TC_OVR_S  0
 #define ICE_AQ_VSI_Q_OPT_TC_OVR_M  (0x1F << 
ICE_AQ_VSI_Q_OPT_TC_OVR_S)
diff --git a/drivers/net/ethernet/intel/ice/ice_lib.c 
b/drivers/net/ethernet/intel/ice/ice_lib.c
index acc3ffc940e7..1adf65d88ef0 100644
--- a/drivers/net/ethernet/intel/ice/ice_lib.c
+++ b/drivers/net/ethernet/intel/ice/ice_lib.c
@@ -1186,12 +1186,12 @@ static void ice_set_rss_vsi_ctx(struct ice_vsi_ctx 
*ctxt, struct ice_vsi *vsi)
case ICE_VSI_PF:
/* PF VSI will inherit RSS instance of PF */
lut_type = ICE_AQ_VSI_Q_OPT_RSS_LUT_PF;
-   hash_type = ICE_AQ_VSI_Q_OPT_RSS_TPLZ;
+   hash_type = ICE_AQ_VSI_Q_OPT_RSS_HASH_TPLZ;
break;
case ICE_VSI_VF:
/* VF VSI will gets a small RSS table which is a VSI LUT type */
lut_type = ICE_AQ_VSI_Q_OPT_RSS_LUT_VSI;
-   hash_type = ICE_AQ_VSI_Q_OPT_RSS_TPLZ;
+   hash_type = ICE_AQ_VSI_Q_OPT_RSS_HASH_TPLZ;
break;
default:
dev_dbg(dev, "Unsupported VSI type %s\n",
diff --git a/drivers/net/ethernet/intel/ice/ice_virtchnl.c 
b/drivers/net/ethernet/intel/ice/ice_virtchnl.c
index 01e88b6e43a1..55bf7891981f 100644
--- a/drivers/net/ethernet/intel/ice/ice_virtchnl.c
+++ b/drivers/net/ethernet/intel/ice/ice_virtchnl.c
@@ -823,8 +823,8 @@ static int ice_vc_handle_rss_cfg(struct ice_vf *vf, u8 
*msg, bool add)
int status;
 
lut_type = ICE_AQ_VSI_Q_OPT_RSS_LUT_VSI;
-   hash_type = add ? ICE_AQ_VSI_Q_OPT_RSS_XOR :
-   ICE_AQ_VSI_Q_OPT_RSS_TPLZ;
+   hash_type = add ? ICE_AQ_VSI_Q_OPT_RSS_HASH_XOR :
+   ICE_AQ_VSI_Q_OPT_RSS_HASH_TPLZ;
 
ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
if (!ctx) {
@@ -832,11 +832,9 @@ static int ice_vc_handle_rss_cfg(struct ice_vf *vf, u8 
*msg, bool add)
goto error_param;
}
 
-   ctx->info.q_opt_rss = ((lut_type <<
-   ICE_AQ_VSI_Q_OPT_RSS_LUT_S) &
-  ICE_AQ_VSI_Q_OPT_RSS_LUT_M) |
-  (hash_type &
-   ICE_AQ_VSI_Q_OPT_RSS_HASH_M);
+   ctx->info.q_opt_rss =
+   FIELD_PREP(ICE_AQ_VSI_Q_OPT_RSS_LUT_M, lut_type) |
+   FIELD_PREP(ICE_AQ_VSI_Q_OPT_RSS_HASH_M, hash_type);
 
/* Preserve existing queueing option setting */
ctx->info.q_opt_rss |= (vsi->info.q_opt_rss &
-- 
2.34.1

___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan


[Intel-wired-lan] [PATCH net-next v2 3/6] ice: refactor RSS configuration

2023-10-06 Thread Ahmed Zaki
From: Qi Zhang 

Refactor the driver to use a communication data structure for RSS
config. To do so we introduce the new ice_rss_hash_cfg struct, and then
pass it as an argument to several functions.

Also introduce enum ice_rss_cfg_hdr_type to specify a more granular and
flexible RSS configuration:

ICE_RSS_OUTER_HEADERS - take outer layer as RSS input set
ICE_RSS_INNER_HEADERS - take inner layer as RSS input set
ICE_RSS_INNER_HEADERS_W_OUTER_IPV4 - take inner layer as RSS input set for
 packet with outer IPV4
ICE_RSS_INNER_HEADERS_W_OUTER_IPV6 - take inner layer as RSS input set for
 packet with outer IPV6
ICE_RSS_ANY_HEADERS - try with outer first then inner (same as the
  behaviour without this change)

Finally, move the virtchnl_rss_algorithm enum to be with the other RSS
related structures in the virtchnl.h file.

There should be no functional change due to this patch.

Reviewed-by: Wojciech Drewek 
Signed-off-by: Qi Zhang 
Co-developed-by: Jesse Brandeburg 
Signed-off-by: Jesse Brandeburg 
Co-developed-by: Ahmed Zaki 
Signed-off-by: Ahmed Zaki 
---
 drivers/net/ethernet/intel/ice/ice_ethtool.c  |   6 +-
 drivers/net/ethernet/intel/ice/ice_flow.c | 232 +++---
 drivers/net/ethernet/intel/ice/ice_flow.h |  33 ++-
 drivers/net/ethernet/intel/ice/ice_lib.c  | 100 +++-
 drivers/net/ethernet/intel/ice/ice_virtchnl.c |  36 +--
 include/linux/avf/virtchnl.h  |  16 +-
 6 files changed, 246 insertions(+), 177 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_ethtool.c 
b/drivers/net/ethernet/intel/ice/ice_ethtool.c
index d3cb08e66dcb..d30d1b2a819b 100644
--- a/drivers/net/ethernet/intel/ice/ice_ethtool.c
+++ b/drivers/net/ethernet/intel/ice/ice_ethtool.c
@@ -2508,6 +2508,7 @@ static int
 ice_set_rss_hash_opt(struct ice_vsi *vsi, struct ethtool_rxnfc *nfc)
 {
struct ice_pf *pf = vsi->back;
+   struct ice_rss_hash_cfg cfg;
struct device *dev;
u64 hashed_flds;
int status;
@@ -2534,7 +2535,10 @@ ice_set_rss_hash_opt(struct ice_vsi *vsi, struct 
ethtool_rxnfc *nfc)
return -EINVAL;
}
 
-   status = ice_add_rss_cfg(&pf->hw, vsi->idx, hashed_flds, hdrs);
+   cfg.hash_flds = hashed_flds;
+   cfg.addl_hdrs = hdrs;
+   cfg.hdr_type = ICE_RSS_ANY_HEADERS;
+   status = ice_add_rss_cfg(&pf->hw, vsi->idx, &cfg);
if (status) {
dev_dbg(dev, "ice_add_rss_cfg failed, vsi num = %d, error = 
%d\n",
vsi->vsi_num, status);
diff --git a/drivers/net/ethernet/intel/ice/ice_flow.c 
b/drivers/net/ethernet/intel/ice/ice_flow.c
index 85cca572c22a..ff76eaabfb69 100644
--- a/drivers/net/ethernet/intel/ice/ice_flow.c
+++ b/drivers/net/ethernet/intel/ice/ice_flow.c
@@ -1858,37 +1858,49 @@ int ice_flow_rem_vsi_prof(struct ice_hw *hw, u16 
vsi_handle, u64 prof_id)
 /**
  * ice_flow_set_rss_seg_info - setup packet segments for RSS
  * @segs: pointer to the flow field segment(s)
- * @hash_fields: fields to be hashed on for the segment(s)
- * @flow_hdr: protocol header fields within a packet segment
+ * @seg_cnt: segment count
+ * @cfg: configure parameters
  *
  * Helper function to extract fields from hash bitmap and use flow
  * header value to set flow field segment for further use in flow
  * profile entry or removal.
  */
 static int
-ice_flow_set_rss_seg_info(struct ice_flow_seg_info *segs, u64 hash_fields,
- u32 flow_hdr)
+ice_flow_set_rss_seg_info(struct ice_flow_seg_info *segs, u8 seg_cnt,
+ const struct ice_rss_hash_cfg *cfg)
 {
+   struct ice_flow_seg_info *seg;
u64 val;
-   u8 i;
+   u16 i;
+
+   /* set inner most segment */
+   seg = &segs[seg_cnt - 1];
 
-   for_each_set_bit(i, (unsigned long *)&hash_fields,
-ICE_FLOW_FIELD_IDX_MAX)
-   ice_flow_set_fld(segs, (enum ice_flow_field)i,
+   for_each_set_bit(i, (const unsigned long *)&cfg->hash_flds,
+(u16)ICE_FLOW_FIELD_IDX_MAX)
+   ice_flow_set_fld(seg, (enum ice_flow_field)i,
 ICE_FLOW_FLD_OFF_INVAL, ICE_FLOW_FLD_OFF_INVAL,
 ICE_FLOW_FLD_OFF_INVAL, false);
 
-   ICE_FLOW_SET_HDRS(segs, flow_hdr);
+   ICE_FLOW_SET_HDRS(seg, cfg->addl_hdrs);
 
-   if (segs->hdrs & ~ICE_FLOW_RSS_SEG_HDR_VAL_MASKS &
+   /* set outer most header */
+   if (cfg->hdr_type == ICE_RSS_INNER_HEADERS_W_OUTER_IPV4)
+   segs[ICE_RSS_OUTER_HEADERS].hdrs |= ICE_FLOW_SEG_HDR_IPV4 |
+   ICE_FLOW_SEG_HDR_IPV_OTHER;
+   else if (cfg->hdr_type == ICE_RSS_INNER_HEADERS_W_OUTER_IPV6)
+   segs[ICE_RSS_OUTER_HEADERS].hdrs |= ICE_FLOW_SEG_HDR_IPV6 |
+   ICE_FLOW_SEG_HDR_IPV_OTHER;
+
+   if (seg-

[Intel-wired-lan] [PATCH net-next v2 4/6] ice: refactor the FD and RSS flow ID generation

2023-10-06 Thread Ahmed Zaki
The flow director and RSS blocks use separate methods to generate a
unique 64 bit ID for the flow. This is not extendable, especially for
the RSS that already uses all 64 bit space.

Refactor the flow generation API so that the ID is generated within
ice_flow_add_prof(). The FD and RSS blocks caches the generated ID for
later use.

Suggested-by: Dan Nowlin 
Reviewed-by: Wojciech Drewek 
Signed-off-by: Ahmed Zaki 
---
 .../net/ethernet/intel/ice/ice_ethtool_fdir.c | 31 +---
 .../net/ethernet/intel/ice/ice_flex_pipe.c| 10 
 .../net/ethernet/intel/ice/ice_flex_type.h|  6 +++
 drivers/net/ethernet/intel/ice/ice_flow.c | 47 +--
 drivers/net/ethernet/intel/ice/ice_flow.h |  2 +-
 drivers/net/ethernet/intel/ice/ice_main.c |  5 +-
 drivers/net/ethernet/intel/ice/ice_type.h |  1 +
 .../ethernet/intel/ice/ice_virtchnl_fdir.c| 33 -
 8 files changed, 54 insertions(+), 81 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_ethtool_fdir.c 
b/drivers/net/ethernet/intel/ice/ice_ethtool_fdir.c
index 8c6e13f87b7d..c9c72f8dbcb2 100644
--- a/drivers/net/ethernet/intel/ice/ice_ethtool_fdir.c
+++ b/drivers/net/ethernet/intel/ice/ice_ethtool_fdir.c
@@ -302,9 +302,7 @@ void ice_fdir_rem_adq_chnl(struct ice_hw *hw, u16 vsi_idx)
continue;
 
for (tun = 0; tun < ICE_FD_HW_SEG_MAX; tun++) {
-   u64 prof_id;
-
-   prof_id = flow + tun * ICE_FLTR_PTYPE_MAX;
+   u64 prof_id = prof->prof_id[tun];
 
for (i = 0; i < prof->cnt; i++) {
if (prof->vsi_h[i] != vsi_idx)
@@ -362,10 +360,9 @@ ice_fdir_erase_flow_from_hw(struct ice_hw *hw, enum 
ice_block blk, int flow)
return;
 
for (tun = 0; tun < ICE_FD_HW_SEG_MAX; tun++) {
-   u64 prof_id;
+   u64 prof_id = prof->prof_id[tun];
int j;
 
-   prof_id = flow + tun * ICE_FLTR_PTYPE_MAX;
for (j = 0; j < prof->cnt; j++) {
u16 vsi_num;
 
@@ -439,12 +436,10 @@ void ice_fdir_replay_flows(struct ice_hw *hw)
for (tun = 0; tun < ICE_FD_HW_SEG_MAX; tun++) {
struct ice_flow_prof *hw_prof;
struct ice_fd_hw_prof *prof;
-   u64 prof_id;
int j;
 
prof = hw->fdir_prof[flow];
-   prof_id = flow + tun * ICE_FLTR_PTYPE_MAX;
-   ice_flow_add_prof(hw, ICE_BLK_FD, ICE_FLOW_RX, prof_id,
+   ice_flow_add_prof(hw, ICE_BLK_FD, ICE_FLOW_RX,
  prof->fdir_seg[tun], TNL_SEG_CNT(tun),
  &hw_prof);
for (j = 0; j < prof->cnt; j++) {
@@ -454,7 +449,7 @@ void ice_fdir_replay_flows(struct ice_hw *hw)
 
prio = ICE_FLOW_PRIO_NORMAL;
err = ice_flow_add_entry(hw, ICE_BLK_FD,
-prof_id,
+hw_prof->id,
 prof->vsi_h[0],
 prof->vsi_h[j],
 prio, prof->fdir_seg,
@@ -464,6 +459,7 @@ void ice_fdir_replay_flows(struct ice_hw *hw)
flow);
continue;
}
+   prof->prof_id[tun] = hw_prof->id;
prof->entry_h[j][tun] = entry_h;
}
}
@@ -630,7 +626,6 @@ ice_fdir_set_hw_fltr_rule(struct ice_pf *pf, struct 
ice_flow_seg_info *seg,
u64 entry1_h = 0;
u64 entry2_h = 0;
bool del_last;
-   u64 prof_id;
int err;
int idx;
 
@@ -678,23 +673,23 @@ ice_fdir_set_hw_fltr_rule(struct ice_pf *pf, struct 
ice_flow_seg_info *seg,
 * That is the final parameters are 1 header (segment), no
 * actions (NULL) and zero actions 0.
 */
-   prof_id = flow + tun * ICE_FLTR_PTYPE_MAX;
-   err = ice_flow_add_prof(hw, ICE_BLK_FD, ICE_FLOW_RX, prof_id, seg,
+   err = ice_flow_add_prof(hw, ICE_BLK_FD, ICE_FLOW_RX, seg,
TNL_SEG_CNT(tun), &prof);
if (err)
return err;
-   err = ice_flow_add_entry(hw, ICE_BLK_FD, prof_id, main_vsi->idx,
+   err = ice_flow_add_entry(hw, ICE_BLK_FD, prof->id, main_vsi->idx,
 main_vsi->idx, ICE_FLOW_PRIO_NORMAL,
 seg, &entry1_h);
if (err)
goto err_prof;
-   err = ice_flow_add_entry(hw, ICE_BLK_FD, prof_id, main_vsi->idx,
+   err = ice_flow_add_

[Intel-wired-lan] [PATCH net-next v2 5/6] ice: enable symmetric RSS Toeplitz hash for any flow type

2023-10-06 Thread Ahmed Zaki
From: Jeff Guo 

The hash function in the E800 NICs is set per-VSI and a specific AQ
command is needed to modify the hash function. Use the AQ command to
enable setting the symmetric Toeplitz RSS hash function for any VSI.

When the Symmetric Toeplitz hash function is used, the hardware sets the
input set of the RSS (Toeplitz) algorithm to be the XOR of the fields
index by HSYMM and the fields index by the INSET registers. We use this
to create a symmetric hash by setting the HSYMM registers to point to
their counterparts in the INSET registers:

 HSYMM [src_fv] = dst_fv;
 HSYMM [dst_fv] = src_fv;

where src_fv and dst_fv are the indexes of the protocol's src and dst
fields.

Reviewed-by: Wojciech Drewek 
Signed-off-by: Jeff Guo 
Signed-off-by: Jesse Brandeburg 
Co-developed-by: Ahmed Zaki 
Signed-off-by: Ahmed Zaki 
---
 drivers/net/ethernet/intel/ice/ice.h  |   2 +
 drivers/net/ethernet/intel/ice/ice_common.h   |   1 +
 drivers/net/ethernet/intel/ice/ice_ethtool.c  |  10 +-
 .../net/ethernet/intel/ice/ice_ethtool_fdir.c |   4 +-
 .../net/ethernet/intel/ice/ice_flex_pipe.c|  33 ++-
 .../net/ethernet/intel/ice/ice_flex_pipe.h|   4 +-
 .../net/ethernet/intel/ice/ice_flex_type.h|   1 +
 drivers/net/ethernet/intel/ice/ice_flow.c | 222 +++---
 drivers/net/ethernet/intel/ice/ice_flow.h |  13 +-
 .../net/ethernet/intel/ice/ice_hw_autogen.h   |   4 +
 drivers/net/ethernet/intel/ice/ice_lib.c  |  41 ++--
 drivers/net/ethernet/intel/ice/ice_main.c |  44 
 drivers/net/ethernet/intel/ice/ice_virtchnl.c |   9 +-
 .../ethernet/intel/ice/ice_virtchnl_fdir.c|   2 +-
 14 files changed, 322 insertions(+), 68 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/ice.h 
b/drivers/net/ethernet/intel/ice/ice.h
index fcaa5c3b8ec0..c131fe24f959 100644
--- a/drivers/net/ethernet/intel/ice/ice.h
+++ b/drivers/net/ethernet/intel/ice/ice.h
@@ -360,6 +360,7 @@ struct ice_vsi {
/* RSS config */
u16 rss_table_size; /* HW RSS table size */
u16 rss_size;   /* Allocated RSS queues */
+   u8 rss_hfunc;   /* User configured hash type */
u8 *rss_hkey_user;  /* User configured hash keys */
u8 *rss_lut_user;   /* User configured lookup table entries */
u8 rss_lut_type;/* used to configure Get/Set RSS LUT AQ call */
@@ -910,6 +911,7 @@ int ice_set_rss_lut(struct ice_vsi *vsi, u8 *lut, u16 
lut_size);
 int ice_get_rss_lut(struct ice_vsi *vsi, u8 *lut, u16 lut_size);
 int ice_set_rss_key(struct ice_vsi *vsi, u8 *seed);
 int ice_get_rss_key(struct ice_vsi *vsi, u8 *seed);
+int ice_set_rss_hfunc(struct ice_vsi *vsi, u8 hfunc);
 void ice_fill_rss_lut(u8 *lut, u16 rss_table_size, u16 rss_size);
 int ice_schedule_reset(struct ice_pf *pf, enum ice_reset_req reset);
 void ice_print_link_msg(struct ice_vsi *vsi, bool isup);
diff --git a/drivers/net/ethernet/intel/ice/ice_common.h 
b/drivers/net/ethernet/intel/ice/ice_common.h
index 31fdcac33986..8d08a34dfb65 100644
--- a/drivers/net/ethernet/intel/ice/ice_common.h
+++ b/drivers/net/ethernet/intel/ice/ice_common.h
@@ -6,6 +6,7 @@
 
 #include 
 
+#include "ice.h"
 #include "ice_type.h"
 #include "ice_nvm.h"
 #include "ice_flex_pipe.h"
diff --git a/drivers/net/ethernet/intel/ice/ice_ethtool.c 
b/drivers/net/ethernet/intel/ice/ice_ethtool.c
index d30d1b2a819b..5ca959373f93 100644
--- a/drivers/net/ethernet/intel/ice/ice_ethtool.c
+++ b/drivers/net/ethernet/intel/ice/ice_ethtool.c
@@ -2538,7 +2538,9 @@ ice_set_rss_hash_opt(struct ice_vsi *vsi, struct 
ethtool_rxnfc *nfc)
cfg.hash_flds = hashed_flds;
cfg.addl_hdrs = hdrs;
cfg.hdr_type = ICE_RSS_ANY_HEADERS;
-   status = ice_add_rss_cfg(&pf->hw, vsi->idx, &cfg);
+   cfg.symm = !!(nfc->data & RXH_SYMMETRIC);
+
+   status = ice_add_rss_cfg(&pf->hw, vsi, &cfg);
if (status) {
dev_dbg(dev, "ice_add_rss_cfg failed, vsi num = %d, error = 
%d\n",
vsi->vsi_num, status);
@@ -2559,6 +2561,7 @@ ice_get_rss_hash_opt(struct ice_vsi *vsi, struct 
ethtool_rxnfc *nfc)
struct ice_pf *pf = vsi->back;
struct device *dev;
u64 hash_flds;
+   bool symm;
u32 hdrs;
 
dev = ice_pf_to_dev(pf);
@@ -2577,7 +2580,7 @@ ice_get_rss_hash_opt(struct ice_vsi *vsi, struct 
ethtool_rxnfc *nfc)
return;
}
 
-   hash_flds = ice_get_rss_cfg(&pf->hw, vsi->idx, hdrs);
+   hash_flds = ice_get_rss_cfg(&pf->hw, vsi->idx, hdrs, &symm);
if (hash_flds == ICE_HASH_INVALID) {
dev_dbg(dev, "No hash fields found for the given header type, 
vsi num = %d\n",
vsi->vsi_num);
@@ -2601,6 +2604,9 @@ ice_get_rss_hash_opt(struct ice_vsi *vsi, struct 
ethtool_rxnfc *nfc)
hash_flds & ICE_FLOW_HASH_FLD_UDP_DST_PORT ||
hash_flds & ICE_FLOW_HASH_FLD_SCTP_DST_PORT)
nfc->data |= (u64)RXH_L4_B_2_3;
+
+   if (symm)
+   nfc->da

[Intel-wired-lan] [PATCH net-next v2 6/6] iavf: enable symmetric RSS Toeplitz hash

2023-10-06 Thread Ahmed Zaki
Allow the VFs to support symmetric RSS for any flow type. The symmetric
RSS will not be supported on PFs not advertising the ADV RSS Offload
flag (ADV_RSS_SUPPORT()), for example the E700 series (i40e).

Reviewed-by: Madhu Chittim 
Signed-off-by: Ahmed Zaki 
---
 .../net/ethernet/intel/iavf/iavf_adv_rss.c|  8 +--
 .../net/ethernet/intel/iavf/iavf_adv_rss.h|  3 ++-
 .../net/ethernet/intel/iavf/iavf_ethtool.c| 22 +++
 3 files changed, 26 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/intel/iavf/iavf_adv_rss.c 
b/drivers/net/ethernet/intel/iavf/iavf_adv_rss.c
index 6edbf134b73f..a9e1da35e248 100644
--- a/drivers/net/ethernet/intel/iavf/iavf_adv_rss.c
+++ b/drivers/net/ethernet/intel/iavf/iavf_adv_rss.c
@@ -95,17 +95,21 @@ iavf_fill_adv_rss_sctp_hdr(struct virtchnl_proto_hdr *hdr, 
u64 hash_flds)
  * @rss_cfg: the virtchnl message to be filled with RSS configuration setting
  * @packet_hdrs: the RSS configuration protocol header types
  * @hash_flds: the RSS configuration protocol hash fields
+ * @symm: if true, symmetric hash is required
  *
  * Returns 0 if the RSS configuration virtchnl message is filled successfully
  */
 int
 iavf_fill_adv_rss_cfg_msg(struct virtchnl_rss_cfg *rss_cfg,
- u32 packet_hdrs, u64 hash_flds)
+ u32 packet_hdrs, u64 hash_flds, bool symm)
 {
struct virtchnl_proto_hdrs *proto_hdrs = &rss_cfg->proto_hdrs;
struct virtchnl_proto_hdr *hdr;
 
-   rss_cfg->rss_algorithm = VIRTCHNL_RSS_ALG_TOEPLITZ_ASYMMETRIC;
+   if (symm)
+   rss_cfg->rss_algorithm = VIRTCHNL_RSS_ALG_TOEPLITZ_SYMMETRIC;
+   else
+   rss_cfg->rss_algorithm = VIRTCHNL_RSS_ALG_TOEPLITZ_ASYMMETRIC;
 
proto_hdrs->tunnel_level = 0;   /* always outer layer */
 
diff --git a/drivers/net/ethernet/intel/iavf/iavf_adv_rss.h 
b/drivers/net/ethernet/intel/iavf/iavf_adv_rss.h
index 4d3be11af7aa..e31eb2afebea 100644
--- a/drivers/net/ethernet/intel/iavf/iavf_adv_rss.h
+++ b/drivers/net/ethernet/intel/iavf/iavf_adv_rss.h
@@ -80,13 +80,14 @@ struct iavf_adv_rss {
 
u32 packet_hdrs;
u64 hash_flds;
+   bool symm;
 
struct virtchnl_rss_cfg cfg_msg;
 };
 
 int
 iavf_fill_adv_rss_cfg_msg(struct virtchnl_rss_cfg *rss_cfg,
- u32 packet_hdrs, u64 hash_flds);
+ u32 packet_hdrs, u64 hash_flds, bool symm);
 struct iavf_adv_rss *
 iavf_find_adv_rss_cfg_by_hdrs(struct iavf_adapter *adapter, u32 packet_hdrs);
 void
diff --git a/drivers/net/ethernet/intel/iavf/iavf_ethtool.c 
b/drivers/net/ethernet/intel/iavf/iavf_ethtool.c
index 90397293525f..0eec30c390d6 100644
--- a/drivers/net/ethernet/intel/iavf/iavf_ethtool.c
+++ b/drivers/net/ethernet/intel/iavf/iavf_ethtool.c
@@ -1618,6 +1618,7 @@ iavf_set_adv_rss_hash_opt(struct iavf_adapter *adapter,
struct iavf_adv_rss *rss_old, *rss_new;
bool rss_new_add = false;
int count = 50, err = 0;
+   bool symm = false;
u64 hash_flds;
u32 hdrs;
 
@@ -1632,11 +1633,15 @@ iavf_set_adv_rss_hash_opt(struct iavf_adapter *adapter,
if (hash_flds == IAVF_ADV_RSS_HASH_INVALID)
return -EINVAL;
 
+   if (cmd->data & RXH_SYMMETRIC)
+   symm = true;
+
rss_new = kzalloc(sizeof(*rss_new), GFP_KERNEL);
if (!rss_new)
return -ENOMEM;
 
-   if (iavf_fill_adv_rss_cfg_msg(&rss_new->cfg_msg, hdrs, hash_flds)) {
+   if (iavf_fill_adv_rss_cfg_msg(&rss_new->cfg_msg, hdrs, hash_flds,
+ symm)) {
kfree(rss_new);
return -EINVAL;
}
@@ -1655,9 +1660,11 @@ iavf_set_adv_rss_hash_opt(struct iavf_adapter *adapter,
if (rss_old) {
if (rss_old->state != IAVF_ADV_RSS_ACTIVE) {
err = -EBUSY;
-   } else if (rss_old->hash_flds != hash_flds) {
+   } else if (rss_old->hash_flds != hash_flds ||
+  rss_old->symm != symm) {
rss_old->state = IAVF_ADV_RSS_ADD_REQUEST;
rss_old->hash_flds = hash_flds;
+   rss_old->symm = symm;
memcpy(&rss_old->cfg_msg, &rss_new->cfg_msg,
   sizeof(rss_new->cfg_msg));
adapter->aq_required |= IAVF_FLAG_AQ_ADD_ADV_RSS_CFG;
@@ -1669,6 +1676,7 @@ iavf_set_adv_rss_hash_opt(struct iavf_adapter *adapter,
rss_new->state = IAVF_ADV_RSS_ADD_REQUEST;
rss_new->packet_hdrs = hdrs;
rss_new->hash_flds = hash_flds;
+   rss_new->symm = symm;
list_add_tail(&rss_new->list, &adapter->adv_rss_list_head);
adapter->aq_required |= IAVF_FLAG_AQ_ADD_ADV_RSS_CFG;
}
@@ -1698,6 +1706,7 @@ iavf_get_adv_rss_hash_opt(struct iavf_adapter *adapter,
 {
struct iavf_adv_rss *rss;
u64 hash_flds;
+

Re: [Intel-wired-lan] [PATCH net-next v2 1/6] net: ethtool: allow symmetric RSS hash for any flow type

2023-10-06 Thread Jakub Kicinski
On Fri,  6 Oct 2023 16:47:21 -0600 Ahmed Zaki wrote:
> Symmetric RSS hash functions are beneficial in applications that monitor
> both Tx and Rx packets of the same flow (IDS, software firewalls, ..etc).
> Getting all traffic of the same flow on the same RX queue results in
> higher CPU cache efficiency.
> 
> Only fields that has counterparts in the other direction can be
> accepted; IP src/dst and L4 src/dst ports.
> 
> The user may request RSS hash symmetry for a specific flow type, via:
> 
> # ethtool -N|-U eth0 rx-flow-hash  s|d|f|n symmetric
> 
> or turn symmetry off (asymmetric) by:
> 
> # ethtool -N|-U eth0 rx-flow-hash  s|d|f|n

Thanks for the changes, code looks good!

The question left unanswered is whether we should care about the exact
implementation of the symmetry (xor, xor duplicate, sort fields).
Toeplitz-based RSS is very precisely specified, so we may want to carry
that precision into the symmetric behavior. I have a weak preference 
to do so... but no willingness to argue with you, so let me put Willem
on the spot and have him make a decision :)

Please make sure to CC Willem and anyone else who commented on previous
revisions on future versions!
___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan