DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Loftus, Ciara" <ciara.loftus@intel.com>
To: "Ye, Xiaolong" <xiaolong.ye@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>, "stable@dpdk.org" <stable@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v3 3/3] net/af_xdp: fix maximum MTU value
Date: Thu, 13 Feb 2020 08:43:08 +0000	[thread overview]
Message-ID: <74F120C019F4A64C9B78E802F6AD4CC27932B471@IRSMSX106.ger.corp.intel.com> (raw)
In-Reply-To: <20200213030559.GO80720@intel.com>

> Subject: Re: [dpdk-dev] [PATCH v3 3/3] net/af_xdp: fix maximum MTU value
> 
> On 02/10, Ciara Loftus wrote:
> >The maximum MTU for af_xdp zero copy is equal to the page size less the
> >frame overhead introduced by AF_XDP (XDP HR = 256) and DPDK (frame
> headroom
> >= 320). The patch updates this value to reflect this.
> >
> >This change also makes it possible to remove unneeded constants for both
> >zero-copy and copy mode.
> >
> >Fixes: d8a210774e1d ("net/af_xdp: support unaligned umem chunks")
> >Cc: stable@dpdk.org
> >
> >Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
> >---
> > drivers/net/af_xdp/rte_eth_af_xdp.c | 23 +++++++++++------------
> > 1 file changed, 11 insertions(+), 12 deletions(-)
> >
> >diff --git a/drivers/net/af_xdp/rte_eth_af_xdp.c
> b/drivers/net/af_xdp/rte_eth_af_xdp.c
> >index 1e98cd44f..75f037c3e 100644
> >--- a/drivers/net/af_xdp/rte_eth_af_xdp.c
> >+++ b/drivers/net/af_xdp/rte_eth_af_xdp.c
> >@@ -59,13 +59,6 @@ static int af_xdp_logtype;
> >
> > #define ETH_AF_XDP_FRAME_SIZE		2048
> > #define ETH_AF_XDP_NUM_BUFFERS		4096
> >-#ifdef XDP_UMEM_UNALIGNED_CHUNK_FLAG
> >-#define ETH_AF_XDP_MBUF_OVERHEAD	128 /* sizeof(struct
> rte_mbuf) */
> >-#define ETH_AF_XDP_DATA_HEADROOM \
> >-	(ETH_AF_XDP_MBUF_OVERHEAD + RTE_PKTMBUF_HEADROOM)
> >-#else
> >-#define ETH_AF_XDP_DATA_HEADROOM	0
> >-#endif
> > #define ETH_AF_XDP_DFLT_NUM_DESCS
> 	XSK_RING_CONS__DEFAULT_NUM_DESCS
> > #define ETH_AF_XDP_DFLT_START_QUEUE_IDX	0
> > #define ETH_AF_XDP_DFLT_QUEUE_COUNT	1
> >@@ -602,7 +595,14 @@ eth_dev_info(struct rte_eth_dev *dev, struct
> rte_eth_dev_info *dev_info)
> > 	dev_info->max_tx_queues = internals->queue_cnt;
> >
> > 	dev_info->min_mtu = RTE_ETHER_MIN_MTU;
> >-	dev_info->max_mtu = ETH_AF_XDP_FRAME_SIZE -
> ETH_AF_XDP_DATA_HEADROOM;
> >+#if defined(XDP_UMEM_UNALIGNED_CHUNK_FLAG)
> >+	dev_info->max_mtu = getpagesize() -
> >+				sizeof(struct rte_mempool_objhdr) -
> >+				sizeof(struct rte_mbuf) -
> >+				RTE_PKTMBUF_HEADROOM -
> XDP_PACKET_HEADROOM;
> >+#else
> >+	dev_info->max_mtu = ETH_AF_XDP_FRAME_SIZE;
> 
> Do we need to subtract XDP_PACKET_HEADROOM for copy mode as well?

Good catch. I'll add this and spin a v4.
Thanks for the reviews.

Ciara

> 
> Thanks,
> Xiaolong
> 
> >+#endif
> >
> > 	dev_info->default_rxportconf.nb_queues = 1;
> > 	dev_info->default_txportconf.nb_queues = 1;
> >@@ -804,7 +804,7 @@ xsk_umem_info *xdp_umem_configure(struct
> pmd_internals *internals,
> > 		.fill_size = ETH_AF_XDP_DFLT_NUM_DESCS,
> > 		.comp_size = ETH_AF_XDP_DFLT_NUM_DESCS,
> > 		.frame_size = ETH_AF_XDP_FRAME_SIZE,
> >-		.frame_headroom = ETH_AF_XDP_DATA_HEADROOM };
> >+		.frame_headroom = 0 };
> > 	char ring_name[RTE_RING_NAMESIZE];
> > 	char mz_name[RTE_MEMZONE_NAMESIZE];
> > 	int ret;
> >@@ -829,8 +829,7 @@ xsk_umem_info *xdp_umem_configure(struct
> pmd_internals *internals,
> >
> > 	for (i = 0; i < ETH_AF_XDP_NUM_BUFFERS; i++)
> > 		rte_ring_enqueue(umem->buf_ring,
> >-				 (void *)(i * ETH_AF_XDP_FRAME_SIZE +
> >-					  ETH_AF_XDP_DATA_HEADROOM));
> >+				 (void *)(i * ETH_AF_XDP_FRAME_SIZE));
> >
> > 	snprintf(mz_name, sizeof(mz_name), "af_xdp_umem_%s_%u",
> > 		       internals->if_name, rxq->xsk_queue_idx);
> >@@ -939,7 +938,7 @@ eth_rx_queue_setup(struct rte_eth_dev *dev,
> > 	/* Now get the space available for data in the mbuf */
> > 	buf_size = rte_pktmbuf_data_room_size(mb_pool) -
> > 		RTE_PKTMBUF_HEADROOM;
> >-	data_size = ETH_AF_XDP_FRAME_SIZE -
> ETH_AF_XDP_DATA_HEADROOM;
> >+	data_size = ETH_AF_XDP_FRAME_SIZE;
> >
> > 	if (data_size > buf_size) {
> > 		AF_XDP_LOG(ERR, "%s: %d bytes will not fit in mbuf (%d
> bytes)\n",
> >--
> >2.17.1
> >

      reply	other threads:[~2020-02-13  8:43 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-10 11:40 [dpdk-dev] [PATCH v3 0/3] AF_XDP PMD Fixes Ciara Loftus
2020-02-10 11:40 ` [dpdk-dev] [PATCH v3 1/3] net/af_xdp: fix umem frame size & headroom calculations Ciara Loftus
2020-02-13  2:45   ` Ye Xiaolong
2020-02-10 11:40 ` [dpdk-dev] [PATCH v3 2/3] net/af_xdp: use correct fill queue addresses Ciara Loftus
2020-02-13  3:09   ` Ye Xiaolong
2020-02-10 11:40 ` [dpdk-dev] [PATCH v3 3/3] net/af_xdp: fix maximum MTU value Ciara Loftus
2020-02-13  3:05   ` Ye Xiaolong
2020-02-13  8:43     ` Loftus, Ciara [this message]

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=74F120C019F4A64C9B78E802F6AD4CC27932B471@IRSMSX106.ger.corp.intel.com \
    --to=ciara.loftus@intel.com \
    --cc=dev@dpdk.org \
    --cc=stable@dpdk.org \
    --cc=xiaolong.ye@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).