From: Simon Horman <horms@kernel.org>
To: Erwan Velu <erwanaliasr1@gmail.com>
Cc: Erwan Velu <e.velu@criteo.com>,
linux-kernel@vger.kernel.org, Eric Dumazet <edumazet@google.com>,
netdev@vger.kernel.org, Tony Nguyen <anthony.l.nguyen@intel.com>,
intel-wired-lan@lists.osuosl.org,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [Intel-wired-lan] [PATCH v4 iwl-net] i40e: Prevent setting MTU if greater than MFS
Date: Mon, 18 Mar 2024 17:45:03 +0000 [thread overview]
Message-ID: <20240318174503.GE1623@kernel.org> (raw)
In-Reply-To: <20240313090719.33627-2-e.velu@criteo.com>
On Wed, Mar 13, 2024 at 10:07:16AM +0100, Erwan Velu wrote:
> Commit 6871a7de705 ("[intelxl] Use admin queue to set port MAC address
> and maximum frame size") from iPXE project set the MFS to 0x600 = 1536.
> See https://github.com/ipxe/ipxe/commit/6871a7de705
>
> At boot time the i40e driver complains about it with
> the following message but continues.
>
> MFS for port 1 has been set below the default: 600
>
> If the MTU size is increased, the driver accepts it but large packets will
> not be processed by the firmware generating tx_errors. The issue is pretty
> silent for users. i.e doing TCP in such context will generates lots of
> retransmissions until the proper window size (below 1500) will be used.
>
> To fix this case, it would have been ideal to increase the MFS,
> via i40e_aqc_opc_set_mac_config, incoming patch will take care of it.
>
> At least, commit prevents setting up an MTU greater than the current MFS.
> It will avoid being in the position of having an MTU set to 9000 on the
> netdev with a firmware refusing packets larger than 1536.
>
> A typical trace looks like:
> [ 377.548696] i40e 0000:5d:00.0 eno5: Error changing mtu to 9000, Max is 1500. MFS is too small.
>
Hi Erwan, all,
As a fix, I think this patch warrants a fixes tag.
Perhaps this one is appropriate?
Fixes: 41c445ff0f48 ("i40e: main driver core")
> Signed-off-by: Erwan Velu <e.velu@criteo.com>
> ---
> drivers/net/ethernet/intel/i40e/i40e_main.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
> index f86578857e8a..85ecf2f3de18 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_main.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
> @@ -2946,7 +2946,7 @@ static int i40e_change_mtu(struct net_device *netdev, int new_mtu)
> struct i40e_netdev_priv *np = netdev_priv(netdev);
> struct i40e_vsi *vsi = np->vsi;
> struct i40e_pf *pf = vsi->back;
> - int frame_size;
> + int frame_size, mfs, max_mtu;
>
> frame_size = i40e_max_vsi_frame_size(vsi, vsi->xdp_prog);
> if (new_mtu > frame_size - I40E_PACKET_HDR_PAD) {
I am fine with this patch, so please take what follows as a suggestion
for improvement, possibly as a follow-up. Not as a hard requirement from
my side.
The part of this function between the two hunks of this patch is:
netdev_err(netdev, "Error changing mtu to %d, Max is %d\n",
new_mtu, frame_size - I40E_PACKET_HDR_PAD);
My reading is that with this patch two different limits are
checked wrt maximum MTU size:
1. A VSI level limit, which relates to RX buffer size
2. A PHY level limit that relates to the MFS
That seems fine to me. But the log message for 1 (above) does
not seem particularly informative wrt which limit has been exceeded.
> @@ -2955,6 +2955,14 @@ static int i40e_change_mtu(struct net_device *netdev, int new_mtu)
> return -EINVAL;
> }
>
> + mfs = pf->hw.phy.link_info.max_frame_size;
> + max_mtu = mfs - I40E_PACKET_HDR_PAD;
> + if (new_mtu > max_mtu) {
> + netdev_err(netdev, "Error changing mtu to %d, Max is %d. MFS is too small.\n",
> + new_mtu, max_mtu);
> + return -EINVAL;
> + }
> +
> netdev_dbg(netdev, "changing MTU from %d to %d\n",
> netdev->mtu, new_mtu);
> netdev->mtu = new_mtu;
> --
> 2.44.0
>
>
WARNING: multiple messages have this Message-ID (diff)
From: Simon Horman <horms@kernel.org>
To: Erwan Velu <erwanaliasr1@gmail.com>
Cc: Erwan Velu <e.velu@criteo.com>,
Jesse Brandeburg <jesse.brandeburg@intel.com>,
Tony Nguyen <anthony.l.nguyen@intel.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 iwl-net] i40e: Prevent setting MTU if greater than MFS
Date: Mon, 18 Mar 2024 17:45:03 +0000 [thread overview]
Message-ID: <20240318174503.GE1623@kernel.org> (raw)
In-Reply-To: <20240313090719.33627-2-e.velu@criteo.com>
On Wed, Mar 13, 2024 at 10:07:16AM +0100, Erwan Velu wrote:
> Commit 6871a7de705 ("[intelxl] Use admin queue to set port MAC address
> and maximum frame size") from iPXE project set the MFS to 0x600 = 1536.
> See https://github.com/ipxe/ipxe/commit/6871a7de705
>
> At boot time the i40e driver complains about it with
> the following message but continues.
>
> MFS for port 1 has been set below the default: 600
>
> If the MTU size is increased, the driver accepts it but large packets will
> not be processed by the firmware generating tx_errors. The issue is pretty
> silent for users. i.e doing TCP in such context will generates lots of
> retransmissions until the proper window size (below 1500) will be used.
>
> To fix this case, it would have been ideal to increase the MFS,
> via i40e_aqc_opc_set_mac_config, incoming patch will take care of it.
>
> At least, commit prevents setting up an MTU greater than the current MFS.
> It will avoid being in the position of having an MTU set to 9000 on the
> netdev with a firmware refusing packets larger than 1536.
>
> A typical trace looks like:
> [ 377.548696] i40e 0000:5d:00.0 eno5: Error changing mtu to 9000, Max is 1500. MFS is too small.
>
Hi Erwan, all,
As a fix, I think this patch warrants a fixes tag.
Perhaps this one is appropriate?
Fixes: 41c445ff0f48 ("i40e: main driver core")
> Signed-off-by: Erwan Velu <e.velu@criteo.com>
> ---
> drivers/net/ethernet/intel/i40e/i40e_main.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
> index f86578857e8a..85ecf2f3de18 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_main.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
> @@ -2946,7 +2946,7 @@ static int i40e_change_mtu(struct net_device *netdev, int new_mtu)
> struct i40e_netdev_priv *np = netdev_priv(netdev);
> struct i40e_vsi *vsi = np->vsi;
> struct i40e_pf *pf = vsi->back;
> - int frame_size;
> + int frame_size, mfs, max_mtu;
>
> frame_size = i40e_max_vsi_frame_size(vsi, vsi->xdp_prog);
> if (new_mtu > frame_size - I40E_PACKET_HDR_PAD) {
I am fine with this patch, so please take what follows as a suggestion
for improvement, possibly as a follow-up. Not as a hard requirement from
my side.
The part of this function between the two hunks of this patch is:
netdev_err(netdev, "Error changing mtu to %d, Max is %d\n",
new_mtu, frame_size - I40E_PACKET_HDR_PAD);
My reading is that with this patch two different limits are
checked wrt maximum MTU size:
1. A VSI level limit, which relates to RX buffer size
2. A PHY level limit that relates to the MFS
That seems fine to me. But the log message for 1 (above) does
not seem particularly informative wrt which limit has been exceeded.
> @@ -2955,6 +2955,14 @@ static int i40e_change_mtu(struct net_device *netdev, int new_mtu)
> return -EINVAL;
> }
>
> + mfs = pf->hw.phy.link_info.max_frame_size;
> + max_mtu = mfs - I40E_PACKET_HDR_PAD;
> + if (new_mtu > max_mtu) {
> + netdev_err(netdev, "Error changing mtu to %d, Max is %d. MFS is too small.\n",
> + new_mtu, max_mtu);
> + return -EINVAL;
> + }
> +
> netdev_dbg(netdev, "changing MTU from %d to %d\n",
> netdev->mtu, new_mtu);
> netdev->mtu = new_mtu;
> --
> 2.44.0
>
>
next prev parent reply other threads:[~2024-03-18 17:45 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-13 9:07 [Intel-wired-lan] [PATCH v4 iwl-net] i40e: Prevent setting MTU if greater than MFS Erwan Velu
2024-03-13 9:07 ` Erwan Velu
2024-03-14 16:10 ` [Intel-wired-lan] " Brett Creeley
2024-03-14 16:10 ` Brett Creeley
2024-03-14 17:10 ` [Intel-wired-lan] " Erwan Velu
2024-03-14 17:10 ` Erwan Velu
2024-03-14 17:55 ` [Intel-wired-lan] " Brett Creeley
2024-03-14 17:55 ` Brett Creeley
2024-03-14 18:04 ` [Intel-wired-lan] " Erwan Velu
2024-03-14 18:04 ` Erwan Velu
2024-03-14 20:31 ` [Intel-wired-lan] " Tony Nguyen
2024-03-14 20:31 ` Tony Nguyen
2024-03-15 9:17 ` [Intel-wired-lan] " Erwan Velu
2024-03-15 9:17 ` Erwan Velu
2024-03-15 16:19 ` [Intel-wired-lan] " Brett Creeley
2024-03-15 16:19 ` Brett Creeley
2024-03-18 17:45 ` Simon Horman [this message]
2024-03-18 17:45 ` Simon Horman
2024-03-19 10:26 ` [Intel-wired-lan] " Sunil Kovvuri Goutham
2024-03-19 10:26 ` Sunil Kovvuri Goutham
2024-03-19 11:38 ` [Intel-wired-lan] " Erwan Velu
2024-03-19 12:20 ` Simon Horman
2024-03-19 12:20 ` Simon Horman
2024-03-19 13:33 ` [Intel-wired-lan] " Erwan Velu
2024-03-19 13:33 ` Erwan Velu
2024-04-19 14:26 ` [Intel-wired-lan] " Pucha, HimasekharX Reddy
2024-04-19 14:26 ` Pucha, HimasekharX Reddy
[not found] ` <CAL2JzuxraP5xCxt4_EK3zbz9kyAyxJFuEadtq4zHsdMjR5PGTw@mail.gmail.com>
2024-04-22 13:19 ` Pucha, HimasekharX Reddy
2024-04-22 13:19 ` Pucha, HimasekharX Reddy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240318174503.GE1623@kernel.org \
--to=horms@kernel.org \
--cc=anthony.l.nguyen@intel.com \
--cc=davem@davemloft.net \
--cc=e.velu@criteo.com \
--cc=edumazet@google.com \
--cc=erwanaliasr1@gmail.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.