From: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
To: Jason Xing <kerneljasonxing@gmail.com>
Cc: <jesse.brandeburg@intel.com>, <anthony.l.nguyen@intel.com>,
<davem@davemloft.net>, <edumazet@google.com>, <kuba@kernel.org>,
<pabeni@redhat.com>, <richardcochran@gmail.com>, <ast@kernel.org>,
<daniel@iogearbox.net>, <hawk@kernel.org>,
<john.fastabend@gmail.co>, <intel-wired-lan@lists.osuosl.org>,
<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<bpf@vger.kernel.org>, Jason Xing <kernelxing@tencent.com>,
<magnus.karlsson@intel.com>, <tirthendu.sarkar@intel.com>,
<alexandr.lobakin@intel.com>
Subject: Re: [PATCH net] ixgbe: allow to increase MTU to some extent with XDP enalbed
Date: Thu, 26 Jan 2023 13:17:20 +0100 [thread overview]
Message-ID: <Y9JvUKBgBifiosOa@boxer> (raw)
In-Reply-To: <20230121085521.9566-1-kerneljasonxing@gmail.com>
On Sat, Jan 21, 2023 at 04:55:21PM +0800, Jason Xing wrote:
> From: Jason Xing <kernelxing@tencent.com>
>
> I encountered one case where I cannot increase the MTU size with XDP
> enabled if the server is equipped with IXGBE card, which happened on
> thousands of servers. I noticed it was prohibited from 2017[1] and
> added size checks[2] if allowed soon after the previous patch.
>
> Interesting part goes like this:
> 1) Changing MTU directly from 1500 (default value) to 2000 doesn't
> work because the driver finds out that 'new_frame_size >
> ixgbe_rx_bufsz(ring)' in ixgbe_change_mtu() function.
> 2) However, if we change MTU to 1501 then change from 1501 to 2000, it
> does work, because the driver sets __IXGBE_RX_3K_BUFFER when MTU size
> is converted to 1501, which later size check policy allows.
>
> The default MTU value for most servers is 1500 which cannot be adjusted
> directly to the value larger than IXGBE_MAX_2K_FRAME_BUILD_SKB (1534 or
> 1536) if it loads XDP.
>
> After I do a quick study on the manner of i40E driver allowing two kinds
> of buffer size (one is 2048 while another is 3072) to support XDP mode in
> i40e_max_xdp_frame_size(), I believe the default MTU size is possibly not
> satisfied in XDP mode when IXGBE driver is in use, we sometimes need to
> insert a new header, say, vxlan header. So setting the 3K-buffer flag
> could solve the issue.
>
> [1] commit 38b7e7f8ae82 ("ixgbe: Do not allow LRO or MTU change with XDP")
> [2] commit fabf1bce103a ("ixgbe: Prevent unsupported configurations with
> XDP")
>
> Signed-off-by: Jason Xing <kernelxing@tencent.com>
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> index ab8370c413f3..dc016582f91e 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> @@ -4313,6 +4313,9 @@ static void ixgbe_set_rx_buffer_len(struct ixgbe_adapter *adapter)
> if (IXGBE_2K_TOO_SMALL_WITH_PADDING ||
> (max_frame > (ETH_FRAME_LEN + ETH_FCS_LEN)))
> set_bit(__IXGBE_RX_3K_BUFFER, &rx_ring->state);
> +
> + if (ixgbe_enabled_xdp_adapter(adapter))
> + set_bit(__IXGBE_RX_3K_BUFFER, &rx_ring->state);
This will result with unnecessary overhead for 1500 MTU because you will
be working on order-1 pages. Instead I would focus on fixing
ixgbe_change_mtu() and stop relying on ixgbe_rx_bufsz() in there. You can
check what we do on ice/i40e sides.
I'm not looking actively into ixgbe internals but I don't think that there
is anything that stops us from using 3k buffers with XDP.
> #endif
> }
> }
> --
> 2.37.3
>
WARNING: multiple messages have this Message-ID (diff)
From: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
To: Jason Xing <kerneljasonxing@gmail.com>
Cc: john.fastabend@gmail.co, hawk@kernel.org, daniel@iogearbox.net,
tirthendu.sarkar@intel.com, intel-wired-lan@lists.osuosl.org,
richardcochran@gmail.com, jesse.brandeburg@intel.com,
ast@kernel.org, edumazet@google.com, anthony.l.nguyen@intel.com,
magnus.karlsson@intel.com, netdev@vger.kernel.org,
kuba@kernel.org, bpf@vger.kernel.org, pabeni@redhat.com,
davem@davemloft.net, linux-kernel@vger.kernel.org,
Jason Xing <kernelxing@tencent.com>
Subject: Re: [Intel-wired-lan] [PATCH net] ixgbe: allow to increase MTU to some extent with XDP enalbed
Date: Thu, 26 Jan 2023 13:17:20 +0100 [thread overview]
Message-ID: <Y9JvUKBgBifiosOa@boxer> (raw)
In-Reply-To: <20230121085521.9566-1-kerneljasonxing@gmail.com>
On Sat, Jan 21, 2023 at 04:55:21PM +0800, Jason Xing wrote:
> From: Jason Xing <kernelxing@tencent.com>
>
> I encountered one case where I cannot increase the MTU size with XDP
> enabled if the server is equipped with IXGBE card, which happened on
> thousands of servers. I noticed it was prohibited from 2017[1] and
> added size checks[2] if allowed soon after the previous patch.
>
> Interesting part goes like this:
> 1) Changing MTU directly from 1500 (default value) to 2000 doesn't
> work because the driver finds out that 'new_frame_size >
> ixgbe_rx_bufsz(ring)' in ixgbe_change_mtu() function.
> 2) However, if we change MTU to 1501 then change from 1501 to 2000, it
> does work, because the driver sets __IXGBE_RX_3K_BUFFER when MTU size
> is converted to 1501, which later size check policy allows.
>
> The default MTU value for most servers is 1500 which cannot be adjusted
> directly to the value larger than IXGBE_MAX_2K_FRAME_BUILD_SKB (1534 or
> 1536) if it loads XDP.
>
> After I do a quick study on the manner of i40E driver allowing two kinds
> of buffer size (one is 2048 while another is 3072) to support XDP mode in
> i40e_max_xdp_frame_size(), I believe the default MTU size is possibly not
> satisfied in XDP mode when IXGBE driver is in use, we sometimes need to
> insert a new header, say, vxlan header. So setting the 3K-buffer flag
> could solve the issue.
>
> [1] commit 38b7e7f8ae82 ("ixgbe: Do not allow LRO or MTU change with XDP")
> [2] commit fabf1bce103a ("ixgbe: Prevent unsupported configurations with
> XDP")
>
> Signed-off-by: Jason Xing <kernelxing@tencent.com>
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> index ab8370c413f3..dc016582f91e 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> @@ -4313,6 +4313,9 @@ static void ixgbe_set_rx_buffer_len(struct ixgbe_adapter *adapter)
> if (IXGBE_2K_TOO_SMALL_WITH_PADDING ||
> (max_frame > (ETH_FRAME_LEN + ETH_FCS_LEN)))
> set_bit(__IXGBE_RX_3K_BUFFER, &rx_ring->state);
> +
> + if (ixgbe_enabled_xdp_adapter(adapter))
> + set_bit(__IXGBE_RX_3K_BUFFER, &rx_ring->state);
This will result with unnecessary overhead for 1500 MTU because you will
be working on order-1 pages. Instead I would focus on fixing
ixgbe_change_mtu() and stop relying on ixgbe_rx_bufsz() in there. You can
check what we do on ice/i40e sides.
I'm not looking actively into ixgbe internals but I don't think that there
is anything that stops us from using 3k buffers with XDP.
> #endif
> }
> }
> --
> 2.37.3
>
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
next prev parent reply other threads:[~2023-01-26 12:17 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-21 8:55 [PATCH net] ixgbe: allow to increase MTU to some extent with XDP enalbed Jason Xing
2023-01-21 8:55 ` [Intel-wired-lan] " Jason Xing
2023-01-22 20:21 ` Paul Menzel
2023-01-22 20:21 ` Paul Menzel
2023-01-23 1:53 ` Jason Xing
2023-01-23 1:53 ` Jason Xing
2023-01-25 7:35 ` Jason Xing
2023-01-25 7:35 ` [Intel-wired-lan] " Jason Xing
2023-01-26 12:17 ` Maciej Fijalkowski [this message]
2023-01-26 12:17 ` Maciej Fijalkowski
2023-01-26 15:56 ` Alexander Lobakin
2023-01-26 15:56 ` [Intel-wired-lan] " Alexander Lobakin
2023-01-27 4:16 ` Jason Xing
2023-01-27 4:16 ` [Intel-wired-lan] " Jason Xing
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=Y9JvUKBgBifiosOa@boxer \
--to=maciej.fijalkowski@intel.com \
--cc=alexandr.lobakin@intel.com \
--cc=anthony.l.nguyen@intel.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hawk@kernel.org \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jesse.brandeburg@intel.com \
--cc=john.fastabend@gmail.co \
--cc=kerneljasonxing@gmail.com \
--cc=kernelxing@tencent.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=magnus.karlsson@intel.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=richardcochran@gmail.com \
--cc=tirthendu.sarkar@intel.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.