GCC 7 is not as good as GCC 8+ in telling what is a compile-time const,
and thus could be used for static storage. So we could not use variables
for that, no matter how much "const" keyword is sprinkled around.
Excerpt from the report:
My GCC is: gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0.
CC [M]
Packet buffers (RX + TX) total 64KB. Neither RX or TX buffers can be
larger than 34KB. So divide the buffer equally, 32KB for each.
Co-developed-by: Vinicius Costa Gomes
Signed-off-by: Vinicius Costa Gomes
Signed-off-by: Faizal Rahim
---
drivers/net/ethernet/intel/igc/igc_defines.h | 3 ++-
1
On 2/5/25 04:18, Zhuo, Qiuxu wrote:
Hi,
I got the build error messages as below:
My GCC is: gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0.
Thank you for the report, FTR this is the same GCC version as used by
SLES 15, even the current ones :(
I will send a fix.
I would love to bump minimal gcc ver
On 1/31/2025 3:21 AM, Stephen Hemminger wrote:
On Thu, 30 Jan 2025 21:17:30 +0200
"Lifshits, Vitaly" wrote:
On 1/30/2025 7:11 PM, Stephen Hemminger wrote:
I am using:
5a:00.0 Ethernet controller: Intel Corporation Ethernet Controller I226-LM (rev
04)
Subsystem: Intel Corporation
On Wed, Feb 05, 2025 at 03:18:30AM +, Zhuo, Qiuxu wrote:
> Hi,
>
> I got the build error messages as below:
> My GCC is: gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0.
>
Try compiling with gcc 8.1 or newer.
Thanks,
Michal
>
> CC [M] drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.o
> drivers
On Wed, Feb 05, 2025 at 10:36:03AM +0800, Song Yoong Siang wrote:
> Set the buffer type to IGC_TX_BUFFER_TYPE_SKB for empty frame in the
> igc_init_empty_frame function. This ensures that the buffer type is
> correctly identified and handled during Tx ring cleanup.
>
> Fixes: db0b124f02ba ("igc: E
gcc-13.2.0
arc defconfiggcc-14.2.0
arc nsimosci_hs_smp_defconfiggcc-14.2.0
arc randconfig-001-20250205gcc-13.2.0
arc randconfig-002-20250205gcc-13.2.0
arc tb10x_defconfig
On Wed, Feb 05, 2025 at 03:43:19PM +0100, Song, Yoong Siang wrote:
> On Wednesday, February 5, 2025 8:31 PM, Fijalkowski, Maciej
> wrote:
> >On Wed, Feb 05, 2025 at 10:41:15AM +0800, Song Yoong Siang wrote:
> >> Refactor the code for inserting an empty packet into a new function
> >> igc_insert_e
> From: Kitszel, Przemyslaw
> [...]
> Subject: [PATCH iwl-net] ice: health.c: fix compilation on gcc 7.5
>
> GCC 7 is not as good as GCC 8+ in telling what is a compile-time const, and
> thus could be used for static storage. So we could not use variables for that,
> no matter how much "const" ke
Hi,
I got the build error messages as below:
My GCC is: gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0.
CC [M] drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.o
drivers/net/ethernet/intel/ice/devlink/health.c:35:3: error: initializer
element is not constant
ice_common_port_solutions, {ice_port_n
Renamed xdp_get_tx_ring() function to a more generic name for use in
upcoming frame preemption patches.
Signed-off-by: Faizal Rahim
---
drivers/net/ethernet/intel/igc/igc.h | 2 +-
drivers/net/ethernet/intel/igc/igc_main.c | 10 +-
2 files changed, 6 insertions(+), 6 deletions(-)
From: Vladimir Oltean
It appears that stmmac is not the only hardware which requires a
software-driven verification state machine for the MAC Merge layer.
While on the one hand it's good to encourage hardware implementations,
on the other hand it's quite difficult to tolerate multiple drivers
im
Introduces support for the FPE feature in the IGC driver.
The patches aligns with the upstream FPE API:
https://patchwork.kernel.org/project/netdevbpf/cover/20230220122343.1156614-1-vladimir.olt...@nxp.com/
https://patchwork.kernel.org/project/netdevbpf/cover/20230119122705.73054-1-vladimir.olt...
Implement "ethtool --show-mm" callback for IGC.
Tested with command:
$ ethtool --show-mm enp1s0.
MAC Merge layer state for enp1s0:
pMAC enabled: on
TX enabled: on
TX active: on
TX minimum fragment size: 64
RX minimum fragment size: 60
Verify enabled: on
Verify time: 128
Max verif
This patch implements the "ethtool --set-mm" callback to trigger the
frame preemption verification handshake.
Uses the MAC Merge Software Verification (mmsv) mechanism in ethtool
to perform the verification handshake for igc.
The structure fpe.mmsv is set by mmsv in ethtool and should remain
read-
Add support to set tx-min-frag-size via set_mm callback in igc.
Increase the max limit of tx-ming-frag-size in ethtool from 252 to 256
since i225/6 value range is 64, 128, 192 and 256.
Co-developed-by: Vinicius Costa Gomes
Signed-off-by: Vinicius Costa Gomes
Signed-off-by: Faizal Rahim
---
dri
In preparation for supporting frame preemption, when entering TSN mode
set the receive packet buffer to 16KB for the Express MAC, 16KB for
the Preemptible MAC and 2KB for the BMC, according to the datasheet
section 7.1.3.2.
Co-developed-by: Vinicius Costa Gomes
Signed-off-by: Vinicius Costa Gomes
Implemented "ethtool --include-statistics --show-mm" callback for IGC.
Tested preemption scenario to check preemption statistics:
1) Trigger verification handshake on both boards:
$ sudo ethtool --set-mm enp1s0 pmac-enabled on
$ sudo ethtool --set-mm enp1s0 tx-enabled on
$ sudo ethtool
Set queue as preemptible or express for taprio.
This will eventually set queue-specific preemptible field in TXQCTL
register.
Verified that the correct preemptible hardware queue is set using the
following commands:
a) 1:1 TC-to-Queue Mapping
$ sudo tc qdisc replace dev enp1s0 parent root hand
On Wed, Feb 05, 2025 at 11:42:12AM +0100, Przemek Kitszel wrote:
> GCC 7 is not as good as GCC 8+ in telling what is a compile-time const,
> and thus could be used for static storage. So we could not use variables
> for that, no matter how much "const" keyword is sprinkled around.
>
> Excerpt from
On Wed, Feb 05, 2025 at 05:05:20AM -0500, Faizal Rahim wrote:
> This patch implements the "ethtool --set-mm" callback to trigger the
> frame preemption verification handshake.
>
> Uses the MAC Merge Software Verification (mmsv) mechanism in ethtool
> to perform the verification handshake for igc.
On 05. 02. 25, 21:45, Simon Horman wrote:
+ Jiri
On Wed, Feb 05, 2025 at 11:42:12AM +0100, Przemek Kitszel wrote:
GCC 7 is not as good as GCC 8+ in telling what is a compile-time const,
and thus could be used for static storage. So we could not use variables
for that, no matter how much "const"
On 05. 02. 25, 23:56, David Laight wrote:
On Wed, 5 Feb 2025 20:45:46 +
Simon Horman wrote:
+ Jiri
On Wed, Feb 05, 2025 at 11:42:12AM +0100, Przemek Kitszel wrote:
GCC 7 is not as good as GCC 8+ in telling what is a compile-time const,
and thus could be used for static storage. So we cou
From: Leon Romanovsky
XFRM offload path is probed even if offload isn't needed at all. Let's
make sure that x->type_offload pointer stays NULL for such path to
reduce ambiguity.
Fixes: 9d389d7f84bb ("xfrm: Add a xfrm type offload.")
Signed-off-by: Leon Romanovsky
---
include/net/xfrm.h | 1
From: Leon Romanovsky
SA replay mode is initialized differently for user-space and
kernel-space users, but the call to xfrm_init_replay() existed in
common path with boolean protection. That caused to situation where
we have two different function orders.
So let's rewrite the SA initialization f
From: Leon Romanovsky
Almost all drivers except bond and nsim had same check if device
can perform XFRM offload on that specific packet. The check was that
packet doesn't have IPv4 options and IPv6 extensions.
In NIC drivers, the IPv4 HELEN comparison was slightly different, but
the intent was t
From: Leon Romanovsky
In tunnel mode, for the packet offload, there were no PMTU signaling
to the upper level about need to fragment the packet. As a solution,
call to already existing xfrm[4|6]_tunnel_check_size() to perform that.
Signed-off-by: Leon Romanovsky
---
include/net/xfrm.h | 9
From: Leon Romanovsky
After change of initialization of x->type_offload pointer to be valid
only for offloaded SAs. There is no need to rely both on x->type_offload
and x->xso.type to determine if SA is offloaded or not.
Signed-off-by: Leon Romanovsky
---
net/xfrm/xfrm_device.c | 10 --
gcc-14.2.0
arc randconfig-001-20250205gcc-13.2.0
arc randconfig-002-20250205gcc-13.2.0
arc tb10x_defconfiggcc-14.2.0
arm allmodconfiggcc-14.2.0
arm allnoconfig
On Wednesday, February 5, 2025 8:31 PM, Fijalkowski, Maciej
wrote:
>On Wed, Feb 05, 2025 at 10:41:15AM +0800, Song Yoong Siang wrote:
>> Refactor the code for inserting an empty packet into a new function
>> igc_insert_empty_packet(). This change extracts the logic for inserting
>> an empty packe
+ Jiri
On Wed, Feb 05, 2025 at 11:42:12AM +0100, Przemek Kitszel wrote:
> GCC 7 is not as good as GCC 8+ in telling what is a compile-time const,
> and thus could be used for static storage. So we could not use variables
> for that, no matter how much "const" keyword is sprinkled around.
>
> Exce
On 2025-02-04 3:43 p.m., Joe Damato wrote:
On Tue, Feb 04, 2025 at 03:06:19PM -0700, Ahmed Zaki wrote:
A common task for most drivers is to remember the user-set CPU affinity
to its IRQs. On each netdev reset, the driver should re-assign the
user's settings to the IRQs.
Add CPU affinity mask
On Wed, Feb 05, 2025 at 10:36:03AM +0800, Song Yoong Siang wrote:
> Set the buffer type to IGC_TX_BUFFER_TYPE_SKB for empty frame in the
> igc_init_empty_frame function. This ensures that the buffer type is
> correctly identified and handled during Tx ring cleanup.
>
> Fixes: db0b124f02ba ("igc: E
gcc-13.2.0
arc allyesconfiggcc-13.2.0
arc randconfig-001-20250205gcc-13.2.0
arc randconfig-002-20250205gcc-13.2.0
arm allmodconfiggcc-14.2.0
arm allnoconfig
Hi,
This series refactors the xdo_dev_offload_ok() to be global place for
drivers to check if their offload can perform encryption for xmit packets.
Such common place gives us an option to check MTU and PMTU at one place.
Thanks
Leon Romanovsky (5):
xfrm: delay initialization of offload path
gcc-13.2.0
arc allyesconfiggcc-13.2.0
arc randconfig-001-20250205gcc-13.2.0
arc randconfig-002-20250205gcc-13.2.0
arc vdk_hs38_smp_defconfiggcc-13.2.0
arm allmodconfiggcc
On Wed, 5 Feb 2025 12:36:31 +0200
"Lifshits, Vitaly" wrote:
> On 1/31/2025 3:21 AM, Stephen Hemminger wrote:
> > On Thu, 30 Jan 2025 21:17:30 +0200
> > "Lifshits, Vitaly" wrote:
> >
> >> On 1/30/2025 7:11 PM, Stephen Hemminger wrote:
> >>> I am using:
> >>>
> >>> 5a:00.0 Ethernet controller
On Thursday, February 6, 2025 12:08 AM, Fijalkowski, Maciej
wrote:
>On Wed, Feb 05, 2025 at 03:43:19PM +0100, Song, Yoong Siang wrote:
>> On Wednesday, February 5, 2025 8:31 PM, Fijalkowski,
>> Maciej wrote:
>> >On Wed, Feb 05, 2025 at 10:41:15AM +0800, Song Yoong Siang wrote:
>> >> Refactor the
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
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
Enable launch time (Time-Based Scheduling) support for XDP zero copy via
the XDP Tx metadata framework.
This patch has been tested with tools/testing/selftests/bpf/xdp_hw_metadata
on Intel Tiger Lake platform. Below are the test steps and result.
Test 1: Send a single packet with the launch time
Refactor the code for inserting an empty frame into a new function
igc_insert_empty_frame(). This change extracts the logic for inserting
an empty packet from igc_xmit_frame_ring() into a separate function,
allowing it to be reused in future implementations, such as the XDP
zero copy transmit funct
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 Control (LTC) support for XDP zero copy via XDP Tx
metadata framework.
This patch has been tested with tools/testing/selftests/bpf/xdp_hw_metadata
on Intel I225-LM Ethernet controller. Below are the test steps and result.
Test 1: Send a single packet with the launch time set to
On Wed, Feb 05, 2025 at 10:41:15AM +0800, Song Yoong Siang wrote:
> Refactor the code for inserting an empty packet into a new function
> igc_insert_empty_packet(). This change extracts the logic for inserting
> an empty packet from igc_xmit_frame_ring() into a separate function,
> allowing it to b
45 matches
Mail list logo
