On Wed, Jan 15, 2025 at 09:11:17AM +0530, Dheeraj Reddy Jonnalagadda wrote:
> The ixgbe driver was missing proper endian conversion for ACI descriptor
> register operations. Add the necessary conversions when reading and
> writing to the registers.
>
> Fixes: 46761fd52a88 ("ixgbe: Add support for
The ixgbe driver was missing proper endian conversion for ACI descriptor
register operations. Add the necessary conversions when reading and
writing to the registers.
Fixes: 46761fd52a88 ("ixgbe: Add support for E610 FW Admin Command Interface")
Closes:
https://scan7.scan.coverity.com/#/project-v
On Tue, Jan 14, 2025 at 12:32:47PM +, Kwapulinski, Piotr wrote:
> >-Original Message-
> >From: Dheeraj Reddy Jonnalagadda
> >Sent: Tuesday, January 14, 2025 1:23 AM
> >To: Kwapulinski, Piotr
> >Cc: andrew+net...@lunn.ch; Nguyen, Anthony L ;
> >da...@davemloft.net; eduma...@google.co
On Tue, 14 Jan 2025 18:00:30 -0700 Ahmed Zaki wrote:
> > Similarly netif_napi_set_irq() may get called with -1 to clear
> > the IRQ number, which you currently treat at a real IRQ id, AFAICT.
>
> correct there is no handling for irq = -1. So netif_napi_set_irq() needs
> to add the irq to the rm
On 2025-01-14 3:08 p.m., Jakub Kicinski wrote:
On Mon, 13 Jan 2025 10:10:37 -0700 Ahmed Zaki wrote:
-#endif /* CONFIG_RFS_ACCEL */
+ return netif_enable_cpu_rmap(adapter->netdev, adapter->num_io_queues);
+#else
return 0;
+#endif /* CONFIG_RFS_ACCEL */
Let's try to eliminate so
On Tue, Jan 14, 2025 at 09:32:26AM +0100, Daniel Sedlak wrote:
>
>
> On 1/13/25 10:15 PM, Jakub Kicinski wrote:
> >
> > We do have an API for that
> > https://docs.kernel.org/next/networking/netlink_spec/netdev.html#napi
> > but unfortunately the driver needs to support it, and i40e currently
>
On Mon, 13 Jan 2025 10:10:37 -0700 Ahmed Zaki wrote:
> -#endif /* CONFIG_RFS_ACCEL */
> + return netif_enable_cpu_rmap(adapter->netdev, adapter->num_io_queues);
> +#else
> return 0;
> +#endif /* CONFIG_RFS_ACCEL */
Let's try to eliminate some of the ifdef-ery on the driver side.
netif_en
-13.2.0
arc allyesconfiggcc-13.2.0
arc randconfig-001-20250114gcc-13.2.0
arc randconfig-002-20250114gcc-13.2.0
arm allmodconfiggcc-14.2.0
arm allnoconfigclang-17
> -Original Message-
> From: Intel-wired-lan On Behalf Of Simon
> Horman
> Sent: Monday, January 6, 2025 11:24 AM
> To: Kitszel, Przemyslaw
> Cc: intel-wired-...@lists.osuosl.org; Nguyen, Anthony L
> ; net...@vger.kernel.org; Dan Carpenter
> ; Zaki, Ahmed ; Zaremba,
> Larysa
> Subject: R
-13.2.0
arc allyesconfiggcc-13.2.0
arc randconfig-001-20250114gcc-13.2.0
arc randconfig-002-20250114gcc-13.2.0
arm allmodconfiggcc-14.2.0
arm allnoconfigclang
gcc-13.2.0
arc allyesconfiggcc-13.2.0
arc axs101_defconfiggcc-13.2.0
arc randconfig-001-20250114gcc-13.2.0
arc randconfig-002-20250114gcc-13.2.0
arm allmodconfig
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Buvaneswaran, Sujai
> Sent: Monday, January 13, 2025 9:17 AM
> To: Marcin Szycik ; intel-wired-
> l...@lists.osuosl.org
> Cc: net...@vger.kernel.org; Michal Swiatkowski
>
> Subject: Re: [Intel-wired-lan] [PATCH iwl-net] ice: Fix
On Tue, Jan 14, 2025 at 01:11:13PM +0100, Milena Olech wrote:
> Add functions to request Tx timestamp for the PTP packets, read the Tx
> timestamp when the completion tag for that packet is being received,
> extend the Tx timestamp value and set the supported timestamping modes.
>
> Tx timestamp i
> Add a new netdev flag "rx_cpu_rmap_auto". Drivers supporting ARFS should
> set the flag via netif_enable_cpu_rmap() and core will allocate and manage
> the ARFS rmap. Freeing the rmap is also done by core when the netdev is
> freed.
>
> Signed-off-by: Ahmed Zaki
> ---
> drivers/net/ethernet/am
On 1/13/25 10:15 PM, Jakub Kicinski wrote:
On Fri, 10 Jan 2025 10:07:18 +0100 Daniel Sedlak wrote:
Hello,
I am writing an affinity scheduler in the userspace for network cards's
Tx/Rx queues. Is there a generic way to retrieve all IRQ numbers for
those queues for each interface?
My goal is t
Enable Launch Time Control (LTC) support to XDP zero copy via XDP Tx
metadata framework.
This patch is tested with tools/testing/selftests/bpf/xdp_hw_metadata on
Intel I225-LM Ethernet controller. Below are the test steps and result.
Test Steps:
1. At DUT, start xdp_hw_metadata selftest applicati
Add launch time hardware offload request to xdp_hw_metadata. Users can
configure the delta of launch time relative to HW RX-time using the "-l"
argument. By default, the delta is set to 0 ns, which means the launch time
is disabled. By setting the delta to a non-zero value, the launch time
hardware
Enable launch time (Time-Based Scheduling) support to XDP zero copy via XDP
Tx metadata framework.
This patch is tested with tools/testing/selftests/bpf/xdp_hw_metadata on
Intel Tiger Lake platform. Below are the test steps and result.
Test Steps:
1. At DUT, start xdp_hw_metadata selftest applica
Extend the XDP Tx metadata framework so that user can requests launch time
hardware offload, where the Ethernet device will schedule the packet for
transmission at a pre-determined time called launch time. The value of
launch time is communicated from user space to Ethernet driver via
launch_time f
This series expands the XDP TX metadata framework to allow user
applications to pass per packet 64-bit launch time directly to the kernel
driver, requesting launch time hardware offload support. The XDP TX
metadata framework will not perform any clock conversion or packet
reordering.
Please note t
On 10/01/2025 14.06, Yunsheng Lin wrote:
This patchset fix a possible time window problem for page_pool and
the dma API misuse problem as mentioned in [1], and try to avoid the
overhead of the fixing using some optimization.
From the below performance data, the overhead is not so obvious
due
>-Original Message-
>From: Dheeraj Reddy Jonnalagadda
>Sent: Tuesday, January 14, 2025 1:23 AM
>To: Kwapulinski, Piotr
>Cc: andrew+net...@lunn.ch; Nguyen, Anthony L ;
>da...@davemloft.net; eduma...@google.com; intel-wired-...@lists.osuosl.org;
>k...@kernel.org; linux-ker...@vger.kernel
Since workqueues are created per CPU, the works scheduled to this
workqueues are run on the CPU they were assigned. It may result in
overloaded CPU that is not able to handle virtchnl messages in
relatively short time. Allocating workqueue with WQ_UNBOUND and
WQ_HIGHPRI flags allows scheduler to qu
PTP capabilities are negotiated using virtchnl command. Add get
capabilities function, direct access to read the PTP clock time and
direct access to read the cross timestamp - system time and PTP clock
time. Set initial PTP capabilities exposed to the stack.
Reviewed-by: Alexander Lobakin
Reviewe
Move virtchnl structures to the header file to expose them for the PTP
virtchnl file.
Reviewed-by: Alexander Lobakin
Reviewed-by: Willem de Bruijn
Signed-off-by: Milena Olech
---
v1 -> v2: fix commit message title
.../net/ethernet/intel/idpf/idpf_virtchnl.c | 86 +--
.../net
This patch series introduces support for Precision Time Protocol (PTP) to
Intel(R) Infrastructure Data Path Function (IDPF) driver. PTP feature is
supported when the PTP capability is negotiated with the Control
Plane (CP). IDPF creates a PTP clock and sets a set of supported
functions.
During the
Add Rx timestamp function when the Rx timestamp value is read directly
from the Rx descriptor. In order to extend the Rx timestamp value to 64
bit in hot path, the PHC time is cached in the receive groups.
Add supported Rx timestamp modes.
Reviewed-by: Willem de Bruijn
Signed-off-by: Milena Olech
Add functions to request Tx timestamp for the PTP packets, read the Tx
timestamp when the completion tag for that packet is being received,
extend the Tx timestamp value and set the supported timestamping modes.
Tx timestamp is requested for the PTP packets by setting a TSYN bit and
index value in
Tx timestamp capabilities are negotiated for the uplink Vport.
Driver receives information about the number of available Tx timestamp
latches, the size of Tx timestamp value and the set of indexes used
for Tx timestamping.
Add function to get the Tx timestamp capabilities and parse the uplink
vpor
PTP clock configuration operations - set time, adjust time and adjust
frequency are required to control the clock and maintain synchronization
process.
Extend get PTP capabilities function to request for the clock adjustments
and add functions to enable these actions using dedicated virtchnl
messa
When the access to read PTP clock is specified as mailbox, the driver
needs to send virtchnl message to perform PTP actions. Message is sent
using idpf_mbq_opc_send_msg_to_peer_drv mailbox opcode, with the parameters
received during PTP capabilities negotiation.
Add functions to recognize PTP mess
PTP capabilities are negotiated using virtchnl commands. There are two
available modes of the PTP support: direct and mailbox. When the direct
access to PTP resources is negotiated, virtchnl messages returns a set
of registers that allow read/write directly. When the mailbox access to
PTP resources
PTP feature is supported if the VIRTCHNL2_CAP_PTP is negotiated during the
capabilities recognition. Initial PTP support includes PTP initialization
and registration of the clock.
Reviewed-by: Alexander Lobakin
Reviewed-by: Vadim Fedorenko
Reviewed-by: Willem de Bruijn
Signed-off-by: Milena Ole
On 1/10/25 07:34, Dan Carpenter wrote:
Hello Yue Haibing,
Dan, Thank you for the report.
@Piotr, could you please fix it?
Commit c824125cbb18 ("ixgbe: Fix passing 0 to ERR_PTR in
ixgbe_run_xdp()") from Jan 6, 2025 (linux-next), leads to the
following Smatch static checker warning:
Olech, Milena wrote:
> On 01/10/2025 10:34PM Willem de Bruijn wrote:
>
> > > > > Add functions to request Tx timestamp for the PTP packets, read the Tx
> > > > > timestamp when the completion tag for that packet is being received,
> > > > > extend the Tx timestamp value and set the supported times
35 matches
Mail list logo
