From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 218654617E for ; Mon, 3 Feb 2025 08:17:16 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 16D8540287; Mon, 3 Feb 2025 08:17:15 +0100 (CET) Received: from mail-wm1-f99.google.com (mail-wm1-f99.google.com [209.85.128.99]) by mails.dpdk.org (Postfix) with ESMTP id 44CF640264 for ; Mon, 3 Feb 2025 08:17:13 +0100 (CET) Received: by mail-wm1-f99.google.com with SMTP id 5b1f17b1804b1-43621d27adeso26745825e9.2 for ; Sun, 02 Feb 2025 23:17:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738567033; x=1739171833; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=DEFtia7OrTe5RTW3pgV2tJlRkAlgcOtlf9yyhGIsfAM=; b=N8B1/v53lV7IaEjpalpwT+Uz3k2cmRYBQjvGC8/etQ0vA7bxhotM4YHzLm5HSTwO4g ZC9xg65QJ1gc5dfItWTJo2QhRV8nFo9ltyKjxTb+4qTzWaG/hPGp9vb6OslB1DWPMaKi gjQRMFmCaOqQlYvAozhQaA+h40N9ndf8xMtuNTb0sNIb8AJZMJl5i6PCQ6TB3EfUHBe7 961r1jySjQJcWEkwfMCRsxH5ADdWnIKi7fSLdegTXMgQN0IH9UrGYdioBAq4rX90sfDB R6G0RrsOYIHv7vQyQ+RkksqwsjNNjJIIcRx/TV3O0guCjqwsRrgPQUIMR2pmzBoCR+Kt rrRA== X-Gm-Message-State: AOJu0YxgxdP4hVtOLw2NiLOnD/T8XstEnTpDkiasruzj85efF+q6GwRn 1j05bXbC67PwOjZYBKetQOXC+1gHg6jJii4db9ULhkCEYAK9htbLa0TUtaVbQxLz2uGIji614Cj kraHPcH8X7ZeDnenJ6be40Z2ni55NP6s//Zked8KI X-Gm-Gg: ASbGncvStFlRoSMAO/82aFEJ1WrkaegfRqWT0nIEf0O3r3+hVC3JhBkJ/m/WVX9uQJj LRj1T0Du7SG0631xbwcWORcK+xwB8BcsKgdErbBExmoRFFC8GVhiARTwJ9QEugJM9w+YvTyaZWm U3M2AUnGuj7QAxd5K7sphwXSfXMcOBQ9CJm9/F6QVdiLJXyCvpuIU4xTO3xkMtp6x40wKbRm3B3 EhI5ATl5gWsbkxFiMUvqZCfE9TrYrXodtSScr9mJ/T6/UR41rQLI2NffkIH8C+3o1Wv9ZweRFMu l7VR/erVtOZKgqOL X-Google-Smtp-Source: AGHT+IFwmghNvtIITuItNgOX7E3gHtRNwno1b6honCmk3hxzI7rx2psdcBpL9yj15fDgtC2sOAys1U/33qJb X-Received: by 2002:a05:600c:4fd6:b0:434:f1d5:1453 with SMTP id 5b1f17b1804b1-438dc34cc47mr198907775e9.0.1738567032577; Sun, 02 Feb 2025 23:17:12 -0800 (PST) Received: from claroty.com (relay.goskope.com. [31.186.239.107]) by smtp-relay.gmail.com with ESMTPS id ffacd0b85a97d-38c5c1e23acsm221974f8f.84.2025.02.02.23.17.11 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 02 Feb 2025 23:17:12 -0800 (PST) X-Relaying-Domain: claroty.com Received: by mail-ot1-f70.google.com with SMTP id 46e09a7af769-71e17fbb9dbso3898839a34.0 for ; Sun, 02 Feb 2025 23:17:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=claroty.com; s=google; t=1738567030; x=1739171830; darn=dpdk.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=DEFtia7OrTe5RTW3pgV2tJlRkAlgcOtlf9yyhGIsfAM=; b=h9R/F3MrhhKI8XusXjcflQLuiGkoXEzK+JQih9iVRs+tUlFaVl09zwcwxvknSuZs1T oKOp/61T/C7QQnRPPkm+U4lEmrHz4sC96vkFJ2svlhC+uTvvtfPQHXgTDXVcuYbDq5uj XsMLTXcfUvMdGvi/z+71HQo2Ox55IZxdLPpFx6ELgg514Igw42QyzkRRAzNKahNrYIGs pJke8ZnMJ48myZXynBMxG+B0duGfQnvj3sxAEVVXurwMPIEDR9aU/m2zja7Ufgjb9SGP gIxs3uvXW+XiKJTugo9hJmQo5JN25SGWqQK2sUecsfoXG0TW2ynF2GA3G2qbv97LRM8X 06aw== X-Received: by 2002:a05:6830:678e:b0:718:ad8a:e2ce with SMTP id 46e09a7af769-726568d20f1mr13070752a34.17.1738567029996; Sun, 02 Feb 2025 23:17:09 -0800 (PST) X-Received: by 2002:a05:6830:678e:b0:718:ad8a:e2ce with SMTP id 46e09a7af769-726568d20f1mr13070748a34.17.1738567029652; Sun, 02 Feb 2025 23:17:09 -0800 (PST) MIME-Version: 1.0 References: <20250202093255.19da8189@hermes.local> In-Reply-To: <20250202093255.19da8189@hermes.local> From: Ofer Dagan Date: Mon, 3 Feb 2025 09:16:58 +0200 X-Gm-Features: AWEUYZm7omyzQJAqiOP6f6VC28z_uNLd1RnMo8FLDPARO9k_Adp05ArqnzrRIc8 Message-ID: Subject: Re: [EXTERNAL] Re: Support jumbo packets with XDP To: stephen@networkplumber.org Cc: users@dpdk.org Content-Type: multipart/alternative; boundary="00000000000038a27b062d37ae1a" x-netskope-inspected: true X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org --00000000000038a27b062d37ae1a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Stephan, Thanks for your response. I'm building DPDK 24.11 on kernel version 5.15.0-130-generic. It does seem to work with the MTU you suggested, but how can I support even larger packets (up to 9000)? Are there any workarounds for such cases? I don't mind a performance penalty as these use cases are expected to support less traffic then the ones using dpdk drivers. On Sun, Feb 2, 2025 at 7:33=E2=80=AFPM Stephen Hemminger wrote: > On Sun, 2 Feb 2025 08: 53: 42 +0200 Ofer Dagan > wrote: > Hi all, > > We are trying to start using AF_XDP instead of libpc= ap > (for use cases where > dpdk drivers aren't a good fit for us). When using > XDP, we > ZjQcmQRYFpfptBannerStart > ------------------------------ > WARNING:External E-Mail - Use caution with links and attachments > > ZjQcmQRYFpfptBannerEnd > > On Sun, 2 Feb 2025 08:53:42 +0200 > Ofer Dagan wrote: > > > Hi all, > > > > We are trying to start using AF_XDP instead of libpcap (for use cases w= here > > dpdk drivers aren't a good fit for us). When using XDP, we can't set hi= gh > > MTU. How to still support jumbo packets in our application? > > > > Thanks, > > Ofer > > What error are you seeing? > What version of DPDK, and what version of kernel are you building for. > > The current version of AF_XDP Poll mode driver supports larger mtu sizes. > It is constrained because the receive buffer has to fit on a single page > and there is overhead for the various headers. > > > dev_info->min_mtu =3D RTE_ETHER_MIN_MTU; > #if defined(XDP_UMEM_UNALIGNED_CHUNK_FLAG) > dev_info->max_rx_pktlen =3D getpagesize() - > sizeof(struct rte_mempool_objhdr) - > sizeof(struct rte_mbuf) - > RTE_PKTMBUF_HEADROOM - XDP_PACKET_HEADROOM; > #else > dev_info->max_rx_pktlen =3D ETH_AF_XDP_FRAME_SIZE - XDP_PACKET_HEADROOM; > #endif > dev_info->max_mtu =3D dev_info->max_rx_pktlen - ETH_AF_XDP_ETH_OVERHEAD; > > If you have a relatively recent kernel the UNALIGNED_CHUNK_FLAG should be= set. > Stepping through the maths for that > max_rx_pktlen =3D 4096 - 24 - 128 - 128 - 256 =3D 3560 > max_mtu =3D max_rx_pktlen - 14 - 4 =3D 3542 > > --00000000000038a27b062d37ae1a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Stephan,

Thanks for your response. I'm building DPDK 24.11 on kernel ve= rsion 5.15.0-130-generic. It does seem to work with the MTU you suggested, but how can I su= pport even larger packets (up to = 9000)?
Are there any=C2=A0workarounds for such cases? I don't mind a perfo= rmance penalty as these use cases are expected to support less traffic then= the ones using dpdk drivers.

On Sun, Feb 2, 2025 at 7= :33=E2=80=AFPM Stephen Hemminger <stephen@networkplumber.org> wrote:
On Sun, 2 Feb 2025 08:=E2=80=8A53:=E2=80=8A42 +0200 Ofer Dagan <ofer.=E2= =80=8Ad@=E2=80=8Aclaroty.=E2=80=8Acom> wrote: > Hi all, > > We = are trying to start using AF_XDP instead of libpcap (for use cases where &g= t; dpdk drivers aren't a good fit for us). When using XDP, we
ZjQcmQRYFpfptBannerStart
=09
WARNING:External E-Mail - Use caution wi= th links and attachments
=C2=A0
ZjQcmQRYFpfptBannerEnd
On Sun, 2 Feb 2025 08:53:42 +0200
Ofer Dagan <ofer=
.d@claroty.com> wrote:

> Hi all,
>=20
> We are trying to start using AF_XDP instead of libpcap (for use cases =
where
> dpdk drivers aren't a good fit for us). When using XDP, we can'=
;t set high
> MTU. How to still support jumbo packets in our application?
>=20
> Thanks,
> Ofer

What error are you seeing?
What version of DPDK, and what version of kernel are you building for.

The current version of AF_XDP Poll mode driver supports larger mtu sizes.
It is constrained because the receive buffer has to fit on a single page
and there is overhead for the various headers.


	dev_info->min_mtu =3D RTE_ETHER_MIN_MTU;
#if defined(XDP_UMEM_UNALIGNED_CHUNK_FLAG)
	dev_info->max_rx_pktlen =3D getpagesize() -
				  sizeof(struct rte_mempool_objhdr) -
				  sizeof(struct rte_mbuf) -
				  RTE_PKTMBUF_HEADROOM - XDP_PACKET_HEADROOM;
#else
	dev_info->max_rx_pktlen =3D ETH_AF_XDP_FRAME_SIZE - XDP_PACKET_HEADROOM=
;
#endif
	dev_info->max_mtu =3D dev_info->max_rx_pktlen - ETH_AF_XDP_ETH_OVERH=
EAD;

If you have a relatively recent kernel the UNALIGNED_CHUNK_FLAG should be s=
et.
Stepping through the maths for that
	max_rx_pktlen =3D 4096 - 24 - 128 - 128 - 256 =3D 3560
	max_mtu =3D max_rx_pktlen - 14 - 4 =3D 3542
--00000000000038a27b062d37ae1a--