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.
---
v3:
- fixed documentation warni
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: 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: 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/network
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: 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.
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Romanowski, Rafal
> Sent: Friday, October 6, 2023 5:16 PM
> To: Simon Horman ; Brandeburg, Jesse
>
> Cc: net...@vger.kernel.org; intel-wired-...@lists.osuosl.org; Christophe
> JAILLET ; Kitszel, Przemyslaw
>
> Subject: Re: [Inte
Make the driver not produce an error message on
"ethtool -m ethX" command when a non-SFP module is encountered
hence there is no possibility to read the EEPROM.
Make the message to appear in the debug log rather
than as an error string.
Change the return code to -EOPNOTSUPP and the string to make
On 10/5/2023 6:57 AM, 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 corruptin
On 10/5/2023 6:58 AM, 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 u
On 10/6/2023 5:53 AM, 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
Reviewed-by: Jesse Brandeburg
_
On Sat, 7 Oct 2023 12:29:47 +0200 Jiri Pirko wrote:
> But since by the policy we cannot break uapi compat, version should be
> never bumped. I wonder howcome it is legit in the examples you listed
> above...
Yes, even it's the 0.0001% of the time when "breaking' uAPI is fine,
the change in the fam
On 10/4/2023 10:08 AM, Skyler Mäntysaari wrote:
>>> Hi there,
>>>
>>> It seems that for reasons unknown to me, my Intel X533 based 10G SFP+
>>> doesn't want to work with kernel 6.1.55 in VyOS 1.4 nor Debian 12 but
>>> it does in OPNsense which is based on FreeBSD 13.2.
>>>
>>> How would I go about
On Fri, 6 Oct 2023 16:47:22 -0600 Ahmed Zaki wrote:
> Fixes: 7bd527aa174f ("ice: Adjust naming for inner VLAN operations")
If there is v3 please drop the Fixes tag.
If the mistake doesn't result in a triggerable bug there's no need
to backport this and therefore no need to annotate the source o
On 10/4/2023 10:44 PM, Vitaly Lifshits wrote:
> On some Meteor Lake systems accessing the PHY via the MDIO interface may
> result in an MDI error. This issue happens sporadically and in most cases
> a second access to the PHY via the MDIO interface results in success.
>
> As a workaround, intro
On 10/6/2023 2:02 PM, Dave Ertman wrote:
> 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 in
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).
v3->v4:
- do not increase do version of uAPI header as it
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 | 31 +++
drivers/dpll/dpll_nl.c
Add documentation on:
- measurement 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
Implement new callback ops related to measurement and adjustment of
signal phase for pin-dpll in ice driver.
Signed-off-by: Arkadiusz Kubalewski
---
drivers/net/ethernet/intel/ice/ice_dpll.c | 220 +-
drivers/net/ethernet/intel/ice/ice_dpll.h | 10 +-
2 files changed, 226 in
Add callback ops for pin-dpll phase measurement.
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 Kub
Align the approach 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:
>From: Jiri Pirko
>Sent: Friday, October 6, 2023 2:38 PM
>
>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.
>>In
>From: Jiri Pirko
>Sent: Monday, October 2, 2023 5:01 PM
>
>Wed, Sep 27, 2023 at 11:24:32AM CEST, arkadiusz.kubalew...@intel.com wrote:
>>Add dpll documentation on new pin's attributes:
>>- phase-offset - measured difference between phase of signals on pin
>> and dpll
>>- phase-adjust - adjustabl
>From: Jiri Pirko
>Sent: Friday, October 6, 2023 2:30 PM
>
>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
>>
>>Sign
On Mon, Oct 9, 2023, at 18:33, Jesse Brandeburg wrote:
> On 10/4/2023 10:08 AM, Skyler Mäntysaari wrote:
Hi there,
It seems that for reasons unknown to me, my Intel X533 based 10G SFP+
doesn't want to work with kernel 6.1.55 in VyOS 1.4 nor Debian 12 but
it does in OPNsen
Here are a couple of iavf cleanups and then improvements for the
initialization flow (waiting for the VF reset) and driver removal.
Michal Schmidt (5):
iavf: fix comments about old bit locks
iavf: simplify mutex_trylock+sleep loops
iavf: in iavf_down, don't queue watchdog_task if comms faile
This pattern appears in two places in the iavf source code:
while (!mutex_trylock(...))
usleep_range(...);
That's just mutex_lock with extra steps.
The pattern is a leftover from when iavf used bit flags instead of
mutexes for locking. Commit 5ac49f3c2702 ("iavf: use mutexes for locking
of
The reason for queueing watchdog_task is to have it process the
aq_required flags that are being set here. If comms failed, there's
nothing to do, so return early.
Signed-off-by: Michal Schmidt
---
drivers/net/ethernet/intel/iavf/iavf_main.c | 6 --
1 file changed, 4 insertions(+), 2 deletio
Bit lock __IAVF_IN_CRITICAL_TASK does not exist anymore since commit
5ac49f3c2702 ("iavf: use mutexes for locking of critical sections").
Adjust the comments accordingly.
Signed-off-by: Michal Schmidt
---
drivers/net/ethernet/intel/iavf/iavf_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 de
In iavf_down, we're skipping the scheduling of certain operations if
the driver is being removed. However, the IAVF_FLAG_AQ_DISABLE_QUEUES
request must not be skipped in this case, because iavf_close waits
for the transition to the __IAVF_DOWN state, which happens in
iavf_virtchnl_completion after
Every time I create VFs on ice, I receive at least one "Device is still
in reset (-16), retrying" message per VF. It recovers fine, but typical
usecases should not trigger scary-looking messages.
The waiting for reset is too short. It makes no sense to check every 10
microseconds. Typical reset wa
On Tue, Oct 10, 2023, at 02:50, Skyler Mäntysaari wrote:
> On Mon, Oct 9, 2023, at 18:33, Jesse Brandeburg wrote:
>> On 10/4/2023 10:08 AM, Skyler Mäntysaari wrote:
> Hi there,
>
> It seems that for reasons unknown to me, my Intel X533 based 10G SFP+
> doesn't want to work with kern
On 10/10/2023 0:28, Jacob Keller wrote:
On 10/4/2023 10:44 PM, Vitaly Lifshits wrote:
On some Meteor Lake systems accessing the PHY via the MDIO interface may
result in an MDI error. This issue happens sporadically and in most cases
a second access to the PHY via the MDIO interface results in
34 matches
Mail list logo
