Hi David,
One question in line.
On Mon, Aug 12, 2024 at 3:52 PM Dawid Osuchowski
wrote:
>
> Ethtool callbacks can be executed while reset is in progress and try to
> access deleted resources, e.g. getting coalesce settings can result in a
> NULL pointer dereference seen below.
>
> Once the drive
>-Original Message-
>From: Intel-wired-lan On Behalf Of
>Fijalkowski, Maciej
>Sent: Wednesday, August 7, 2024 4:23 PM
>To: intel-wired-...@lists.osuosl.org
>Cc: Fijalkowski, Maciej ;
>net...@vger.kernel.org; bj...@kernel.org; Nguyen, Anthony L
>; Karlsson, Magnus
>; luiz...@redhat.com
>
>-Original Message-
>From: Intel-wired-lan On Behalf Of
>Fijalkowski, Maciej
>Sent: Wednesday, August 7, 2024 4:23 PM
>To: intel-wired-...@lists.osuosl.org
>Cc: Fijalkowski, Maciej ;
>net...@vger.kernel.org; bj...@kernel.org; Nguyen, Anthony L
>; Karlsson, Magnus
>; luiz...@redhat.com
>
>-Original Message-
>From: Intel-wired-lan On Behalf Of
>Fijalkowski, Maciej
>Sent: Wednesday, August 7, 2024 4:23 PM
>To: intel-wired-...@lists.osuosl.org
>Cc: Fijalkowski, Maciej ;
>net...@vger.kernel.org; bj...@kernel.org; Nguyen, Anthony L
>; Karlsson, Magnus
>; luiz...@redhat.com
>
On Mon, 12 Aug 2024 14:56:21 + Joe Damato wrote:
> Several drivers make a check in their napi poll functions to determine
> if the CPU affinity of the IRQ has changed. If it has, the napi poll
> function returns a value less than the budget to force polling mode to
> be disabled, so that it can
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git main
branch HEAD: dd1bf9f9df156b43e5122f90d97ac3f59a1a5621 net: hinic: use
ethtool_sprintf/puts
elapsed time: 810m
configs tested: 128
configs skipped: 4
The following configs have been built successfully.
More c
Daiwei Li writes:
> 82580 NICs have a hardware bug that makes it
> necessary to write into the TSICR (TimeSync Interrupt Cause) register
> to clear it:
> https://lore.kernel.org/all/cdcb8be0.1ec2c%25matthew.v...@intel.com/
>
> Add a conditional so only for 82580 we write into the TSICR register,
Dear Manoj,
Thank you for your patch.
It’d be great if you made the summary a statement, that means, adding a
verb (in imperative mood), like:
idpf: Add more info during virtchnl transaction timeout
Am 13.08.24 um 20:27 schrieb Manoj Vishwanathan:
Add more information related to the transa
On Tue, Aug 13, 2024 at 05:31:37PM +0200, Dawid Osuchowski wrote:
> On 13.08.2024 13:49, Maciej Fijalkowski wrote:
> > What about other intel drivers tho?
>
> I have not performed detailed analysis of other intel ethernet drivers in
> this regard, but it is surely a topic worth investigating.
If
Manoj Vishwanathan wrote:
> From: Willem de Bruijn
>
> The virtchannel control queue is lossy to avoid deadlock. Ensure that
> no losses occur in practice. Detect a full queue, when overflows may
> have happened.
>
> In practice, virtchnl is synchronous currenty and messages generally
> take a s
gcc-13.2.0
arc allmodconfig gcc-13.2.0
arc allnoconfig gcc-13.2.0
arc allyesconfig gcc-13.2.0
arc defconfig gcc-13.2.0
arc randconfig-001-20240813 gcc
From: Willem de Bruijn
The virtchannel control queue is lossy to avoid deadlock. Ensure that
no losses occur in practice. Detect a full queue, when overflows may
have happened.
In practice, virtchnl is synchronous currenty and messages generally
take a single slot. Using up anywhere near the ful
Add more information related to the transaction like cookie, vc_op, salt
when transaction times out and include info like state, vc_op, chnl_opcode
when transaction salt does not match.
Sample output for transaction timeout:
---
Transaction timed-out (op:5015 cookie:45fe vc_op:5015
From: Marco Leogrande
When a workqueue is created with `WQ_UNBOUND`, its work items are
served by special worker-pools, whose host workers are not bound to
any specific CPU. In the default configuration (i.e. when
`queue_delayed_work` and friends do not specify which CPU to run the
work item on),
The transaction salt was being accessed before acquiring the
idpf_vc_xn_lock when idpf has to forward the virtchnl reply.
Fixes: 34c21fa894a1 ("idpf: implement virtchnl transaction manager")
Signed-off-by: Manoj Vishwanathan
---
drivers/net/ethernet/intel/idpf/idpf_virtchnl.c | 3 ++-
1 file ch
Adopt the same pattern as in other places in the code to take the rtnl
lock during hard resets.
Tested the patch by injecting tx timeout in IDPF , observe that idpf
recovers and IDPF comes back reachable
Without this patch causes there is a splat:
[ 270.145214] WARNING: CPU: PID: at net/sched/s
This patch series is to enhance IDPF virtchnl error reporting and some
minor fixes to the locking sequence in virtchnl message handling
we encountered while testing.
Also includes a minor clean up with regards to warning we encountered
in controlq section of IDPF.
The issue we had here was a virtc
On 13.08.2024 13:49, Maciej Fijalkowski wrote:
What about other intel drivers tho?
I have not performed detailed analysis of other intel ethernet drivers
in this regard, but it is surely a topic worth investigating.
--Dawid
On Tue, 13 Aug 2024 09:42:53 +0530 Ratheesh Kannoth wrote:
> On 2024-08-10 at 05:53:02, Vinicius Costa Gomes (vinicius.go...@intel.com)
> wrote:
> > @@ -6960,31 +6960,48 @@ static void igb_extts(struct igb_adapter *adapter,
> > int tsintr_tt)
> > static void igb_tsync_interrupt(struct igb_adapte
On 2024-08-10 at 05:53:02, Vinicius Costa Gomes (vinicius.go...@intel.com)
wrote:
> @@ -6960,31 +6960,48 @@ static void igb_extts(struct igb_adapter *adapter,
> int tsintr_tt)
> static void igb_tsync_interrupt(struct igb_adapter *adapter)
> {
> struct e1000_hw *hw = &adapter->hw;
> -
82580 NICs have a hardware bug that makes it
necessary to write into the TSICR (TimeSync Interrupt Cause) register
to clear it:
https://lore.kernel.org/all/cdcb8be0.1ec2c%25matthew.v...@intel.com/
Add a conditional so only for 82580 we write into the TSICR register,
so we don't risk losing events
On Tue, Aug 13, 2024 at 01:31:57PM +0200, Maciej Fijalkowski wrote:
> On Wed, Jul 24, 2024 at 06:48:33PM +0200, Larysa Zaremba wrote:
> > The main threat to data consistency in ice_xdp() is a possible asynchronous
> > PF reset. It can be triggered by a user or by TX timeout handler.
> >
> > XDP se
From: Jacob Keller
Add support for receive timestamps to the Rx hotpath. This support only
works when using the flexible descriptor format, so make sure that we
request this format by default if we have receive timestamp support
available in the PTP capabilities.
In order to report the timestamp
From: Jacob Keller
Using VIRTCHNL_VF_OFFLOAD_FLEX_DESC, the iAVF driver is capable of
negotiating to enable the advanced flexible descriptor layout. Add the
flexible NIC layout (RXDID=2) as a member of the Rx descriptor union.
Also add bit position definitions for the status and error indication
From: Jacob Keller
Add handlers for the .ndo_hwtstamp_get and .ndo_hwtstamp_set ops which allow
userspace to request timestamp enablement for the device. This support allows
standard Linux applications to request the timestamping desired.
As with other devices that support timestamping all packe
Rx timestamping introduced in PF driver caused the need of refactoring
the VF driver mechanism to check packet fields.
The function to check errors in descriptor has been removed and from
now only previously set struct fields are being checked. The field DD
(descriptor done) needs to be checked at
From: Jacob Keller
The Rx timestamps reported by hardware may only have 32 bits of storage
for nanosecond time. These timestamps cannot be directly reported to the
Linux stack, as it expects 64bits of time.
To handle this, the timestamps must be extended using an algorithm that
calculates the co
The union iavf_32byte_rx_desc consists of two unnamed structs defined
inside. One of them represents legacy 32 byte descriptor and second the
16 byte descriptor (extended to 32 byte). Each of them consists of
bunch of unions, structs and __le fields that represent specific fields
in descriptor.
Th
Structs idpf_rx_csum_decoded and idpf_rx_extracted are used both in
idpf and iavf Intel drivers. This commit changes the prefix from
idpf_* to libeth_* and moves mentioned structs to libeth's rx.h header
file.
Usage in idpf driver has been adjusted.
Suggested-by: Alexander Lobakin
Signed-off-by:
From: Jacob Keller
Add a new extended capabilities negotiation to exchange information from
the PF about what PTP capabilities are supported by this VF. This
requires sending a VIRTCHNL_OP_1588_PTP_GET_CAPS message, and waiting
for the response from the PF. Handle this early on during the VF
init
From: Jacob Keller
Implement support for reading the PHC time indirectly via the
VIRTCHNL_OP_1588_PTP_GET_TIME operation.
Based on some simple tests with ftrace, the latency of the indirect
clock access appears to be about ~110 microseconds. This is due to the
cost of preparing a message to send
From: Simei Su
To support Rx timestamp offload, VIRTCHNL_OP_1588_PTP_CAPS is sent by
the VF to request PTP capability and responded by the PF what capability
is enabled for that VF.
Hardware captures timestamps which contain only 32 bits of nominal
nanoseconds, as opposed to the 64bit timestamps
From: Jacob Keller
Add the iavf_ptp.c file and fill it in with a skeleton framework to
allow registering the PTP clock device.
Add implementation of helper functions to check if a PTP capability
is supported and handle change in PTP capabilities.
Enabling virtual clock would be possible, though i
From: Jacob Keller
Enable support for VIRTCHNL_VF_OFFLOAD_RX_FLEX_DESC, to enable the VF
driver the ability to determine what Rx descriptor formats are
available. This requires sending an additional message during
initialization and reset, the VIRTCHNL_OP_GET_SUPPORTED_RXDIDS. This
operation requ
From: Jacob Keller
Support for allowing VF to negotiate the descriptor format requires that
the VF specify which descriptor format to use when requesting Rx queues.
The VF is supposed to request the set of supported formats via the new
VIRTCHNL_OP_GET_SUPPORTED_RXDIDS, and then set one of the sup
From: Jacob Keller
Add support for allowing a VF to enable PTP feature - Rx timestamps
The new capability is gated by VIRTCHNL_VF_CAP_PTP, which must be
set by the VF to request access to the new operations. In addition, the
VIRTCHNL_OP_1588_PTP_CAPS command is used to determine the specific
cap
Initially, during VF creation it registers the PTP clock in
the system and negotiates with PF it's capabilities. In the
meantime the PF enables the Flexible Descriptor for VF.
Only this type of descriptor allows to receive Rx timestamps.
Enabling virtual clock would be possible, though it would pr
On Mon, Aug 12, 2024 at 02:50:09PM +0200, Dawid Osuchowski wrote:
> Ethtool callbacks can be executed while reset is in progress and try to
> access deleted resources, e.g. getting coalesce settings can result in a
> NULL pointer dereference seen below.
>
> Reproduction steps:
> Once the driver is
On Wed, Jul 24, 2024 at 06:48:33PM +0200, Larysa Zaremba wrote:
> The main threat to data consistency in ice_xdp() is a possible asynchronous
> PF reset. It can be triggered by a user or by TX timeout handler.
>
> XDP setup and PF reset code access the same resources in the following
> sections:
>
On Mon, Aug 12, 2024 at 05:59:21PM +0200, Larysa Zaremba wrote:
> On Mon, Aug 12, 2024 at 03:03:19PM +0200, Maciej Fijalkowski wrote:
> > On Wed, Jul 24, 2024 at 06:48:36PM +0200, Larysa Zaremba wrote:
> > > Locking used in ice_qp_ena() and ice_qp_dis() does pretty much nothing,
> > > because ICE_C
arc allnoconfig gcc-13.2.0
arc allyesconfig gcc-13.2.0
arc randconfig-001-20240813 gcc-13.2.0
arc randconfig-002-20240813 gcc-13.2.0
arm allmodconfig gcc-14.1.0
arm allnocon
Use always the same pf id in devlink port number. When doing
pass-through the PF to VM bus info func number can be any value.
Reviewed-by: Wojciech Drewek
Suggested-by: Jiri Pirko
Signed-off-by: Michal Swiatkowski
---
drivers/net/ethernet/intel/ice/devlink/devlink_port.c | 4 ++--
1 file chang
42 matches
Mail list logo
