[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <e98d2126-df54-4a75-896a-fc5915f94894@intel.com>
Date: Wed, 27 Aug 2025 09:18:31 -0700
From: Jacob Keller <jacob.e.keller@...el.com>
To: Simon Horman <horms@...nel.org>
CC: <kheib@...hat.com>, Paul Menzel <pmenzel@...gen.mpg.de>, Anthony Nguyen
<anthony.l.nguyen@...el.com>, Intel Wired LAN
<intel-wired-lan@...ts.osuosl.org>, Przemek Kitszel
<przemyslaw.kitszel@...el.com>, <netdev@...r.kernel.org>
Subject: Re: [PATCH iwl-net v2] i40e: fix Jumbo Frame support after iPXE boot
On 8/27/2025 3:37 AM, Simon Horman wrote:
> On Fri, Aug 15, 2025 at 05:20:39PM -0700, Jacob Keller wrote:
>> The i40e hardware has multiple hardware settings which define the Maximum
>> Frame Size (MFS) of the physical port. The firmware has an AdminQ command
>> (0x0603) to configure the MFS, but the i40e Linux driver never issues this
>> command.
>>
>> In most cases this is no problem, as the NVM default value has the device
>> configured for its maximum value of 9728. Unfortunately, recent versions of
>> the iPXE intelxl driver now issue the 0x0603 Set Mac Config command,
>> modifying the MFS and reducing it from its default value of 9728.
>>
>> This occurred as part of iPXE commit 6871a7de705b ("[intelxl] Use admin
>> queue to set port MAC address and maximum frame size"), a prerequisite
>> change for supporting the E800 series hardware in iPXE. Both the E700 and
>> E800 firmware support the AdminQ command, and the iPXE code shares much of
>> the logic between the two device drivers.
>>
>> The ice E800 Linux driver already issues the 0x0603 Set Mac Config command
>> early during probe, and is thus unaffected by the iPXE change.
>>
>> Since commit 3a2c6ced90e1 ("i40e: Add a check to see if MFS is set"), the
>> i40e driver does check the I40E_PRTGL_SAH register, but it only logs a
>> warning message if its value is below the 9728 default. This register also
>> only covers received packets and not transmitted packets. A warning can
>> inform system administrators, but does not correct the issue. No
>> interactions from userspace cause the driver to write to PRTGL_SAH or issue
>> the 0x0603 AdminQ command. Only a GLOBR reset will restore the value to its
>> default value. There is no obvious method to trigger a GLOBR reset from
>> user space.
>>
>> To fix this, introduce the i40e_aq_set_mac_config() function, similar to
>> the one from the ice driver. Call this during early probe to ensure that
>> the device configuration matches driver expectation.
>>
>> In addition, instead of just checking the I40E_PRTGL_SAH register, update
>> its value to the 9728 default and write it back. This ensures that the
>> hardware is in the expected state, regardless of whether the iPXE (or any
>> other early boot driver) has modified this state.
>>
>> This is a better user experience, as we now fix the issues with larger MTU
>> instead of merely warning. It also aligns with the way the ice E800 series
>> driver works.
>>
>> A final note: The Fixes tag provided here is not strictly accurate. The
>> issue occurs as a result of an external entity (the iPXE intelxl driver),
>> and this is not a regression specifically caused by the mentioned change.
>> However, I believe the original change to just warn about PRTGL_SAH being
>> too low was an insufficient fix.
>>
>> Fixes: 3a2c6ced90e1 ("i40e: Add a check to see if MFS is set")
>> Link: https://github.com/ipxe/ipxe/commit/6871a7de705b6f6a4046f0d19da9bcd689c3bc8e
>> Signed-off-by: Jacob Keller <jacob.e.keller@...el.com>
>
> Reviewed-by: Simon Horman <horms@...nel.org>
>
Unfortunately, we recently discovered that this has causes a regression
in some cases for Tx traffic. Still investigating, but Tony dropped it
from his tree. Will try to figure out what is wrong here and submit a v3.
Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (237 bytes)
Powered by blists - more mailing lists