On 2/22/24 15:50, Maciej Fijalkowski wrote:
1. pcaps are free'd right after AQ routines are done, no need for
devm_'s
2. a test frame for loopback test in ethtool -t is destroyed at the end
of the test so we don't need devm_ here either.
Signed-off-by: Maciej Fijalkowski
---
drivers/n
During VSI reconfiguration filters and VSI config which is set in
ice_vf_init_host_cfg() are lost. Recall the host configuration function
to restore them.
Without this config VF on which MSI-X amount was changed might had a
connection problems.
Fixes: 4d38cb44bd32 ("ice: manage VFs MSI-X using re
On 2/22/2024 2:25 PM, Tony Nguyen wrote:
I think he means that the tests won't pass without Amritha's patch
because we'll hit the ASSERT_RTNL in the suspend flow otherwise.
Got it. Anyways, this doesn't apply to net-queue, could we rebase or
base it off of that tree?
Ok, will send v2 off -n
On Thu, 22 Feb 2024 14:25:21 +0100 Mateusz Polchlopek wrote:
> >> This is kind of proprietary param similar to number of which were shot
> >> down for mlx5 in past. Jakub?
> >
> > I remain somewhat confused about what this does.
> > Specifically IIUC the problem is that the radix of each node is
On 2/22/2024 2:19 PM, Keller, Jacob E wrote:
-Original Message-
From: Nguyen, Anthony L
...
NOTE:
Requires Amritha's patch:
https://patchwork.ozlabs.org/project/intel-wired-
lan/patch/170785373072.3325.9129916579186572531.st...@anambiarhost.jf.
intel.com/
to be applied before t
> -Original Message-
> From: Nguyen, Anthony L
> Sent: Thursday, February 22, 2024 2:10 PM
> To: Brandeburg, Jesse ; intel-wired-
> l...@lists.osuosl.org
> Cc: net...@vger.kernel.org; Elliott, Rob ; Keller, Jacob E
> ; David S. Miller ; Eric
> Dumazet
> ; Jakub Kicinski ; Paolo Abeni
>
On 2/20/2024 3:17 PM, Jesse Brandeburg wrote:
The ice_suspend/ice_resume cycle was not updated when refactoring was
done to the init path and I suspect this allowed a bug to creep in where
the driver was not correctly reinitialized during resume.
I was able to test against 6.1.77 kernel and that
This error message is at best not really helpful and at worst
misleading. If we're here in idpf_intr_rel we're likely trying to do
remove or reset. If we're in reset, this message will fail because we
lose the virtchnl on reset and HW is going to clean up those resources
regardless in that case. If
While we're here improving virtchnl we can include two minor fixes for
the lower level ctrlq flow.
This adds a memory barrier to idpf_post_rx_buffs before we update tail
on the controlq. We should make sure our writes have had a chance to
finish before we tell HW it can touch them.
This also rem
In idpf_remove we need to tear down the virtchnl core with
idpf_vc_core_deinit so we can free up resources and leave things in a
good state. However, in the case where we failed to establish VC
communications we may not have ever actually successfully initialized
the virtchnl core.
This fixes it b
We can now remove a bunch of gross code we don't need anymore like the
vc state bits and vc_buf_lock since everything is using transaction API
now.
Tested-by: Alexander Lobakin
Reviewed-by: Przemek Kitszel
Reviewed-by: Igor Bagnucki
Signed-off-by: Alan Brady
---
drivers/net/ethernet/intel/idp
This takes care of RSS/SRIOV/MAC and other misc virtchnl messages. This
again is mostly mechanical.
In absence of an async_handler for MAC filters, this will simply
generically report any errors from idpf_vc_xn_forward_async. This
maintains the existing behavior. Follow up patch will add an async
Now that all the messages are using the transaction API, we can rework
idpf_recv_mb_msg quite a lot to simplify it. Due to this, we remove
idpf_find_vport as no longer used and alter idpf_recv_event_msg
slightly.
Tested-by: Alexander Lobakin
Signed-off-by: Alan Brady
---
drivers/net/ethernet/in
There are situations where the driver needs to add a MAC filter but
we're explicitly not allowed to sleep so we can wait for a virtchnl
message to complete.
This adds an async_handler for asynchronously sent messages for MAC
filters so that we can better handle if there's an error of some kind.
If
This reworks queue specific virtchnl messages to use the added
transaction API. It is fairly mechanical and generally makes the
functions using it more simple. Functions using transaction API no
longer need to take the vc_buf_lock since it's not using it anymore.
After filling out an idpf_vc_xn_pa
This reworks the way vport related virtchnl messages work to take
advantage of the added transaction API. It is fairly mechanical as, to
use the transaction API, the function just needs to fill out an
appropriate idpf_vc_xn_params struct to pass to idpf_vc_xn_exec which
will take care of the actual
This starts refactoring how virtchnl messages are handled by adding a
transaction manager (idpf_vc_xn_manager).
There are two primary motivations here which are to enable handling of
multiple messages at once and to make it more robust in general. As it
is right now, the driver may only have one p
idpf.h is quite heavy. We can reduce the burden a fair bit by
introducing an idpf_virtchnl.h file. This mostly just moves function
declarations but there are many of them. This also makes an attempt to
group those declarations in a way that makes some sense instead of
mishmashed.
Suggested-by: Ale
The motivation for this series has two primary goals. We want to enable
support of multiple simultaneous messages and make the channel more
robust. The way it works right now, the driver can only send and receive
a single message at a time and if something goes really wrong, it can
lead to data cor
allnoconfig gcc
arc allyesconfig gcc
arc defconfig gcc
arc randconfig-001-20240222 gcc
arc randconfig-002-20240222 gcc
arc
Dear Martin,
On Tue, Feb 20, 2024 at 2:17PM +0100, Martin Kulas wrote:
[...]
> > >
> > > When searching for a solution about this high latency TX timestamp read,
> > > I found the following thread from 2022:
> > >
> > > https://patchwork.ozlabs.org/project/intel-wired-lan/patch/20220802145757.27
> -Original Message-
> From: Intel-wired-lan On Behalf Of Jon
> Maxwell
> Sent: Friday, February 16, 2024 3:31 AM
> To: Brandeburg, Jesse
> Cc: intel-wired-...@lists.osuosl.org; linux-ker...@vger.kernel.org;
> eduma...@google.com; Nguyen, Anthony L ;
> net...@vger.kernel.org; k...@kern
Fix issue where ixgbe driver triggers resets in endless manner. A
snippet from dmesg:
[1879966.583523] ixgbe :86:00.0 enp134s0f0: initiating reset to clear Tx
work after link loss
[1879968.405694] ixgbe :86:00.0 enp134s0f0: Reset adapter
[1879968.925689] ixgbe :86:00.0 enp134s0f0: det
On Wed, Feb 21, 2024 at 10:28:51AM +, Simon Horman wrote:
> On Tue, Feb 20, 2024 at 03:45:28PM +0100, Andrew Lunn wrote:
> > > > + unsupp = linkmode_andnot(tmp, edata->advertised, supported);
> > >
> > > nit: Given the types involved, I might have written this as:
> > >
> > > unsupp =
Introduce ixgbe_update_{r,t}x_ring_stats() that will be used by both
standard and ZC datapath.
Signed-off-by: Maciej Fijalkowski
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 54 ++-
.../ethernet/intel/ixgbe/ixgbe_txrx_common.h | 7 +++
drivers/net/ethernet/intel/ixgbe/ix
1. pcaps are free'd right after AQ routines are done, no need for
devm_'s
2. a test frame for loopback test in ethtool -t is destroyed at the end
of the test so we don't need devm_ here either.
Signed-off-by: Maciej Fijalkowski
---
drivers/net/ethernet/intel/ice/ice_common.c | 23
ice_down() clears QINT_TQCTL_CAUSE_ENA_M bit twice, which is not
necessary. First clearing happens in ice_vsi_dis_irq() and second in
ice_vsi_stop_tx_ring() - remove the first one.
While at it, make ice_vsi_dis_irq() static as ice_down() is the only
current caller of it.
Signed-off-by: Maciej Fij
Hi,
here are not related improvements to ice and ixgbe. Spotted while
working on other issues. First one takes care redundant Tx disabling on
ifdown. Second one is about rather obvious getting rid of devm_ usage
and last one is plain refactor of stats update.
Thanks!
Maciej Fijalkowski (3):
ic
On 2/22/2024 5:04 AM, Alexander Lobakin wrote:
From: Alexander Lobakin
Date: Thu, 22 Feb 2024 13:53:25 +0100
From: Alan Brady
Date: Wed, 21 Feb 2024 12:16:37 -0800
On 2/21/2024 4:15 AM, Alexander Lobakin wrote:
From: Alan Brady
Date: Tue, 20 Feb 2024 16:49:40 -0800
This starts refactori
On 2/22/2024 12:38 AM, Jakub Kicinski wrote:
On Mon, 19 Feb 2024 13:37:36 +0100 Jiri Pirko wrote:
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 pa
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Simon Horman
> Sent: Monday, February 19, 2024 10:22 AM
> To: Brandeburg, Jesse
> Cc: net...@vger.kernel.org; Eric Dumazet ; Nguyen,
> Anthony L ; Brady, Alan
> ; Jakub Kicinski ; intel-wired-
> l...@lists.osuosl.org; Paolo Abeni
From: Alexander Lobakin
Date: Thu, 22 Feb 2024 13:53:25 +0100
> From: Alan Brady
> Date: Wed, 21 Feb 2024 12:16:37 -0800
>
>> On 2/21/2024 4:15 AM, Alexander Lobakin wrote:
>>> From: Alan Brady
>>> Date: Tue, 20 Feb 2024 16:49:40 -0800
>>>
This starts refactoring how virtchnl messages are
allnoconfig gcc
arc allyesconfig gcc
arc defconfig gcc
arc randconfig-001-20240222 gcc
arc randconfig-002-20240222 gcc
arm
From: Alan Brady
Date: Wed, 21 Feb 2024 12:16:37 -0800
> On 2/21/2024 4:15 AM, Alexander Lobakin wrote:
>> From: Alan Brady
>> Date: Tue, 20 Feb 2024 16:49:40 -0800
>>
>>> This starts refactoring how virtchnl messages are handled by adding a
>>> transaction manager (idpf_vc_xn_manager).
[...]
In case of traffic going from the VF (so ingress for port representor)
source VSI should be consider during packet classification. It is
needed for hardware to not match packets from different ports with
filters added on other port.
It is only for "from VF" traffic, because other traffic direction
Add new matching type for ip_proto.
Use it in the same lookup type as for TTL. In hardware it has the same
protocol ID, but different offset.
Example command to add filter with ip_proto:
$tc filter add dev eth10 ingress protocol ip flower ip_proto icmp \
skip_sw action mirred egress redirect dev
Extend hardware support for tc flower to match ip_proto field (patch 2)
and source VSI metadata when the packets are sent from VF (patch 1).
v1 --> v2: [1]
* fix commit message, add more examples
[1]
https://lore.kernel.org/netdev/20240220105950.6814-1-michal.swiatkow...@linux.intel.com/
Mich
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Oleksij Rempel
> Sent: Tuesday, February 13, 2024 5:24 PM
> To: Brandeburg, Jesse ; Nguyen, Anthony L
> ; David S. Miller ; Eric
> Dumazet ; Jakub Kicinski ; Paolo Abeni
> ; Richard Cochran
> Cc: Oleksij Rempel ;
> intel-wir
Dear Arnd,
Thank you for the patch.
Am 22.02.24 um 11:02 schrieb Arnd Bergmann:
From: Arnd Bergmann
When IGC is built-in but LEDS_CLASS is a loadable module, there is
a link failure:
x86_64-linux-ld: drivers/net/ethernet/intel/igc/igc_leds.o: in function
`igc_led_setup':
igc_leds.c:(.text
On Thu Feb 22 2024, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> When IGC is built-in but LEDS_CLASS is a loadable module, there is
> a link failure:
>
> x86_64-linux-ld: drivers/net/ethernet/intel/igc/igc_leds.o: in function
> `igc_led_setup':
> igc_leds.c:(.text+0x75c): undefined reference to
From: Arnd Bergmann
When IGC is built-in but LEDS_CLASS is a loadable module, there is
a link failure:
x86_64-linux-ld: drivers/net/ethernet/intel/igc/igc_leds.o: in function
`igc_led_setup':
igc_leds.c:(.text+0x75c): undefined reference to
`devm_led_classdev_register_ext'
Add another depende
On 19.02.24 12:40, Jaroslav Pulchart wrote:
> If the question is for me then my opinion about it is this:
>
> I'm fine with the behaviour of a driver about memory consumption if it
> is predictable/described with the possibility to change it from
> default values. My understanding of "predictable"
On Tue, 20 Feb 2024 at 22:46, Maciej Fijalkowski
wrote:
>
> Hi,
>
> It started out as an issue on ixgbe reported by Pavel [0] which first
> patch is supposed to fix, but apparently i40e and ice have queue pair
> disabling flow a bit out of order, so I addressed them as well. More
> info is include
43 matches
Mail list logo
