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.
---
v10:
- fixed all but one kdoc w
Extend devlink_param *set function pointer to take extack as a param.
Sometimes it is needed to pass information to the end user from set
function. It is more proper to use for that netlink instead of passing
message to dmesg.
Reviewed-by: Jiri Pirko
Reviewed-by: Przemek Kitszel
Signed-off-by: M
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 p
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.
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
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
From: Michal Wilczynski
New driver specific parameter 'tx_scheduling_layers' was introduced.
Describe parameter in the documentation.
Signed-off-by: Michal Wilczynski
Acked-by: Jakub Kicinski
Reviewed-by: Jiri Pirko
Reviewed-by: Przemek Kitszel
Co-developed-by: Mateusz Polchlopek
Signed-off
Refactor struct ice_vsi_cfg_params to be embedded into struct ice_vsi.
Prior to that the members of the struct were scattered around ice_vsi,
and were copy-pasted for purposes of reinit.
Now we have struct handy, and it is easier to have something sticky
in the flags field.
Suggested-by: Przemek K
On Tue, Apr 16, 2024 at 02:43:30PM +, Asbjørn Sloth Tønnesen wrote:
> This driver currently doesn't support any control flags.
>
> Use flow_rule_has_control_flags() to check for control flags,
> such as can be set through `tc flower ... ip_flags frag`.
>
> In case any control flags are masked
>-Original Message-
> From: Intel-wired-lan On Behalf Of Erwan
> Velu
> Sent: Wednesday, March 13, 2024 2:37 PM
> Cc: Velu, Erwan ; linux-ker...@vger.kernel.org; Eric
> Dumazet ; net...@vger.kernel.org; Nguyen, Anthony L
> ; intel-wired-...@lists.osuosl.org; Jakub
> Kicinski ; Paolo Ab
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Mogilappagari, Sudheer
> Sent: Monday, April 1, 2024 10:01 PM
> To: intel-wired-...@lists.osuosl.org
> Subject: [Intel-wired-lan] [PATCH iwl-net] iavf: Fix TC config comparison with
> existing adapter TC config
>
> Same number
> > drivers/net/ethernet/intel/i40e/i40e_main.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c
> > b/drivers/net/ethernet/intel/i40e/i40e_main.c
> > index 6010a49..dbc4ab90 100644
> > --- a/drivers/net/ethernet/intel/i40e/
Commit 24407a01e57c ("ice: Add 200G speed/phy type use") added support
for 200G PHY speeds, but did not include the mapping of 200G PHY types
to link speed. As a result the driver is returning UNKNOWN link speed
when setting 200G ethtool advertised link modes.
To fix this add 200G PHY types to lin
Hi Sasha,
Thank you, sorry for the delay but I coudln't reboot.
Adding Greg KH because I don't know if stable will receive my e-mail
(not subscribed) but the regression was integrated in stable:
commit 0a4e3c2d976aa4dd38951afd6267f74ef3fade0e
so they should get the fix ASAP too.
Tested-by: Jé
Hi,
This is a series to prepare port representor for supporting also
subfunctions. We need correct devlink locking and the possibility to
update parent VSI after port representor is created.
Refactor how devlink lock is taken to suite the subfunction use case.
VSI configuration needs to be done
It is used to get representor structure during cleaning.
Reviewed-by: Wojciech Drewek
Signed-off-by: Michal Swiatkowski
---
drivers/net/ethernet/intel/ice/ice_eswitch_br.c | 4 +++-
drivers/net/ethernet/intel/ice/ice_eswitch_br.h | 1 +
drivers/net/ethernet/intel/ice/ice_repr.c | 7 ++
In case of subfunction lock will be taken for whole port creation. Do
the same in VF case.
Signed-off-by: Michal Swiatkowski
---
drivers/net/ethernet/intel/ice/devlink/devlink.c | 2 --
drivers/net/ethernet/intel/ice/devlink/devlink_port.c | 4 ++--
drivers/net/ethernet/intel/ice/ice_eswitc
It is needed because subfunction port representor shouldn't configure
the source VSI during representor creation.
Move the code to separate function and call it only in case the VF port
representor is being created.
Signed-off-by: Michal Swiatkowski
---
drivers/net/ethernet/intel/ice/ice_eswitc
In case of reset of VF VSI can be reallocated. To handle this case it
should be properly updated.
Reload representor as vsi->vsi_num can be different than the one stored
when representor was created.
Instead of only changing antispoof do whole VSI configuration for
eswitch.
Signed-off-by: Michal
On Thu, Apr 18, 2024 at 07:25:35PM +0200, Jiri Pirko wrote:
> Thu, Apr 18, 2024 at 06:11:38PM CEST, michal.swiatkow...@linux.intel.com
> wrote:
> >On Thu, Apr 18, 2024 at 05:43:25PM +0200, Jiri Pirko wrote:
> >> Thu, Apr 18, 2024 at 04:46:23PM CEST, michal.swiatkow...@linux.intel.com
> >> wrote:
20 matches
Mail list logo
