All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 1/1] net: fec: add initial XDP support
@ 2022-10-25 20:11 Shenwei Wang
  2022-10-25 22:08 ` Andrew Lunn
  2022-10-26  7:45 ` kernel test robot
  0 siblings, 2 replies; 25+ messages in thread
From: Shenwei Wang @ 2022-10-25 20:11 UTC (permalink / raw)
  To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni
  Cc: Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
	John Fastabend, netdev, linux-kernel, imx, Shenwei Wang

This patch adds the initial XDP support to Freescale driver. It supports
XDP_PASS, XDP_DROP and XDP_REDIRECT actions. Upcoming patches will add
support for XDP_TX and Zero Copy features.

As the patch is rather large, the part of codes to collect the
statistics is separated and will prepare a dedicated patch for that
part.

The driver has a macro RX_RING_SIZE to configure the RX ring size. After
testing with the RX ring size, it turned out the small the rign size the
better the better performance for XDP mode. So the different ring size is
selected for XDP mode and normal mode in this patch.

I just tested with the application of xdpsock.
  -- Native here means running command of "xdpsock -i eth0"
  -- SKB-Mode means running command of "xdpsock -S -i eth0"

RX Ring Size       16       32        64       128
      Native      230K     227K      196K      160K
    SKB-Mode      207K     208K      203K      204K

Normal mode performance by iperf.

RX Ring Size         16         64       128
iperf              300Mbps    830Mbps   933Mbps

The following are the testing result relating to XDP mode:

 # ./xdpsock -i eth0
 sock0@eth0:0 rxdrop xdp-drv
                   pps            pkts           1.00
 rx                 231166         905984
 tx                 0              0

 # xdpsock -S -i eth0         // skb-mode
 sock0@eth0:0 rxdrop xdp-skb
                    pps            pkts           1.00
 rx                 205638         917288
 tx                 0              0

 # xdp2 eth0
 proto 0:     571382 pkt/s
 proto 0:     579849 pkt/s
 proto 0:     582110 pkt/s

 # xdp2 -S eth0    // skb-mode
 proto 17:      71999 pkt/s
 proto 17:      72000 pkt/s
 proto 17:      71988 pkt/s

Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com>
---
 drivers/net/ethernet/freescale/fec.h      |   4 +
 drivers/net/ethernet/freescale/fec_main.c | 241 +++++++++++++++++++++-
 2 files changed, 244 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/freescale/fec.h b/drivers/net/ethernet/freescale/fec.h
index 476e3863a310..07e85fc3d7ba 100644
--- a/drivers/net/ethernet/freescale/fec.h
+++ b/drivers/net/ethernet/freescale/fec.h
@@ -348,6 +348,7 @@ struct bufdesc_ex {
  */
 
 #define FEC_ENET_XDP_HEADROOM	(XDP_PACKET_HEADROOM)
+#define XDP_RX_RING_SIZE	16
 
 #define FEC_ENET_RX_PAGES	256
 #define FEC_ENET_RX_FRSIZE	(PAGE_SIZE - FEC_ENET_XDP_HEADROOM \
@@ -663,6 +664,9 @@ struct fec_enet_private {
 
 	struct imx_sc_ipc *ipc_handle;
 
+	/* XDP BPF Program */
+	struct bpf_prog *xdp_prog;
+
 	u64 ethtool_stats[];
 };
 
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 6986b74fb8af..2e4be4590f77 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -89,6 +89,11 @@ static const u16 fec_enet_vlan_pri_to_queue[8] = {0, 0, 1, 1, 1, 2, 2, 2};
 #define FEC_ENET_OPD_V	0xFFF0
 #define FEC_MDIO_PM_TIMEOUT  100 /* ms */
 
+#define FEC_ENET_XDP_PASS          0
+#define FEC_ENET_XDP_CONSUMED      BIT(0)
+#define FEC_ENET_XDP_TX            BIT(1)
+#define FEC_ENET_XDP_REDIR         BIT(2)
+
 struct fec_devinfo {
 	u32 quirks;
 };
@@ -418,13 +423,14 @@ static int
 fec_enet_create_page_pool(struct fec_enet_private *fep,
 			  struct fec_enet_priv_rx_q *rxq, int size)
 {
+	struct bpf_prog *xdp_prog = READ_ONCE(fep->xdp_prog);
 	struct page_pool_params pp_params = {
 		.order = 0,
 		.flags = PP_FLAG_DMA_MAP | PP_FLAG_DMA_SYNC_DEV,
 		.pool_size = size,
 		.nid = dev_to_node(&fep->pdev->dev),
 		.dev = &fep->pdev->dev,
-		.dma_dir = DMA_FROM_DEVICE,
+		.dma_dir = xdp_prog ? DMA_BIDIRECTIONAL : DMA_FROM_DEVICE,
 		.offset = FEC_ENET_XDP_HEADROOM,
 		.max_len = FEC_ENET_RX_FRSIZE,
 	};
@@ -1499,6 +1505,59 @@ static void fec_enet_update_cbd(struct fec_enet_priv_rx_q *rxq,
 	bdp->cbd_bufaddr = cpu_to_fec32(phys_addr);
 }
 
+static u32
+fec_enet_run_xdp(struct fec_enet_private *fep, struct bpf_prog *prog,
+		 struct xdp_buff *xdp, struct fec_enet_priv_rx_q *rxq, int index)
+{
+	unsigned int sync, len = xdp->data_end - xdp->data;
+	u32 ret = FEC_ENET_XDP_PASS;
+	struct page *page;
+	int err;
+	u32 act;
+
+	act = bpf_prog_run_xdp(prog, xdp);
+
+	/* Due xdp_adjust_tail: DMA sync for_device cover max len CPU touch */
+	sync = xdp->data_end - xdp->data_hard_start - FEC_ENET_XDP_HEADROOM;
+	sync = max(sync, len);
+
+	switch (act) {
+	case XDP_PASS:
+		ret = FEC_ENET_XDP_PASS;
+		break;
+
+	case XDP_REDIRECT:
+		err = xdp_do_redirect(fep->netdev, xdp, prog);
+		if (!err) {
+			ret = FEC_ENET_XDP_REDIR;
+		} else {
+			ret = FEC_ENET_XDP_CONSUMED;
+			page = virt_to_head_page(xdp->data);
+			page_pool_put_page(rxq->page_pool, page, sync, true);
+		}
+		break;
+
+	default:
+		bpf_warn_invalid_xdp_action(fep->netdev, prog, act);
+		fallthrough;
+
+	case XDP_TX:
+		bpf_warn_invalid_xdp_action(fep->netdev, prog, act);
+		fallthrough;
+
+	case XDP_ABORTED:
+		fallthrough;    /* handle aborts by dropping packet */
+
+	case XDP_DROP:
+		ret = FEC_ENET_XDP_CONSUMED;
+		page = virt_to_head_page(xdp->data);
+		page_pool_put_page(rxq->page_pool, page, sync, true);
+		break;
+	}
+
+	return ret;
+}
+
 /* During a receive, the bd_rx.cur points to the current incoming buffer.
  * When we update through the ring, if the next incoming buffer has
  * not been given to the system, we just set the empty indicator,
@@ -1520,6 +1579,9 @@ fec_enet_rx_queue(struct net_device *ndev, int budget, u16 queue_id)
 	u16	vlan_tag;
 	int	index = 0;
 	bool	need_swap = fep->quirks & FEC_QUIRK_SWAP_FRAME;
+	struct bpf_prog *xdp_prog = READ_ONCE(fep->xdp_prog);
+	u32 ret, xdp_result = FEC_ENET_XDP_PASS;
+	struct xdp_buff xdp;
 	struct page *page;
 
 #ifdef CONFIG_M532x
@@ -1531,6 +1593,7 @@ fec_enet_rx_queue(struct net_device *ndev, int budget, u16 queue_id)
 	 * These get messed up if we get called due to a busy condition.
 	 */
 	bdp = rxq->bd.cur;
+	xdp_init_buff(&xdp, PAGE_SIZE, &rxq->xdp_rxq);
 
 	while (!((status = fec16_to_cpu(bdp->cbd_sc)) & BD_ENET_RX_EMPTY)) {
 
@@ -1580,6 +1643,17 @@ fec_enet_rx_queue(struct net_device *ndev, int budget, u16 queue_id)
 		prefetch(page_address(page));
 		fec_enet_update_cbd(rxq, bdp, index);
 
+		if (xdp_prog) {
+			xdp_buff_clear_frags_flag(&xdp);
+			xdp_prepare_buff(&xdp, page_address(page),
+					 FEC_ENET_XDP_HEADROOM, pkt_len, false);
+
+			ret = fec_enet_run_xdp(fep, xdp_prog, &xdp, rxq, index);
+			xdp_result |= ret;
+			if (ret != FEC_ENET_XDP_PASS)
+				goto rx_processing_done;
+		}
+
 		/* The packet length includes FCS, but we don't want to
 		 * include that when passing upstream as it messes up
 		 * bridging applications.
@@ -1675,6 +1749,10 @@ fec_enet_rx_queue(struct net_device *ndev, int budget, u16 queue_id)
 		writel(0, rxq->bd.reg_desc_active);
 	}
 	rxq->bd.cur = bdp;
+
+	if (xdp_result & FEC_ENET_XDP_REDIR)
+		xdp_do_flush_map();
+
 	return pkt_received;
 }
 
@@ -3476,6 +3554,165 @@ static u16 fec_enet_select_queue(struct net_device *ndev, struct sk_buff *skb,
 	return fec_enet_vlan_pri_to_queue[vlan_tag >> 13];
 }
 
+static int fec_enet_bpf(struct net_device *dev, struct netdev_bpf *bpf)
+{
+	struct fec_enet_private *fep = netdev_priv(dev);
+	bool is_run = netif_running(dev);
+	struct bpf_prog *old_prog;
+	unsigned int dsize;
+	int i;
+
+	switch (bpf->command) {
+	case XDP_SETUP_PROG:
+		if (is_run)
+			fec_enet_close(dev);
+
+		old_prog = xchg(&fep->xdp_prog, bpf->prog);
+
+		/* Update RX ring size */
+		dsize = fep->bufdesc_ex ? sizeof(struct bufdesc_ex) :
+			sizeof(struct bufdesc);
+		for (i = 0; i < fep->num_rx_queues; i++) {
+			struct fec_enet_priv_rx_q *rxq = fep->rx_queue[i];
+			struct bufdesc *cbd_base;
+			unsigned int size;
+
+			cbd_base = rxq->bd.base;
+			if (bpf->prog)
+				rxq->bd.ring_size = XDP_RX_RING_SIZE;
+			else
+				rxq->bd.ring_size = RX_RING_SIZE;
+			size = dsize * rxq->bd.ring_size;
+			cbd_base = (struct bufdesc *)(((void *)cbd_base) + size);
+			rxq->bd.last = (struct bufdesc *)(((void *)cbd_base) - dsize);
+		}
+
+		if (is_run)
+			fec_enet_open(dev);
+
+		if (old_prog)
+			bpf_prog_put(old_prog);
+
+		return 0;
+
+	case XDP_SETUP_XSK_POOL:
+		return -EOPNOTSUPP;
+
+	default:
+		return -EOPNOTSUPP;
+	}
+}
+
+static int
+fec_enet_xdp_get_tx_queue(struct fec_enet_private *fep, int cpu)
+{
+	int index = cpu;
+
+	if (unlikely(index < 0))
+		index = 0;
+
+	while (index >= fep->num_tx_queues)
+		index -= fep->num_tx_queues;
+
+	return index;
+}
+
+static int fec_enet_txq_xmit_frame(struct fec_enet_private *fep,
+				   struct fec_enet_priv_tx_q *txq,
+				   struct xdp_frame *frame)
+{
+	unsigned int index, status, estatus;
+	struct bufdesc *bdp, *last_bdp;
+	dma_addr_t dma_addr;
+	int entries_free;
+
+	entries_free = fec_enet_get_free_txdesc_num(txq);
+	if (entries_free < MAX_SKB_FRAGS + 1) {
+		netdev_err(fep->netdev, "NOT enough BD for SG!\n");
+		return NETDEV_TX_OK;
+	}
+
+	/* Fill in a Tx ring entry */
+	bdp = txq->bd.cur;
+	last_bdp = bdp;
+	status = fec16_to_cpu(bdp->cbd_sc);
+	status &= ~BD_ENET_TX_STATS;
+
+	index = fec_enet_get_bd_index(bdp, &txq->bd);
+
+	dma_addr = dma_map_single(&fep->pdev->dev, frame->data,
+				  frame->len, DMA_TO_DEVICE);
+	if (dma_mapping_error(&fep->pdev->dev, dma_addr))
+		return FEC_ENET_XDP_CONSUMED;
+
+	status |= (BD_ENET_TX_INTR | BD_ENET_TX_LAST);
+	if (fep->bufdesc_ex)
+		estatus = BD_ENET_TX_INT;
+
+	bdp->cbd_bufaddr = cpu_to_fec32(dma_addr);
+	bdp->cbd_datlen = cpu_to_fec16(frame->len);
+
+	if (fep->bufdesc_ex) {
+		struct bufdesc_ex *ebdp = (struct bufdesc_ex *)bdp;
+
+		if (fep->quirks & FEC_QUIRK_HAS_AVB)
+			estatus |= FEC_TX_BD_FTYPE(txq->bd.qid);
+
+		ebdp->cbd_bdu = 0;
+		ebdp->cbd_esc = cpu_to_fec32(estatus);
+	}
+
+	index = fec_enet_get_bd_index(last_bdp, &txq->bd);
+	txq->tx_skbuff[index] = NULL;
+
+	/* Send it on its way.  Tell FEC it's ready, interrupt when done,
+	 * it's the last BD of the frame, and to put the CRC on the end.
+	 */
+	status |= (BD_ENET_TX_READY | BD_ENET_TX_TC);
+	bdp->cbd_sc = cpu_to_fec16(status);
+
+	/* If this was the last BD in the ring, start at the beginning again. */
+	bdp = fec_enet_get_nextdesc(last_bdp, &txq->bd);
+
+	txq->bd.cur = bdp;
+
+	return 0;
+}
+
+static int fec_enet_xdp_xmit(struct net_device *dev,
+			     int num_frames,
+			     struct xdp_frame **frames,
+			     u32 flags)
+{
+	struct fec_enet_private *fep = netdev_priv(dev);
+	struct fec_enet_priv_tx_q *txq;
+	int cpu = smp_processor_id();
+	struct netdev_queue *nq;
+	unsigned int queue;
+	int i, nxmit = 0;
+
+	queue = fec_enet_xdp_get_tx_queue(fep, cpu);
+	txq = fep->tx_queue[queue];
+	nq = netdev_get_tx_queue(fep->netdev, queue);
+
+	__netif_tx_lock(nq, cpu);
+
+	for (i = 0; i < num_frames; i++) {
+		fec_enet_txq_xmit_frame(fep, txq, frames[i]);
+		nxmit++;
+	}
+
+	/* Make sure the update to bdp and tx_skbuff are performed. */
+	wmb();
+
+	/* Trigger transmission start */
+	writel(0, txq->bd.reg_desc_active);
+
+	__netif_tx_unlock(nq);
+
+	return num_frames;
+}
+
 static const struct net_device_ops fec_netdev_ops = {
 	.ndo_open		= fec_enet_open,
 	.ndo_stop		= fec_enet_close,
@@ -3490,6 +3727,8 @@ static const struct net_device_ops fec_netdev_ops = {
 	.ndo_poll_controller	= fec_poll_controller,
 #endif
 	.ndo_set_features	= fec_set_features,
+	.ndo_bpf		= fec_enet_bpf,
+	.ndo_xdp_xmit		= fec_enet_xdp_xmit,
 };
 
 static const unsigned short offset_des_active_rxq[] = {
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 25+ messages in thread

* Re: [PATCH 1/1] net: fec: add initial XDP support
  2022-10-25 20:11 [PATCH 1/1] net: fec: add initial XDP support Shenwei Wang
@ 2022-10-25 22:08 ` Andrew Lunn
  2022-10-27  1:50   ` [EXT] " Shenwei Wang
  2022-10-26  7:45 ` kernel test robot
  1 sibling, 1 reply; 25+ messages in thread
From: Andrew Lunn @ 2022-10-25 22:08 UTC (permalink / raw)
  To: Shenwei Wang
  Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
	Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
	John Fastabend, netdev, linux-kernel, imx

> +#define FEC_ENET_XDP_PASS          0
> +#define FEC_ENET_XDP_CONSUMED      BIT(0)
> +#define FEC_ENET_XDP_TX            BIT(1)
> +#define FEC_ENET_XDP_REDIR         BIT(2)

I don't know XDP, so maybe a silly question. Are these action mutually
exclusive? Are these really bits, or should it be an enum?
fec_enet_run_xdp() does not combine them as bits.

> +static int fec_enet_bpf(struct net_device *dev, struct netdev_bpf *bpf)
> +{
> +	struct fec_enet_private *fep = netdev_priv(dev);
> +	bool is_run = netif_running(dev);

You have the space, so maybe call it is_running.

> +	struct bpf_prog *old_prog;
> +	unsigned int dsize;
> +	int i;
> +
> +	switch (bpf->command) {
> +	case XDP_SETUP_PROG:
> +		if (is_run)
> +			fec_enet_close(dev);

fec_net_close() followed by fec_enet_open() is pretty expensive.  The
PHY is stopped and disconnected, and then connected and started. That
will probably trigger an auto-neg, which takes around 1.5 seconds
before the link is up again.

Maybe you should optimise this. I guess the real issue here is you
need to resize the RX ring. You need to be careful with that
anyway. If the machine is under memory pressure, you might not be able
to allocate the ring, resulting in a broken interface. What is
recommended for ethtool --set-ring is that you first allocate the new
ring, and if that is successful, free the old ring. If the allocation
fails, you still have the old ring, and you can safely return -ENOMEM
and still have a working interface.

So i think you can split this patch up into a few parts:

XDP using the default ring size. Your benchmarks show it works, its
just not optimal. But the resulting smaller patch will be easier to
review.

Add support for ethtool set-ring, which will allow you to pick apart
the bits of fec_net_close() and fec_enet_open() which are needed for
changing the rings. This might actually need a refactoring patch?

And then add support for optimal ring size for XDP.

    Andrew

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH 1/1] net: fec: add initial XDP support
  2022-10-25 20:11 [PATCH 1/1] net: fec: add initial XDP support Shenwei Wang
  2022-10-25 22:08 ` Andrew Lunn
@ 2022-10-26  7:45 ` kernel test robot
  1 sibling, 0 replies; 25+ messages in thread
From: kernel test robot @ 2022-10-26  7:45 UTC (permalink / raw)
  To: Shenwei Wang, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni
  Cc: llvm, oe-kbuild-all, netdev, Alexei Starovoitov, Daniel Borkmann,
	Jesper Dangaard Brouer, John Fastabend, linux-kernel, imx,
	Shenwei Wang

[-- Attachment #1: Type: text/plain, Size: 6527 bytes --]

Hi Shenwei,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on net-next/master]
[also build test WARNING on net/master linus/master v6.1-rc2 next-20221026]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Shenwei-Wang/net-fec-add-initial-XDP-support/20221026-041331
patch link:    https://lore.kernel.org/r/20221025201156.776576-1-shenwei.wang%40nxp.com
patch subject: [PATCH 1/1] net: fec: add initial XDP support
config: hexagon-randconfig-r033-20221024 (attached as .config)
compiler: clang version 16.0.0 (https://github.com/llvm/llvm-project 791a7ae1ba3efd6bca96338e10ffde557ba83920)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/intel-lab-lkp/linux/commit/f601d09cdead68e49ba67efbb904277b697c2f66
        git remote add linux-review https://github.com/intel-lab-lkp/linux
        git fetch --no-tags linux-review Shenwei-Wang/net-fec-add-initial-XDP-support/20221026-041331
        git checkout f601d09cdead68e49ba67efbb904277b697c2f66
        # save the config file
        mkdir build_dir && cp config build_dir/.config
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=hexagon SHELL=/bin/bash drivers/net/ethernet/freescale/

If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot <lkp@intel.com>

All warnings (new ones prefixed by >>):

   In file included from drivers/net/ethernet/freescale/fec_main.c:33:
   In file included from include/linux/interrupt.h:11:
   In file included from include/linux/hardirq.h:11:
   In file included from ./arch/hexagon/include/generated/asm/hardirq.h:1:
   In file included from include/asm-generic/hardirq.h:17:
   In file included from include/linux/irq.h:20:
   In file included from include/linux/io.h:13:
   In file included from arch/hexagon/include/asm/io.h:334:
   include/asm-generic/io.h:547:31: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
           val = __raw_readb(PCI_IOBASE + addr);
                             ~~~~~~~~~~ ^
   include/asm-generic/io.h:560:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
           val = __le16_to_cpu((__le16 __force)__raw_readw(PCI_IOBASE + addr));
                                                           ~~~~~~~~~~ ^
   include/uapi/linux/byteorder/little_endian.h:37:51: note: expanded from macro '__le16_to_cpu'
   #define __le16_to_cpu(x) ((__force __u16)(__le16)(x))
                                                     ^
   In file included from drivers/net/ethernet/freescale/fec_main.c:33:
   In file included from include/linux/interrupt.h:11:
   In file included from include/linux/hardirq.h:11:
   In file included from ./arch/hexagon/include/generated/asm/hardirq.h:1:
   In file included from include/asm-generic/hardirq.h:17:
   In file included from include/linux/irq.h:20:
   In file included from include/linux/io.h:13:
   In file included from arch/hexagon/include/asm/io.h:334:
   include/asm-generic/io.h:573:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
           val = __le32_to_cpu((__le32 __force)__raw_readl(PCI_IOBASE + addr));
                                                           ~~~~~~~~~~ ^
   include/uapi/linux/byteorder/little_endian.h:35:51: note: expanded from macro '__le32_to_cpu'
   #define __le32_to_cpu(x) ((__force __u32)(__le32)(x))
                                                     ^
   In file included from drivers/net/ethernet/freescale/fec_main.c:33:
   In file included from include/linux/interrupt.h:11:
   In file included from include/linux/hardirq.h:11:
   In file included from ./arch/hexagon/include/generated/asm/hardirq.h:1:
   In file included from include/asm-generic/hardirq.h:17:
   In file included from include/linux/irq.h:20:
   In file included from include/linux/io.h:13:
   In file included from arch/hexagon/include/asm/io.h:334:
   include/asm-generic/io.h:584:33: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
           __raw_writeb(value, PCI_IOBASE + addr);
                               ~~~~~~~~~~ ^
   include/asm-generic/io.h:594:59: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
           __raw_writew((u16 __force)cpu_to_le16(value), PCI_IOBASE + addr);
                                                         ~~~~~~~~~~ ^
   include/asm-generic/io.h:604:59: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
           __raw_writel((u32 __force)cpu_to_le32(value), PCI_IOBASE + addr);
                                                         ~~~~~~~~~~ ^
>> drivers/net/ethernet/freescale/fec_main.c:3692:9: warning: variable 'nxmit' set but not used [-Wunused-but-set-variable]
           int i, nxmit = 0;
                  ^
   7 warnings generated.


vim +/nxmit +3692 drivers/net/ethernet/freescale/fec_main.c

  3681	
  3682	static int fec_enet_xdp_xmit(struct net_device *dev,
  3683				     int num_frames,
  3684				     struct xdp_frame **frames,
  3685				     u32 flags)
  3686	{
  3687		struct fec_enet_private *fep = netdev_priv(dev);
  3688		struct fec_enet_priv_tx_q *txq;
  3689		int cpu = smp_processor_id();
  3690		struct netdev_queue *nq;
  3691		unsigned int queue;
> 3692		int i, nxmit = 0;
  3693	
  3694		queue = fec_enet_xdp_get_tx_queue(fep, cpu);
  3695		txq = fep->tx_queue[queue];
  3696		nq = netdev_get_tx_queue(fep->netdev, queue);
  3697	
  3698		__netif_tx_lock(nq, cpu);
  3699	
  3700		for (i = 0; i < num_frames; i++) {
  3701			fec_enet_txq_xmit_frame(fep, txq, frames[i]);
  3702			nxmit++;
  3703		}
  3704	
  3705		/* Make sure the update to bdp and tx_skbuff are performed. */
  3706		wmb();
  3707	
  3708		/* Trigger transmission start */
  3709		writel(0, txq->bd.reg_desc_active);
  3710	
  3711		__netif_tx_unlock(nq);
  3712	
  3713		return num_frames;
  3714	}
  3715	

-- 
0-DAY CI Kernel Test Service
https://01.org/lkp

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 40247 bytes --]

^ permalink raw reply	[flat|nested] 25+ messages in thread

* RE: [EXT] Re: [PATCH 1/1] net: fec: add initial XDP support
  2022-10-25 22:08 ` Andrew Lunn
@ 2022-10-27  1:50   ` Shenwei Wang
  0 siblings, 0 replies; 25+ messages in thread
From: Shenwei Wang @ 2022-10-27  1:50 UTC (permalink / raw)
  To: Andrew Lunn
  Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
	Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
	John Fastabend, netdev, linux-kernel, imx



> -----Original Message-----
> From: Andrew Lunn <andrew@lunn.ch>
> Sent: Tuesday, October 25, 2022 5:09 PM
> To: Shenwei Wang <shenwei.wang@nxp.com>
> Cc: David S. Miller <davem@davemloft.net>; Eric Dumazet
> <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni
> <pabeni@redhat.com>; Alexei Starovoitov <ast@kernel.org>; Daniel Borkmann
> <daniel@iogearbox.net>; Jesper Dangaard Brouer <hawk@kernel.org>; John
> Fastabend <john.fastabend@gmail.com>; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; imx@lists.linux.dev
> Subject: [EXT] Re: [PATCH 1/1] net: fec: add initial XDP support
> 
> Caution: EXT Email
> 
> > +#define FEC_ENET_XDP_PASS          0
> > +#define FEC_ENET_XDP_CONSUMED      BIT(0)
> > +#define FEC_ENET_XDP_TX            BIT(1)
> > +#define FEC_ENET_XDP_REDIR         BIT(2)
> 
> I don't know XDP, so maybe a silly question. Are these action mutually exclusive?
> Are these really bits, or should it be an enum?
> fec_enet_run_xdp() does not combine them as bits.
> 
The bit here is to record the states that may required after completing the XDP processing.
As the current implementation for XDP is not full, the other bit like FEC_ENET_XDP_TX is not 
used for now. Generally it will require an extra action if a FEC_ENET_XDP_TX is returned. 
Because we are processing a batch of packets together, those bits may get combined. It will 
then responds to each bit accordingly.

> > +static int fec_enet_bpf(struct net_device *dev, struct netdev_bpf
> > +*bpf) {
> > +     struct fec_enet_private *fep = netdev_priv(dev);
> > +     bool is_run = netif_running(dev);
> 
> You have the space, so maybe call it is_running.
> 
> > +     struct bpf_prog *old_prog;
> > +     unsigned int dsize;
> > +     int i;
> > +
> > +     switch (bpf->command) {
> > +     case XDP_SETUP_PROG:
> > +             if (is_run)
> > +                     fec_enet_close(dev);
> 
> fec_net_close() followed by fec_enet_open() is pretty expensive.  The PHY is
> stopped and disconnected, and then connected and started. That will probably
> trigger an auto-neg, which takes around 1.5 seconds before the link is up again.
> 
> Maybe you should optimise this. I guess the real issue here is you need to resize
> the RX ring. You need to be careful with that anyway. If the machine is under
> memory pressure, you might not be able to allocate the ring, resulting in a
> broken interface. What is recommended for ethtool --set-ring is that you first
> allocate the new ring, and if that is successful, free the old ring. If the allocation
> fails, you still have the old ring, and you can safely return -ENOMEM and still
> have a working interface.
> 
> So i think you can split this patch up into a few parts:
> 
> XDP using the default ring size. Your benchmarks show it works, its just not
> optimal. But the resulting smaller patch will be easier to review.
> 
> Add support for ethtool set-ring, which will allow you to pick apart the bits of
> fec_net_close() and fec_enet_open() which are needed for changing the rings.
> This might actually need a refactoring patch?
> 

That sounds good. Let me think about it.

Thanks,
Shenwei

> And then add support for optimal ring size for XDP.
> 
>     Andrew

^ permalink raw reply	[flat|nested] 25+ messages in thread

* RE: [EXT] Re: [PATCH 1/1] net: fec: add initial XDP support
  2022-10-07  8:08                           ` Ilias Apalodimas
@ 2022-10-07 19:18                             ` Shenwei Wang
  0 siblings, 0 replies; 25+ messages in thread
From: Shenwei Wang @ 2022-10-07 19:18 UTC (permalink / raw)
  To: Ilias Apalodimas, Jesper Dangaard Brouer
  Cc: Andrew Lunn, brouer, David S. Miller, Eric Dumazet,
	Jakub Kicinski, Paolo Abeni, Alexei Starovoitov, Daniel Borkmann,
	Jesper Dangaard Brouer, John Fastabend, netdev, linux-kernel,
	imx, Magnus Karlsson, Björn Töpel

Hi Jesper and Ilias,

The driver has a macro to configure the RX ring size. After testing
with the RX ring size, I found the strange result may has something
to do with this ring size.

I just tested with the application of xdpsock.
  -- Native here means running command of "xdpsock -i eth0"
  -- SKB-Mode means running command of "xdpsock -S -i eth0"

RX Ring Size       16       32        64       128
      Native      230K     227K      196K      160K
    SKB-Mode      207K     208K      203K      204K

It seems the smaller the ring size, the better the performance. This
is also a strange result to me.

The following is the iperf testing result.

RX Ring Size         16         64       128
iperf              300Mbps    830Mbps   933Mbps

Thanks,
Shenwei

> -----Original Message-----
> From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> Sent: Friday, October 7, 2022 3:08 AM
> To: Jesper Dangaard Brouer <jbrouer@redhat.com>
> Cc: Shenwei Wang <shenwei.wang@nxp.com>; Andrew Lunn
> <andrew@lunn.ch>; brouer@redhat.com; David S. Miller
> <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>; Jakub
> Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; Alexei
> Starovoitov <ast@kernel.org>; Daniel Borkmann <daniel@iogearbox.net>;
> Jesper Dangaard Brouer <hawk@kernel.org>; John Fastabend
> <john.fastabend@gmail.com>; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; imx@lists.linux.dev; Magnus Karlsson
> <magnus.karlsson@gmail.com>; Björn Töpel <bjorn@kernel.org>
> Subject: Re: [EXT] Re: [PATCH 1/1] net: fec: add initial XDP support
> 
> Caution: EXT Email
> 
> Hi Jesper,
> 
> On Thu, 6 Oct 2022 at 11:37, Jesper Dangaard Brouer <jbrouer@redhat.com>
> wrote:
> >
> >
> >
> > On 05/10/2022 14.40, Shenwei Wang wrote:
> > > Hi Jesper,
> > >
> > > Here is the summary of "xdp_rxq_info" testing.
> > >
> > >                skb_mark_for_recycle           page_pool_release_page
> > >
> > >               Native        SKB-Mode           Native          SKB-Mode
> > > XDP_DROP     460K           220K              460K             102K
> > > XDP_PASS     80K            113K              60K              62K
> > >
> >
> > It is very pleasing to see the *huge* performance benefit that
> > page_pool provide when recycling pages for SKBs (via skb_mark_for_recycle).
> > I did expect a performance boost, but not around a x2 performance boost.
> 
> Indeed that's a pleasant surprise.  Keep in mind that if we convert more driver
> we can also get rid of copy_break code sprinkled around in drivers.
> 
> Thanks
> /Ilias
> >
> > I guess this platform have a larger overhead for DMA-mapping and
> > page-allocation.
> >
> > IMHO it would be valuable to include this result as part of the patch
> > description when you post the XDP patch again.
> >
> > Only strange result is XDP_PASS 'Native' is slower that 'SKB-mode'. I
> > cannot explain why, as XDP_PASS essentially does nothing and just
> > follow normal driver code to netstack.
> >
> > Thanks a lot for doing these tests.
> > --Jesper
> >
> > > The following are the testing log.
> > >
> > > Thanks,
> > > Shenwei
> > >
> > > ### skb_mark_for_recycle solution ###
> > >
> > > ./xdp_rxq_info --dev eth0 --act XDP_DROP --read
> > >
> > > Running XDP on dev:eth0 (ifindex:2) action:XDP_DROP options:read
> > > XDP stats       CPU     pps         issue-pps
> > > XDP-RX CPU      0       466,553     0
> > > XDP-RX CPU      total   466,553
> > >
> > > ./xdp_rxq_info -S --dev eth0 --act XDP_DROP --read
> > >
> > > Running XDP on dev:eth0 (ifindex:2) action:XDP_DROP options:read
> > > XDP stats       CPU     pps         issue-pps
> > > XDP-RX CPU      0       226,272     0
> > > XDP-RX CPU      total   226,272
> > >
> > > ./xdp_rxq_info --dev eth0 --act XDP_PASS --read
> > >
> > > Running XDP on dev:eth0 (ifindex:2) action:XDP_PASS options:read
> > > XDP stats       CPU     pps         issue-pps
> > > XDP-RX CPU      0       80,518      0
> > > XDP-RX CPU      total   80,518
> > >
> > > ./xdp_rxq_info -S --dev eth0 --act XDP_PASS --read
> > >
> > > Running XDP on dev:eth0 (ifindex:2) action:XDP_PASS options:read
> > > XDP stats       CPU     pps         issue-pps
> > > XDP-RX CPU      0       113,681     0
> > > XDP-RX CPU      total   113,681
> > >
> > >
> > > ### page_pool_release_page solution ###
> > >
> > > ./xdp_rxq_info --dev eth0 --act XDP_DROP --read
> > >
> > > Running XDP on dev:eth0 (ifindex:2) action:XDP_DROP options:read
> > > XDP stats       CPU     pps         issue-pps
> > > XDP-RX CPU      0       463,145     0
> > > XDP-RX CPU      total   463,145
> > >
> > > ./xdp_rxq_info -S --dev eth0 --act XDP_DROP --read
> > >
> > > Running XDP on dev:eth0 (ifindex:2) action:XDP_DROP options:read
> > > XDP stats       CPU     pps         issue-pps
> > > XDP-RX CPU      0       104,443     0
> > > XDP-RX CPU      total   104,443
> > >
> > > ./xdp_rxq_info --dev eth0 --act XDP_PASS --read
> > >
> > > Running XDP on dev:eth0 (ifindex:2) action:XDP_PASS options:read
> > > XDP stats       CPU     pps         issue-pps
> > > XDP-RX CPU      0       60,539      0
> > > XDP-RX CPU      total   60,539
> > >
> > > ./xdp_rxq_info -S --dev eth0 --act XDP_PASS --read
> > >
> > > Running XDP on dev:eth0 (ifindex:2) action:XDP_PASS options:read
> > > XDP stats       CPU     pps         issue-pps
> > > XDP-RX CPU      0       62,566      0
> > > XDP-RX CPU      total   62,566
> > >
> > >> -----Original Message-----
> > >> From: Shenwei Wang
> > >> Sent: Tuesday, October 4, 2022 8:34 AM
> > >> To: Jesper Dangaard Brouer <jbrouer@redhat.com>; Andrew Lunn
> > >> <andrew@lunn.ch>
> > >> Cc: brouer@redhat.com; David S. Miller <davem@davemloft.net>; Eric
> > >> Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>;
> > >> Paolo Abeni <pabeni@redhat.com>; Alexei Starovoitov
> > >> <ast@kernel.org>; Daniel Borkmann <daniel@iogearbox.net>; Jesper
> > >> Dangaard Brouer <hawk@kernel.org>; John Fastabend
> > >> <john.fastabend@gmail.com>; netdev@vger.kernel.org; linux-
> > >> kernel@vger.kernel.org; imx@lists.linux.dev; Magnus Karlsson
> > >> <magnus.karlsson@gmail.com>; Björn Töpel <bjorn@kernel.org>; Ilias
> > >> Apalodimas <ilias.apalodimas@linaro.org>
> > >> Subject: RE: [EXT] Re: [PATCH 1/1] net: fec: add initial XDP
> > >> support
> > >>
> > >>
> > >>
> > >>> -----Original Message-----
> > >>> From: Shenwei Wang
> > >>> Sent: Tuesday, October 4, 2022 8:13 AM
> > >>> To: Jesper Dangaard Brouer <jbrouer@redhat.com>; Andrew Lunn
> > >> ...
> > >>> I haven't tested xdp_rxq_info yet, and will have a try sometime later today.
> > >>> However, for the XDP_DROP test, I did try xdp2 test case, and the
> > >>> testing result looks reasonable. The performance of Native mode is
> > >>> much higher than skb- mode.
> > >>>
> > >>> # xdp2 eth0
> > >>>   proto 0:     475362 pkt/s
> > >>>
> > >>> # xdp2 -S eth0             (page_pool_release_page solution)
> > >>>   proto 17:     71999 pkt/s
> > >>>
> > >>> # xdp2 -S eth0             (skb_mark_for_recycle solution)
> > >>>   proto 17:     72228 pkt/s
> > >>>
> > >>
> > >> Correction for xdp2 -S eth0  (skb_mark_for_recycle solution)
> > >> proto 0:          0 pkt/s
> > >> proto 17:     122473 pkt/s
> > >>
> > >> Thanks,
> > >> Shenwei
> > >
> >

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [EXT] Re: [PATCH 1/1] net: fec: add initial XDP support
  2022-10-06  8:37                         ` Jesper Dangaard Brouer
@ 2022-10-07  8:08                           ` Ilias Apalodimas
  2022-10-07 19:18                             ` Shenwei Wang
  0 siblings, 1 reply; 25+ messages in thread
From: Ilias Apalodimas @ 2022-10-07  8:08 UTC (permalink / raw)
  To: Jesper Dangaard Brouer
  Cc: Shenwei Wang, Andrew Lunn, brouer, David S. Miller, Eric Dumazet,
	Jakub Kicinski, Paolo Abeni, Alexei Starovoitov, Daniel Borkmann,
	Jesper Dangaard Brouer, John Fastabend, netdev, linux-kernel,
	imx, Magnus Karlsson, Björn Töpel

Hi Jesper,

On Thu, 6 Oct 2022 at 11:37, Jesper Dangaard Brouer <jbrouer@redhat.com> wrote:
>
>
>
> On 05/10/2022 14.40, Shenwei Wang wrote:
> > Hi Jesper,
> >
> > Here is the summary of "xdp_rxq_info" testing.
> >
> >                skb_mark_for_recycle           page_pool_release_page
> >
> >               Native        SKB-Mode           Native          SKB-Mode
> > XDP_DROP     460K           220K              460K             102K
> > XDP_PASS     80K            113K              60K              62K
> >
>
> It is very pleasing to see the *huge* performance benefit that page_pool
> provide when recycling pages for SKBs (via skb_mark_for_recycle).
> I did expect a performance boost, but not around a x2 performance boost.

Indeed that's a pleasant surprise.  Keep in mind that if we convert
more driver we
can also get rid of copy_break code sprinkled around in drivers.

Thanks
/Ilias
>
> I guess this platform have a larger overhead for DMA-mapping and
> page-allocation.
>
> IMHO it would be valuable to include this result as part of the patch
> description when you post the XDP patch again.
>
> Only strange result is XDP_PASS 'Native' is slower that 'SKB-mode'. I
> cannot explain why, as XDP_PASS essentially does nothing and just follow
> normal driver code to netstack.
>
> Thanks a lot for doing these tests.
> --Jesper
>
> > The following are the testing log.
> >
> > Thanks,
> > Shenwei
> >
> > ### skb_mark_for_recycle solution ###
> >
> > ./xdp_rxq_info --dev eth0 --act XDP_DROP --read
> >
> > Running XDP on dev:eth0 (ifindex:2) action:XDP_DROP options:read
> > XDP stats       CPU     pps         issue-pps
> > XDP-RX CPU      0       466,553     0
> > XDP-RX CPU      total   466,553
> >
> > ./xdp_rxq_info -S --dev eth0 --act XDP_DROP --read
> >
> > Running XDP on dev:eth0 (ifindex:2) action:XDP_DROP options:read
> > XDP stats       CPU     pps         issue-pps
> > XDP-RX CPU      0       226,272     0
> > XDP-RX CPU      total   226,272
> >
> > ./xdp_rxq_info --dev eth0 --act XDP_PASS --read
> >
> > Running XDP on dev:eth0 (ifindex:2) action:XDP_PASS options:read
> > XDP stats       CPU     pps         issue-pps
> > XDP-RX CPU      0       80,518      0
> > XDP-RX CPU      total   80,518
> >
> > ./xdp_rxq_info -S --dev eth0 --act XDP_PASS --read
> >
> > Running XDP on dev:eth0 (ifindex:2) action:XDP_PASS options:read
> > XDP stats       CPU     pps         issue-pps
> > XDP-RX CPU      0       113,681     0
> > XDP-RX CPU      total   113,681
> >
> >
> > ### page_pool_release_page solution ###
> >
> > ./xdp_rxq_info --dev eth0 --act XDP_DROP --read
> >
> > Running XDP on dev:eth0 (ifindex:2) action:XDP_DROP options:read
> > XDP stats       CPU     pps         issue-pps
> > XDP-RX CPU      0       463,145     0
> > XDP-RX CPU      total   463,145
> >
> > ./xdp_rxq_info -S --dev eth0 --act XDP_DROP --read
> >
> > Running XDP on dev:eth0 (ifindex:2) action:XDP_DROP options:read
> > XDP stats       CPU     pps         issue-pps
> > XDP-RX CPU      0       104,443     0
> > XDP-RX CPU      total   104,443
> >
> > ./xdp_rxq_info --dev eth0 --act XDP_PASS --read
> >
> > Running XDP on dev:eth0 (ifindex:2) action:XDP_PASS options:read
> > XDP stats       CPU     pps         issue-pps
> > XDP-RX CPU      0       60,539      0
> > XDP-RX CPU      total   60,539
> >
> > ./xdp_rxq_info -S --dev eth0 --act XDP_PASS --read
> >
> > Running XDP on dev:eth0 (ifindex:2) action:XDP_PASS options:read
> > XDP stats       CPU     pps         issue-pps
> > XDP-RX CPU      0       62,566      0
> > XDP-RX CPU      total   62,566
> >
> >> -----Original Message-----
> >> From: Shenwei Wang
> >> Sent: Tuesday, October 4, 2022 8:34 AM
> >> To: Jesper Dangaard Brouer <jbrouer@redhat.com>; Andrew Lunn
> >> <andrew@lunn.ch>
> >> Cc: brouer@redhat.com; David S. Miller <davem@davemloft.net>; Eric Dumazet
> >> <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni
> >> <pabeni@redhat.com>; Alexei Starovoitov <ast@kernel.org>; Daniel Borkmann
> >> <daniel@iogearbox.net>; Jesper Dangaard Brouer <hawk@kernel.org>; John
> >> Fastabend <john.fastabend@gmail.com>; netdev@vger.kernel.org; linux-
> >> kernel@vger.kernel.org; imx@lists.linux.dev; Magnus Karlsson
> >> <magnus.karlsson@gmail.com>; Björn Töpel <bjorn@kernel.org>; Ilias
> >> Apalodimas <ilias.apalodimas@linaro.org>
> >> Subject: RE: [EXT] Re: [PATCH 1/1] net: fec: add initial XDP support
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Shenwei Wang
> >>> Sent: Tuesday, October 4, 2022 8:13 AM
> >>> To: Jesper Dangaard Brouer <jbrouer@redhat.com>; Andrew Lunn
> >> ...
> >>> I haven't tested xdp_rxq_info yet, and will have a try sometime later today.
> >>> However, for the XDP_DROP test, I did try xdp2 test case, and the
> >>> testing result looks reasonable. The performance of Native mode is
> >>> much higher than skb- mode.
> >>>
> >>> # xdp2 eth0
> >>>   proto 0:     475362 pkt/s
> >>>
> >>> # xdp2 -S eth0             (page_pool_release_page solution)
> >>>   proto 17:     71999 pkt/s
> >>>
> >>> # xdp2 -S eth0             (skb_mark_for_recycle solution)
> >>>   proto 17:     72228 pkt/s
> >>>
> >>
> >> Correction for xdp2 -S eth0  (skb_mark_for_recycle solution)
> >> proto 0:          0 pkt/s
> >> proto 17:     122473 pkt/s
> >>
> >> Thanks,
> >> Shenwei
> >
>

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [EXT] Re: [PATCH 1/1] net: fec: add initial XDP support
  2022-10-05 12:40                       ` Shenwei Wang
@ 2022-10-06  8:37                         ` Jesper Dangaard Brouer
  2022-10-07  8:08                           ` Ilias Apalodimas
  0 siblings, 1 reply; 25+ messages in thread
From: Jesper Dangaard Brouer @ 2022-10-06  8:37 UTC (permalink / raw)
  To: Shenwei Wang, Jesper Dangaard Brouer, Andrew Lunn
  Cc: brouer, David S. Miller, Eric Dumazet, Jakub Kicinski,
	Paolo Abeni, Alexei Starovoitov, Daniel Borkmann,
	Jesper Dangaard Brouer, John Fastabend, netdev, linux-kernel,
	imx, Magnus Karlsson, Björn Töpel, Ilias Apalodimas



On 05/10/2022 14.40, Shenwei Wang wrote:
> Hi Jesper,
> 
> Here is the summary of "xdp_rxq_info" testing.
> 
>                skb_mark_for_recycle           page_pool_release_page
> 
>               Native        SKB-Mode           Native          SKB-Mode
> XDP_DROP     460K           220K              460K             102K
> XDP_PASS     80K            113K              60K              62K
> 

It is very pleasing to see the *huge* performance benefit that page_pool
provide when recycling pages for SKBs (via skb_mark_for_recycle).
I did expect a performance boost, but not around a x2 performance boost.

I guess this platform have a larger overhead for DMA-mapping and
page-allocation.

IMHO it would be valuable to include this result as part of the patch
description when you post the XDP patch again.

Only strange result is XDP_PASS 'Native' is slower that 'SKB-mode'. I
cannot explain why, as XDP_PASS essentially does nothing and just follow
normal driver code to netstack.

Thanks a lot for doing these tests.
--Jesper

> The following are the testing log.
> 
> Thanks,
> Shenwei
> 
> ### skb_mark_for_recycle solution ###
> 
> ./xdp_rxq_info --dev eth0 --act XDP_DROP --read
> 
> Running XDP on dev:eth0 (ifindex:2) action:XDP_DROP options:read
> XDP stats       CPU     pps         issue-pps
> XDP-RX CPU      0       466,553     0
> XDP-RX CPU      total   466,553
> 
> ./xdp_rxq_info -S --dev eth0 --act XDP_DROP --read
> 
> Running XDP on dev:eth0 (ifindex:2) action:XDP_DROP options:read
> XDP stats       CPU     pps         issue-pps
> XDP-RX CPU      0       226,272     0
> XDP-RX CPU      total   226,272
> 
> ./xdp_rxq_info --dev eth0 --act XDP_PASS --read
> 
> Running XDP on dev:eth0 (ifindex:2) action:XDP_PASS options:read
> XDP stats       CPU     pps         issue-pps
> XDP-RX CPU      0       80,518      0
> XDP-RX CPU      total   80,518
> 
> ./xdp_rxq_info -S --dev eth0 --act XDP_PASS --read
> 
> Running XDP on dev:eth0 (ifindex:2) action:XDP_PASS options:read
> XDP stats       CPU     pps         issue-pps
> XDP-RX CPU      0       113,681     0
> XDP-RX CPU      total   113,681
> 
> 
> ### page_pool_release_page solution ###
> 
> ./xdp_rxq_info --dev eth0 --act XDP_DROP --read
> 
> Running XDP on dev:eth0 (ifindex:2) action:XDP_DROP options:read
> XDP stats       CPU     pps         issue-pps
> XDP-RX CPU      0       463,145     0
> XDP-RX CPU      total   463,145
> 
> ./xdp_rxq_info -S --dev eth0 --act XDP_DROP --read
> 
> Running XDP on dev:eth0 (ifindex:2) action:XDP_DROP options:read
> XDP stats       CPU     pps         issue-pps
> XDP-RX CPU      0       104,443     0
> XDP-RX CPU      total   104,443
> 
> ./xdp_rxq_info --dev eth0 --act XDP_PASS --read
> 
> Running XDP on dev:eth0 (ifindex:2) action:XDP_PASS options:read
> XDP stats       CPU     pps         issue-pps
> XDP-RX CPU      0       60,539      0
> XDP-RX CPU      total   60,539
> 
> ./xdp_rxq_info -S --dev eth0 --act XDP_PASS --read
> 
> Running XDP on dev:eth0 (ifindex:2) action:XDP_PASS options:read
> XDP stats       CPU     pps         issue-pps
> XDP-RX CPU      0       62,566      0
> XDP-RX CPU      total   62,566
> 
>> -----Original Message-----
>> From: Shenwei Wang
>> Sent: Tuesday, October 4, 2022 8:34 AM
>> To: Jesper Dangaard Brouer <jbrouer@redhat.com>; Andrew Lunn
>> <andrew@lunn.ch>
>> Cc: brouer@redhat.com; David S. Miller <davem@davemloft.net>; Eric Dumazet
>> <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni
>> <pabeni@redhat.com>; Alexei Starovoitov <ast@kernel.org>; Daniel Borkmann
>> <daniel@iogearbox.net>; Jesper Dangaard Brouer <hawk@kernel.org>; John
>> Fastabend <john.fastabend@gmail.com>; netdev@vger.kernel.org; linux-
>> kernel@vger.kernel.org; imx@lists.linux.dev; Magnus Karlsson
>> <magnus.karlsson@gmail.com>; Björn Töpel <bjorn@kernel.org>; Ilias
>> Apalodimas <ilias.apalodimas@linaro.org>
>> Subject: RE: [EXT] Re: [PATCH 1/1] net: fec: add initial XDP support
>>
>>
>>
>>> -----Original Message-----
>>> From: Shenwei Wang
>>> Sent: Tuesday, October 4, 2022 8:13 AM
>>> To: Jesper Dangaard Brouer <jbrouer@redhat.com>; Andrew Lunn
>> ...
>>> I haven't tested xdp_rxq_info yet, and will have a try sometime later today.
>>> However, for the XDP_DROP test, I did try xdp2 test case, and the
>>> testing result looks reasonable. The performance of Native mode is
>>> much higher than skb- mode.
>>>
>>> # xdp2 eth0
>>>   proto 0:     475362 pkt/s
>>>
>>> # xdp2 -S eth0             (page_pool_release_page solution)
>>>   proto 17:     71999 pkt/s
>>>
>>> # xdp2 -S eth0             (skb_mark_for_recycle solution)
>>>   proto 17:     72228 pkt/s
>>>
>>
>> Correction for xdp2 -S eth0	(skb_mark_for_recycle solution)
>> proto 0:          0 pkt/s
>> proto 17:     122473 pkt/s
>>
>> Thanks,
>> Shenwei
> 


^ permalink raw reply	[flat|nested] 25+ messages in thread

* RE: [EXT] Re: [PATCH 1/1] net: fec: add initial XDP support
  2022-10-04 13:34                     ` Shenwei Wang
@ 2022-10-05 12:40                       ` Shenwei Wang
  2022-10-06  8:37                         ` Jesper Dangaard Brouer
  0 siblings, 1 reply; 25+ messages in thread
From: Shenwei Wang @ 2022-10-05 12:40 UTC (permalink / raw)
  To: Jesper Dangaard Brouer, Andrew Lunn
  Cc: brouer, David S. Miller, Eric Dumazet, Jakub Kicinski,
	Paolo Abeni, Alexei Starovoitov, Daniel Borkmann,
	Jesper Dangaard Brouer, John Fastabend, netdev, linux-kernel,
	imx, Magnus Karlsson, Björn Töpel, Ilias Apalodimas

Hi Jesper,

Here is the summary of "xdp_rxq_info" testing.

              skb_mark_for_recycle           page_pool_release_page

             Native        SKB-Mode           Native          SKB-Mode
XDP_DROP     460K           220K              460K             102K
XDP_PASS     80K            113K              60K              62K


The following are the testing log.

Thanks,
Shenwei

### skb_mark_for_recycle solution ###

./xdp_rxq_info --dev eth0 --act XDP_DROP --read

Running XDP on dev:eth0 (ifindex:2) action:XDP_DROP options:read
XDP stats       CPU     pps         issue-pps
XDP-RX CPU      0       466,553     0
XDP-RX CPU      total   466,553

./xdp_rxq_info -S --dev eth0 --act XDP_DROP --read

Running XDP on dev:eth0 (ifindex:2) action:XDP_DROP options:read
XDP stats       CPU     pps         issue-pps
XDP-RX CPU      0       226,272     0
XDP-RX CPU      total   226,272

./xdp_rxq_info --dev eth0 --act XDP_PASS --read

Running XDP on dev:eth0 (ifindex:2) action:XDP_PASS options:read
XDP stats       CPU     pps         issue-pps
XDP-RX CPU      0       80,518      0
XDP-RX CPU      total   80,518

./xdp_rxq_info -S --dev eth0 --act XDP_PASS --read

Running XDP on dev:eth0 (ifindex:2) action:XDP_PASS options:read
XDP stats       CPU     pps         issue-pps
XDP-RX CPU      0       113,681     0
XDP-RX CPU      total   113,681


### page_pool_release_page solution ###

./xdp_rxq_info --dev eth0 --act XDP_DROP --read

Running XDP on dev:eth0 (ifindex:2) action:XDP_DROP options:read
XDP stats       CPU     pps         issue-pps
XDP-RX CPU      0       463,145     0
XDP-RX CPU      total   463,145

./xdp_rxq_info -S --dev eth0 --act XDP_DROP --read

Running XDP on dev:eth0 (ifindex:2) action:XDP_DROP options:read
XDP stats       CPU     pps         issue-pps
XDP-RX CPU      0       104,443     0
XDP-RX CPU      total   104,443

./xdp_rxq_info --dev eth0 --act XDP_PASS --read

Running XDP on dev:eth0 (ifindex:2) action:XDP_PASS options:read
XDP stats       CPU     pps         issue-pps
XDP-RX CPU      0       60,539      0
XDP-RX CPU      total   60,539

./xdp_rxq_info -S --dev eth0 --act XDP_PASS --read

Running XDP on dev:eth0 (ifindex:2) action:XDP_PASS options:read
XDP stats       CPU     pps         issue-pps
XDP-RX CPU      0       62,566      0
XDP-RX CPU      total   62,566

> -----Original Message-----
> From: Shenwei Wang
> Sent: Tuesday, October 4, 2022 8:34 AM
> To: Jesper Dangaard Brouer <jbrouer@redhat.com>; Andrew Lunn
> <andrew@lunn.ch>
> Cc: brouer@redhat.com; David S. Miller <davem@davemloft.net>; Eric Dumazet
> <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni
> <pabeni@redhat.com>; Alexei Starovoitov <ast@kernel.org>; Daniel Borkmann
> <daniel@iogearbox.net>; Jesper Dangaard Brouer <hawk@kernel.org>; John
> Fastabend <john.fastabend@gmail.com>; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; imx@lists.linux.dev; Magnus Karlsson
> <magnus.karlsson@gmail.com>; Björn Töpel <bjorn@kernel.org>; Ilias
> Apalodimas <ilias.apalodimas@linaro.org>
> Subject: RE: [EXT] Re: [PATCH 1/1] net: fec: add initial XDP support
> 
> 
> 
> > -----Original Message-----
> > From: Shenwei Wang
> > Sent: Tuesday, October 4, 2022 8:13 AM
> > To: Jesper Dangaard Brouer <jbrouer@redhat.com>; Andrew Lunn
> ...
> > I haven't tested xdp_rxq_info yet, and will have a try sometime later today.
> > However, for the XDP_DROP test, I did try xdp2 test case, and the
> > testing result looks reasonable. The performance of Native mode is
> > much higher than skb- mode.
> >
> > # xdp2 eth0
> >  proto 0:     475362 pkt/s
> >
> > # xdp2 -S eth0             (page_pool_release_page solution)
> >  proto 17:     71999 pkt/s
> >
> > # xdp2 -S eth0             (skb_mark_for_recycle solution)
> >  proto 17:     72228 pkt/s
> >
> 
> Correction for xdp2 -S eth0	(skb_mark_for_recycle solution)
> proto 0:          0 pkt/s
> proto 17:     122473 pkt/s
> 
> Thanks,
> Shenwei


^ permalink raw reply	[flat|nested] 25+ messages in thread

* RE: [EXT] Re: [PATCH 1/1] net: fec: add initial XDP support
  2022-10-04 13:12                   ` Shenwei Wang
@ 2022-10-04 13:34                     ` Shenwei Wang
  2022-10-05 12:40                       ` Shenwei Wang
  0 siblings, 1 reply; 25+ messages in thread
From: Shenwei Wang @ 2022-10-04 13:34 UTC (permalink / raw)
  To: Jesper Dangaard Brouer, Andrew Lunn
  Cc: brouer, David S. Miller, Eric Dumazet, Jakub Kicinski,
	Paolo Abeni, Alexei Starovoitov, Daniel Borkmann,
	Jesper Dangaard Brouer, John Fastabend, netdev, linux-kernel,
	imx, Magnus Karlsson, Björn Töpel, Ilias Apalodimas



> -----Original Message-----
> From: Shenwei Wang
> Sent: Tuesday, October 4, 2022 8:13 AM
> To: Jesper Dangaard Brouer <jbrouer@redhat.com>; Andrew Lunn
...
> I haven't tested xdp_rxq_info yet, and will have a try sometime later today.
> However, for the XDP_DROP test, I did try xdp2 test case, and the testing result
> looks reasonable. The performance of Native mode is much higher than skb-
> mode.
> 
> # xdp2 eth0
>  proto 0:     475362 pkt/s
> 
> # xdp2 -S eth0             (page_pool_release_page solution)
>  proto 17:     71999 pkt/s
> 
> # xdp2 -S eth0             (skb_mark_for_recycle solution)
>  proto 17:     72228 pkt/s
> 

Correction for xdp2 -S eth0	(skb_mark_for_recycle solution)
proto 0:          0 pkt/s
proto 17:     122473 pkt/s

Thanks,
Shenwei


^ permalink raw reply	[flat|nested] 25+ messages in thread

* RE: [EXT] Re: [PATCH 1/1] net: fec: add initial XDP support
  2022-10-04 11:21                 ` Jesper Dangaard Brouer
@ 2022-10-04 13:12                   ` Shenwei Wang
  2022-10-04 13:34                     ` Shenwei Wang
  0 siblings, 1 reply; 25+ messages in thread
From: Shenwei Wang @ 2022-10-04 13:12 UTC (permalink / raw)
  To: Jesper Dangaard Brouer, Andrew Lunn
  Cc: brouer, Joakim Zhang, David S. Miller, Eric Dumazet,
	Jakub Kicinski, Paolo Abeni, Alexei Starovoitov, Daniel Borkmann,
	Jesper Dangaard Brouer, John Fastabend, netdev, linux-kernel,
	imx, Magnus Karlsson, Björn Töpel, Ilias Apalodimas



> -----Original Message-----
> From: Jesper Dangaard Brouer <jbrouer@redhat.com>
> Sent: Tuesday, October 4, 2022 6:22 AM
> To: Shenwei Wang <shenwei.wang@nxp.com>; Jesper Dangaard Brouer
> <jbrouer@redhat.com>; Andrew Lunn <andrew@lunn.ch>
> Cc: brouer@redhat.com; Joakim Zhang <qiangqing.zhang@nxp.com>; David S.
> Miller <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>; Jakub
> Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; Alexei
> Starovoitov <ast@kernel.org>; Daniel Borkmann <daniel@iogearbox.net>;
> Jesper Dangaard Brouer <hawk@kernel.org>; John Fastabend
> <john.fastabend@gmail.com>; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; imx@lists.linux.dev; Magnus Karlsson
> <magnus.karlsson@gmail.com>; Björn Töpel <bjorn@kernel.org>; Ilias
> Apalodimas <ilias.apalodimas@linaro.org>
> Subject: Re: [EXT] Re: [PATCH 1/1] net: fec: add initial XDP support
> 
> Caution: EXT Email
> 
> On 03/10/2022 14.49, Shenwei Wang wrote:
> > Hi Jesper,
> >
> >>>> On mvneta driver/platform we saw huge speedup replacing:
> >>>>
> >>>>      page_pool_release_page(rxq->page_pool, page); with
> >>>>      skb_mark_for_recycle(skb);
> >>>>
> >
> > After replacing the page_pool_release_page with the
> > skb_mark_for_recycle, I found something confused me a little in the
> > testing result. > I tested with the sample app of "xdpsock" under two
> > modes:
> >  1. Native (xdpsock -i eth0).
> >  2. Skb-mode (xdpsock -S -i eth0).
> Great that you are also testing AF_XDP, but do you have a particular use-case
> that needs AF_XDP on this board?

The purpose is to provide our customers an alternative solution to the current DPDK implementation.

> 
> What packet size are used in below results?

The packets were generated by pktgen_sample03_burst_single_flow.sh, and its size is 60 bytes 0 frags.

> 
> > The following are the testing result:
>  >
> >       With page_pool_release_page (pps)  With skb_mark_for_recycle
> > (pps)
> >
> >   SKB-Mode                          90K                            200K
> >   Native                           190K                            190K
> >
> 
> The default AF_XDP test with xdpsock is rxdrop IIRC.
> 
> Can you test the normal XDP code path and do a XDP_DROP test via the samples
> tool 'xdp_rxq_info' and cmdline:
> 
>    sudo ./xdp_rxq_info --dev eth42 --act XDP_DROP --read
> 
> And then same with --skb-mode

I haven't tested xdp_rxq_info yet, and will have a try sometime later today. However, for the XDP_DROP test, I 
did try xdp2 test case, and the testing result looks reasonable. The performance of Native mode is much higher than skb-mode.

# xdp2 eth0
 proto 0:     475362 pkt/s

# xdp2 -S eth0             (page_pool_release_page solution)
 proto 17:     71999 pkt/s

# xdp2 -S eth0             (skb_mark_for_recycle solution)
 proto 17:     72228 pkt/s

> 
> > The skb_mark_for_recycle solution boosted the performance of SKB-Mode
> > to 200K+ PPS. That is even higher than the performance of Native
> > solution.  Is this result reasonable? Do you have any clue why the
> > SKB-Mode performance can go higher than that of Native one?
> I might be able to explain this (Cc. AF_XDP maintainers to keep me honest).
> 
> When you say "native" *AF_XDP* that isn't Zero-Copy AF_XDP.
> 

Right. Zero-copy hasn't been implemented yet.

> Sure, XDP runs in native driver mode and redirects the raw frames into the
> AF_XDP socket, but as this isn't zero-copy AF_XDP. Thus, the packets needs to be
> copied into the AF_XDP buffers.
> 
> As soon as the frame or SKB (for generic XDP) have been copied it is
> released/freed by AF_XDP/xsk code (either via xdp_return_buff() or
> consume_skb()). Thus, it looks like it really pays off to recycle the frame via
> page_pool, also for the SKB consume_skb() case.
> 
> I am still a little surprised that to can be faster than native AF_XDP, as the SKB-
> mode ("XDP-generic") needs to call through lot more software layers and
> convert the SKB to look like an xdp_buff.

That's what I can't understand right now too.

Thanks very much for the explanations!
Shenwei

> 
> --Jesper
> 
> 
> 
> >> -----Original Message-----
> >> From: Jesper Dangaard Brouer <jbrouer@redhat.com>
> >> Sent: Thursday, September 29, 2022 1:55 PM
> >> To: Shenwei Wang <shenwei.wang@nxp.com>; Jesper Dangaard Brouer
> >> <jbrouer@redhat.com>; Andrew Lunn <andrew@lunn.ch>
> >> Cc: brouer@redhat.com; Joakim Zhang <qiangqing.zhang@nxp.com>; David
> S.
> >> Miller <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>;
> >> Jakub Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>;
> >> Alexei Starovoitov <ast@kernel.org>; Daniel Borkmann
> >> <daniel@iogearbox.net>; Jesper Dangaard Brouer <hawk@kernel.org>;
> >> John Fastabend <john.fastabend@gmail.com>; netdev@vger.kernel.org;
> >> linux- kernel@vger.kernel.org; imx@lists.linux.dev
> >> Subject: Re: [EXT] Re: [PATCH 1/1] net: fec: add initial XDP support
> >>
> >> Caution: EXT Email
> >>
> >> On 29/09/2022 17.52, Shenwei Wang wrote:
> >>>
> >>>> From: Jesper Dangaard Brouer <jbrouer@redhat.com>
> >>>>
> >>>> On 29/09/2022 15.26, Shenwei Wang wrote:
> >>>>>
> >>>>>> From: Andrew Lunn <andrew@lunn.ch>
> >>>>>> Sent: Thursday, September 29, 2022 8:23 AM
> >>>> [...]
> >>>>>>
> >>>>>>> I actually did some compare testing regarding the page pool for
> >>>>>>> normal traffic.  So far I don't see significant improvement in
> >>>>>>> the current implementation. The performance for large packets
> >>>>>>> improves a little, and the performance for small packets get a little
> worse.
> >>>>>>
> >>>>>> What hardware was this for? imx51? imx6? imx7 Vybrid? These all
> >>>>>> use the
> >> FEC.
> >>>>>
> >>>>> I tested on imx8qxp platform. It is ARM64.
> >>>>
> >>>> On mvneta driver/platform we saw huge speedup replacing:
> >>>>
> >>>>      page_pool_release_page(rxq->page_pool, page); with
> >>>>      skb_mark_for_recycle(skb);
> >>>>
> >>>> As I mentioned: Today page_pool have SKB recycle support (you might
> >>>> have looked at drivers that didn't utilize this yet), thus you
> >>>> don't need to release the page (page_pool_release_page) here.
> >>>> Instead you could simply mark the SKB for recycling, unless driver
> >>>> does some page refcnt
> >> tricks I didn't notice.
> >>>>
> >>>> On the mvneta driver/platform the DMA unmap (in
> >>>> page_pool_release_page) was very expensive. This imx8qxp platform
> >>>> might have faster DMA unmap in case is it cache-coherent.
> >>>>
> >>>> I would be very interested in knowing if skb_mark_for_recycle()
> >>>> helps on this platform, for normal network stack performance.
> >>>>
> >>>
> >>> Did a quick compare testing for the following 3 scenarios:
> >>
> >> Thanks for doing this! :-)
> >>
> >>> 1. original implementation
> >>>
> >>> shenwei@5810:~$ iperf -c 10.81.16.245 -w 2m -i 1
> >>> ------------------------------------------------------------
> >>> Client connecting to 10.81.16.245, TCP port 5001 TCP window size:
> >>> 416 KByte (WARNING: requested 1.91 MByte)
> >>> ------------------------------------------------------------
> >>> [  1] local 10.81.17.20 port 49154 connected with 10.81.16.245 port 5001
> >>> [ ID] Interval       Transfer     Bandwidth
> >>> [  1] 0.0000-1.0000 sec   104 MBytes   868 Mbits/sec
> >>> [  1] 1.0000-2.0000 sec   105 MBytes   878 Mbits/sec
> >>> [  1] 2.0000-3.0000 sec   105 MBytes   881 Mbits/sec
> >>> [  1] 3.0000-4.0000 sec   105 MBytes   879 Mbits/sec
> >>> [  1] 4.0000-5.0000 sec   105 MBytes   878 Mbits/sec
> >>> [  1] 5.0000-6.0000 sec   105 MBytes   878 Mbits/sec
> >>> [  1] 6.0000-7.0000 sec   104 MBytes   875 Mbits/sec
> >>> [  1] 7.0000-8.0000 sec   104 MBytes   875 Mbits/sec
> >>> [  1] 8.0000-9.0000 sec   104 MBytes   873 Mbits/sec
> >>> [  1] 9.0000-10.0000 sec   104 MBytes   875 Mbits/sec
> >>> [  1] 0.0000-10.0073 sec  1.02 GBytes   875 Mbits/sec
> >>>
> >>> 2. Page pool with page_pool_release_page
> >>>
> >>> shenwei@5810:~$ iperf -c 10.81.16.245 -w 2m -i 1
> >>> ------------------------------------------------------------
> >>> Client connecting to 10.81.16.245, TCP port 5001 TCP window size:
> >>> 416 KByte (WARNING: requested 1.91 MByte)
> >>> ------------------------------------------------------------
> >>> [  1] local 10.81.17.20 port 35924 connected with 10.81.16.245 port 5001
> >>> [ ID] Interval       Transfer     Bandwidth
> >>> [  1] 0.0000-1.0000 sec   101 MBytes   849 Mbits/sec
> >>> [  1] 1.0000-2.0000 sec   102 MBytes   860 Mbits/sec
> >>> [  1] 2.0000-3.0000 sec   102 MBytes   860 Mbits/sec
> >>> [  1] 3.0000-4.0000 sec   102 MBytes   859 Mbits/sec
> >>> [  1] 4.0000-5.0000 sec   103 MBytes   863 Mbits/sec
> >>> [  1] 5.0000-6.0000 sec   103 MBytes   864 Mbits/sec
> >>> [  1] 6.0000-7.0000 sec   103 MBytes   863 Mbits/sec
> >>> [  1] 7.0000-8.0000 sec   103 MBytes   865 Mbits/sec
> >>> [  1] 8.0000-9.0000 sec   103 MBytes   862 Mbits/sec
> >>> [  1] 9.0000-10.0000 sec   102 MBytes   856 Mbits/sec
> >>> [  1] 0.0000-10.0246 sec  1.00 GBytes   858 Mbits/sec
> >>>
> >>>
> >>> 3. page pool with skb_mark_for_recycle
> >>>
> >>> shenwei@5810:~$ iperf -c 10.81.16.245 -w 2m -i 1
> >>> ------------------------------------------------------------
> >>> Client connecting to 10.81.16.245, TCP port 5001 TCP window size:
> >>> 416 KByte (WARNING: requested 1.91 MByte)
> >>> ------------------------------------------------------------
> >>> [  1] local 10.81.17.20 port 42724 connected with 10.81.16.245 port 5001
> >>> [ ID] Interval       Transfer     Bandwidth
> >>> [  1] 0.0000-1.0000 sec   111 MBytes   931 Mbits/sec
> >>> [  1] 1.0000-2.0000 sec   112 MBytes   935 Mbits/sec
> >>> [  1] 2.0000-3.0000 sec   111 MBytes   934 Mbits/sec
> >>> [  1] 3.0000-4.0000 sec   111 MBytes   934 Mbits/sec
> >>> [  1] 4.0000-5.0000 sec   111 MBytes   934 Mbits/sec
> >>> [  1] 5.0000-6.0000 sec   112 MBytes   935 Mbits/sec
> >>> [  1] 6.0000-7.0000 sec   111 MBytes   934 Mbits/sec
> >>> [  1] 7.0000-8.0000 sec   111 MBytes   933 Mbits/sec
> >>> [  1] 8.0000-9.0000 sec   112 MBytes   935 Mbits/sec
> >>> [  1] 9.0000-10.0000 sec   111 MBytes   933 Mbits/sec
> >>> [  1] 0.0000-10.0069 sec  1.09 GBytes   934 Mbits/sec
> >>
> >> This is a very significant performance improvement (page pool with
> >> skb_mark_for_recycle).  This is very close to the max goodput for a 1Gbit/s
> link.
> >>
> >>
> >>> For small packet size (64 bytes), all three cases have almost the same result:
> >>>
> >>
> >> To me this indicate, that the DMA map/unmap operations on this
> >> platform are indeed more expensive on larger packets.  Given this is
> >> what page_pool does, keeping the DMA mapping intact when recycling.
> >>
> >> Driver still need DMA-sync, although I notice you set page_pool
> >> feature flag PP_FLAG_DMA_SYNC_DEV, this is good as page_pool will try
> >> to reduce sync size where possible. E.g. in this SKB case will reduce
> >> the DMA-sync to the max_len=FEC_ENET_RX_FRSIZE which should also help
> on performance.
> >>
> >>
> >>> shenwei@5810:~$ iperf -c 10.81.16.245 -w 2m -i 1 -l 64
> >>> ------------------------------------------------------------
> >>> Client connecting to 10.81.16.245, TCP port 5001 TCP window size:
> >>> 416 KByte (WARNING: requested 1.91 MByte)
> >>> ------------------------------------------------------------
> >>> [  1] local 10.81.17.20 port 58204 connected with 10.81.16.245 port 5001
> >>> [ ID] Interval       Transfer     Bandwidth
> >>> [  1] 0.0000-1.0000 sec  36.9 MBytes   309 Mbits/sec
> >>> [  1] 1.0000-2.0000 sec  36.6 MBytes   307 Mbits/sec
> >>> [  1] 2.0000-3.0000 sec  36.6 MBytes   307 Mbits/sec
> >>> [  1] 3.0000-4.0000 sec  36.5 MBytes   307 Mbits/sec
> >>> [  1] 4.0000-5.0000 sec  37.1 MBytes   311 Mbits/sec
> >>> [  1] 5.0000-6.0000 sec  37.2 MBytes   312 Mbits/sec
> >>> [  1] 6.0000-7.0000 sec  37.1 MBytes   311 Mbits/sec
> >>> [  1] 7.0000-8.0000 sec  37.1 MBytes   311 Mbits/sec
> >>> [  1] 8.0000-9.0000 sec  37.1 MBytes   312 Mbits/sec
> >>> [  1] 9.0000-10.0000 sec  37.2 MBytes   312 Mbits/sec
> >>> [  1] 0.0000-10.0097 sec   369 MBytes   310 Mbits/sec
> >>>
> >>> Regards,
> >>> Shenwei
> >>>
> >>>
> >>>>>> By small packets, do you mean those under the copybreak limit?
> >>>>>>
> >>>>>> Please provide some benchmark numbers with your next patchset.
> >>>>>
> >>>>> Yes, the packet size is 64 bytes and it is under the copybreak limit.
> >>>>> As the impact is not significant, I would prefer to remove the
> >>>>> copybreak  logic.
> >>>>
> >>>> +1 to removing this logic if possible, due to maintenance cost.
> >>>>
> >>>> --Jesper
> >>>
> >


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [EXT] Re: [PATCH 1/1] net: fec: add initial XDP support
  2022-10-03 12:49               ` Shenwei Wang
@ 2022-10-04 11:21                 ` Jesper Dangaard Brouer
  2022-10-04 13:12                   ` Shenwei Wang
  0 siblings, 1 reply; 25+ messages in thread
From: Jesper Dangaard Brouer @ 2022-10-04 11:21 UTC (permalink / raw)
  To: Shenwei Wang, Jesper Dangaard Brouer, Andrew Lunn
  Cc: brouer, Joakim Zhang, David S. Miller, Eric Dumazet,
	Jakub Kicinski, Paolo Abeni, Alexei Starovoitov, Daniel Borkmann,
	Jesper Dangaard Brouer, John Fastabend, netdev, linux-kernel,
	imx, Magnus Karlsson, Björn Töpel, Ilias Apalodimas


On 03/10/2022 14.49, Shenwei Wang wrote:
> Hi Jesper,
> 
>>>> On mvneta driver/platform we saw huge speedup replacing:
>>>>
>>>>      page_pool_release_page(rxq->page_pool, page); with
>>>>      skb_mark_for_recycle(skb);
>>>>
> 
> After replacing the page_pool_release_page with the
> skb_mark_for_recycle, I found something confused me a little in the
> testing result. >
> I tested with the sample app of "xdpsock" under two modes: 
>  1. Native (xdpsock -i eth0). 
>  2. Skb-mode (xdpsock -S -i eth0).
Great that you are also testing AF_XDP, but do you have a particular
use-case that needs AF_XDP on this board?

What packet size are used in below results?

> The following are the testing result:
 >
>       With page_pool_release_page (pps)  With skb_mark_for_recycle (pps)
> 
>   SKB-Mode                          90K                            200K
>   Native                           190K                            190K
> 

The default AF_XDP test with xdpsock is rxdrop IIRC.

Can you test the normal XDP code path and do a XDP_DROP test via the
samples tool 'xdp_rxq_info' and cmdline:

   sudo ./xdp_rxq_info --dev eth42 --act XDP_DROP --read

And then same with --skb-mode

> The skb_mark_for_recycle solution boosted the performance of SKB-Mode
> to 200K+ PPS. That is even higher than the performance of Native
> solution.  Is this result reasonable? Do you have any clue why the
> SKB-Mode performance can go higher than that of Native one?
I might be able to explain this (Cc. AF_XDP maintainers to keep me honest).

When you say "native" *AF_XDP* that isn't Zero-Copy AF_XDP.

Sure, XDP runs in native driver mode and redirects the raw frames into 
the AF_XDP socket, but as this isn't zero-copy AF_XDP. Thus, the packets 
needs to be copied into the AF_XDP buffers.

As soon as the frame or SKB (for generic XDP) have been copied it is 
released/freed by AF_XDP/xsk code (either via xdp_return_buff() or 
consume_skb()). Thus, it looks like it really pays off to recycle the 
frame via page_pool, also for the SKB consume_skb() case.

I am still a little surprised that to can be faster than native AF_XDP, 
as the SKB-mode ("XDP-generic") needs to call through lot more software 
layers and convert the SKB to look like an xdp_buff.

--Jesper



>> -----Original Message-----
>> From: Jesper Dangaard Brouer <jbrouer@redhat.com>
>> Sent: Thursday, September 29, 2022 1:55 PM
>> To: Shenwei Wang <shenwei.wang@nxp.com>; Jesper Dangaard Brouer
>> <jbrouer@redhat.com>; Andrew Lunn <andrew@lunn.ch>
>> Cc: brouer@redhat.com; Joakim Zhang <qiangqing.zhang@nxp.com>; David S.
>> Miller <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>; Jakub
>> Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; Alexei
>> Starovoitov <ast@kernel.org>; Daniel Borkmann <daniel@iogearbox.net>;
>> Jesper Dangaard Brouer <hawk@kernel.org>; John Fastabend
>> <john.fastabend@gmail.com>; netdev@vger.kernel.org; linux-
>> kernel@vger.kernel.org; imx@lists.linux.dev
>> Subject: Re: [EXT] Re: [PATCH 1/1] net: fec: add initial XDP support
>>
>> Caution: EXT Email
>>
>> On 29/09/2022 17.52, Shenwei Wang wrote:
>>>
>>>> From: Jesper Dangaard Brouer <jbrouer@redhat.com>
>>>>
>>>> On 29/09/2022 15.26, Shenwei Wang wrote:
>>>>>
>>>>>> From: Andrew Lunn <andrew@lunn.ch>
>>>>>> Sent: Thursday, September 29, 2022 8:23 AM
>>>> [...]
>>>>>>
>>>>>>> I actually did some compare testing regarding the page pool for
>>>>>>> normal traffic.  So far I don't see significant improvement in the
>>>>>>> current implementation. The performance for large packets improves
>>>>>>> a little, and the performance for small packets get a little worse.
>>>>>>
>>>>>> What hardware was this for? imx51? imx6? imx7 Vybrid? These all use the
>> FEC.
>>>>>
>>>>> I tested on imx8qxp platform. It is ARM64.
>>>>
>>>> On mvneta driver/platform we saw huge speedup replacing:
>>>>
>>>>      page_pool_release_page(rxq->page_pool, page); with
>>>>      skb_mark_for_recycle(skb);
>>>>
>>>> As I mentioned: Today page_pool have SKB recycle support (you might
>>>> have looked at drivers that didn't utilize this yet), thus you don't
>>>> need to release the page (page_pool_release_page) here.  Instead you
>>>> could simply mark the SKB for recycling, unless driver does some page refcnt
>> tricks I didn't notice.
>>>>
>>>> On the mvneta driver/platform the DMA unmap (in
>>>> page_pool_release_page) was very expensive. This imx8qxp platform
>>>> might have faster DMA unmap in case is it cache-coherent.
>>>>
>>>> I would be very interested in knowing if skb_mark_for_recycle() helps
>>>> on this platform, for normal network stack performance.
>>>>
>>>
>>> Did a quick compare testing for the following 3 scenarios:
>>
>> Thanks for doing this! :-)
>>
>>> 1. original implementation
>>>
>>> shenwei@5810:~$ iperf -c 10.81.16.245 -w 2m -i 1
>>> ------------------------------------------------------------
>>> Client connecting to 10.81.16.245, TCP port 5001 TCP window size:  416
>>> KByte (WARNING: requested 1.91 MByte)
>>> ------------------------------------------------------------
>>> [  1] local 10.81.17.20 port 49154 connected with 10.81.16.245 port 5001
>>> [ ID] Interval       Transfer     Bandwidth
>>> [  1] 0.0000-1.0000 sec   104 MBytes   868 Mbits/sec
>>> [  1] 1.0000-2.0000 sec   105 MBytes   878 Mbits/sec
>>> [  1] 2.0000-3.0000 sec   105 MBytes   881 Mbits/sec
>>> [  1] 3.0000-4.0000 sec   105 MBytes   879 Mbits/sec
>>> [  1] 4.0000-5.0000 sec   105 MBytes   878 Mbits/sec
>>> [  1] 5.0000-6.0000 sec   105 MBytes   878 Mbits/sec
>>> [  1] 6.0000-7.0000 sec   104 MBytes   875 Mbits/sec
>>> [  1] 7.0000-8.0000 sec   104 MBytes   875 Mbits/sec
>>> [  1] 8.0000-9.0000 sec   104 MBytes   873 Mbits/sec
>>> [  1] 9.0000-10.0000 sec   104 MBytes   875 Mbits/sec
>>> [  1] 0.0000-10.0073 sec  1.02 GBytes   875 Mbits/sec
>>>
>>> 2. Page pool with page_pool_release_page
>>>
>>> shenwei@5810:~$ iperf -c 10.81.16.245 -w 2m -i 1
>>> ------------------------------------------------------------
>>> Client connecting to 10.81.16.245, TCP port 5001 TCP window size:  416
>>> KByte (WARNING: requested 1.91 MByte)
>>> ------------------------------------------------------------
>>> [  1] local 10.81.17.20 port 35924 connected with 10.81.16.245 port 5001
>>> [ ID] Interval       Transfer     Bandwidth
>>> [  1] 0.0000-1.0000 sec   101 MBytes   849 Mbits/sec
>>> [  1] 1.0000-2.0000 sec   102 MBytes   860 Mbits/sec
>>> [  1] 2.0000-3.0000 sec   102 MBytes   860 Mbits/sec
>>> [  1] 3.0000-4.0000 sec   102 MBytes   859 Mbits/sec
>>> [  1] 4.0000-5.0000 sec   103 MBytes   863 Mbits/sec
>>> [  1] 5.0000-6.0000 sec   103 MBytes   864 Mbits/sec
>>> [  1] 6.0000-7.0000 sec   103 MBytes   863 Mbits/sec
>>> [  1] 7.0000-8.0000 sec   103 MBytes   865 Mbits/sec
>>> [  1] 8.0000-9.0000 sec   103 MBytes   862 Mbits/sec
>>> [  1] 9.0000-10.0000 sec   102 MBytes   856 Mbits/sec
>>> [  1] 0.0000-10.0246 sec  1.00 GBytes   858 Mbits/sec
>>>
>>>
>>> 3. page pool with skb_mark_for_recycle
>>>
>>> shenwei@5810:~$ iperf -c 10.81.16.245 -w 2m -i 1
>>> ------------------------------------------------------------
>>> Client connecting to 10.81.16.245, TCP port 5001 TCP window size:  416
>>> KByte (WARNING: requested 1.91 MByte)
>>> ------------------------------------------------------------
>>> [  1] local 10.81.17.20 port 42724 connected with 10.81.16.245 port 5001
>>> [ ID] Interval       Transfer     Bandwidth
>>> [  1] 0.0000-1.0000 sec   111 MBytes   931 Mbits/sec
>>> [  1] 1.0000-2.0000 sec   112 MBytes   935 Mbits/sec
>>> [  1] 2.0000-3.0000 sec   111 MBytes   934 Mbits/sec
>>> [  1] 3.0000-4.0000 sec   111 MBytes   934 Mbits/sec
>>> [  1] 4.0000-5.0000 sec   111 MBytes   934 Mbits/sec
>>> [  1] 5.0000-6.0000 sec   112 MBytes   935 Mbits/sec
>>> [  1] 6.0000-7.0000 sec   111 MBytes   934 Mbits/sec
>>> [  1] 7.0000-8.0000 sec   111 MBytes   933 Mbits/sec
>>> [  1] 8.0000-9.0000 sec   112 MBytes   935 Mbits/sec
>>> [  1] 9.0000-10.0000 sec   111 MBytes   933 Mbits/sec
>>> [  1] 0.0000-10.0069 sec  1.09 GBytes   934 Mbits/sec
>>
>> This is a very significant performance improvement (page pool with
>> skb_mark_for_recycle).  This is very close to the max goodput for a 1Gbit/s link.
>>
>>
>>> For small packet size (64 bytes), all three cases have almost the same result:
>>>
>>
>> To me this indicate, that the DMA map/unmap operations on this platform are
>> indeed more expensive on larger packets.  Given this is what page_pool does,
>> keeping the DMA mapping intact when recycling.
>>
>> Driver still need DMA-sync, although I notice you set page_pool feature flag
>> PP_FLAG_DMA_SYNC_DEV, this is good as page_pool will try to reduce sync size
>> where possible. E.g. in this SKB case will reduce the DMA-sync to the
>> max_len=FEC_ENET_RX_FRSIZE which should also help on performance.
>>
>>
>>> shenwei@5810:~$ iperf -c 10.81.16.245 -w 2m -i 1 -l 64
>>> ------------------------------------------------------------
>>> Client connecting to 10.81.16.245, TCP port 5001 TCP window size:  416
>>> KByte (WARNING: requested 1.91 MByte)
>>> ------------------------------------------------------------
>>> [  1] local 10.81.17.20 port 58204 connected with 10.81.16.245 port 5001
>>> [ ID] Interval       Transfer     Bandwidth
>>> [  1] 0.0000-1.0000 sec  36.9 MBytes   309 Mbits/sec
>>> [  1] 1.0000-2.0000 sec  36.6 MBytes   307 Mbits/sec
>>> [  1] 2.0000-3.0000 sec  36.6 MBytes   307 Mbits/sec
>>> [  1] 3.0000-4.0000 sec  36.5 MBytes   307 Mbits/sec
>>> [  1] 4.0000-5.0000 sec  37.1 MBytes   311 Mbits/sec
>>> [  1] 5.0000-6.0000 sec  37.2 MBytes   312 Mbits/sec
>>> [  1] 6.0000-7.0000 sec  37.1 MBytes   311 Mbits/sec
>>> [  1] 7.0000-8.0000 sec  37.1 MBytes   311 Mbits/sec
>>> [  1] 8.0000-9.0000 sec  37.1 MBytes   312 Mbits/sec
>>> [  1] 9.0000-10.0000 sec  37.2 MBytes   312 Mbits/sec
>>> [  1] 0.0000-10.0097 sec   369 MBytes   310 Mbits/sec
>>>
>>> Regards,
>>> Shenwei
>>>
>>>
>>>>>> By small packets, do you mean those under the copybreak limit?
>>>>>>
>>>>>> Please provide some benchmark numbers with your next patchset.
>>>>>
>>>>> Yes, the packet size is 64 bytes and it is under the copybreak limit.
>>>>> As the impact is not significant, I would prefer to remove the
>>>>> copybreak  logic.
>>>>
>>>> +1 to removing this logic if possible, due to maintenance cost.
>>>>
>>>> --Jesper
>>>
> 


^ permalink raw reply	[flat|nested] 25+ messages in thread

* RE: [EXT] Re: [PATCH 1/1] net: fec: add initial XDP support
  2022-09-29 18:55             ` Jesper Dangaard Brouer
@ 2022-10-03 12:49               ` Shenwei Wang
  2022-10-04 11:21                 ` Jesper Dangaard Brouer
  0 siblings, 1 reply; 25+ messages in thread
From: Shenwei Wang @ 2022-10-03 12:49 UTC (permalink / raw)
  To: Jesper Dangaard Brouer, Andrew Lunn
  Cc: brouer, Joakim Zhang, David S. Miller, Eric Dumazet,
	Jakub Kicinski, Paolo Abeni, Alexei Starovoitov, Daniel Borkmann,
	Jesper Dangaard Brouer, John Fastabend, netdev, linux-kernel,
	imx

Hi Jesper,

> >> On mvneta driver/platform we saw huge speedup replacing:
> >>
> >>     page_pool_release_page(rxq->page_pool, page); with
> >>     skb_mark_for_recycle(skb);
> >>

After replacing the page_pool_release_page with the skb_mark_for_recycle, I found something confused me a little in the testing result.
I tested with the sample app of "xdpsock" under two modes:  1. Native (xdpsock -i eth0). 2. Skb-mode (xdpsock -S -i eth0). 
The following are the testing result:
			With page_pool_release_page  (pps)                                           With skb_mark_for_recycle (pps)

   SKB-Mode                                  90K                                                                                                     200K       
   Native                                         190K                                                                                                   190K

The skb_mark_for_recycle solution boosted the performance of SKB-Mode to 200K+ PPS. That is even higher than the 
performance of Native solution.  Is this result reasonable? Do you have any clue why the SKB-Mode performance can 
go higher than that of Native one?

Thanks,
Shenwei



> -----Original Message-----
> From: Jesper Dangaard Brouer <jbrouer@redhat.com>
> Sent: Thursday, September 29, 2022 1:55 PM
> To: Shenwei Wang <shenwei.wang@nxp.com>; Jesper Dangaard Brouer
> <jbrouer@redhat.com>; Andrew Lunn <andrew@lunn.ch>
> Cc: brouer@redhat.com; Joakim Zhang <qiangqing.zhang@nxp.com>; David S.
> Miller <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>; Jakub
> Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; Alexei
> Starovoitov <ast@kernel.org>; Daniel Borkmann <daniel@iogearbox.net>;
> Jesper Dangaard Brouer <hawk@kernel.org>; John Fastabend
> <john.fastabend@gmail.com>; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; imx@lists.linux.dev
> Subject: Re: [EXT] Re: [PATCH 1/1] net: fec: add initial XDP support
> 
> Caution: EXT Email
> 
> On 29/09/2022 17.52, Shenwei Wang wrote:
> >
> >> From: Jesper Dangaard Brouer <jbrouer@redhat.com>
> >>
> >> On 29/09/2022 15.26, Shenwei Wang wrote:
> >>>
> >>>> From: Andrew Lunn <andrew@lunn.ch>
> >>>> Sent: Thursday, September 29, 2022 8:23 AM
> >> [...]
> >>>>
> >>>>> I actually did some compare testing regarding the page pool for
> >>>>> normal traffic.  So far I don't see significant improvement in the
> >>>>> current implementation. The performance for large packets improves
> >>>>> a little, and the performance for small packets get a little worse.
> >>>>
> >>>> What hardware was this for? imx51? imx6? imx7 Vybrid? These all use the
> FEC.
> >>>
> >>> I tested on imx8qxp platform. It is ARM64.
> >>
> >> On mvneta driver/platform we saw huge speedup replacing:
> >>
> >>     page_pool_release_page(rxq->page_pool, page); with
> >>     skb_mark_for_recycle(skb);
> >>
> >> As I mentioned: Today page_pool have SKB recycle support (you might
> >> have looked at drivers that didn't utilize this yet), thus you don't
> >> need to release the page (page_pool_release_page) here.  Instead you
> >> could simply mark the SKB for recycling, unless driver does some page refcnt
> tricks I didn't notice.
> >>
> >> On the mvneta driver/platform the DMA unmap (in
> >> page_pool_release_page) was very expensive. This imx8qxp platform
> >> might have faster DMA unmap in case is it cache-coherent.
> >>
> >> I would be very interested in knowing if skb_mark_for_recycle() helps
> >> on this platform, for normal network stack performance.
> >>
> >
> > Did a quick compare testing for the following 3 scenarios:
> 
> Thanks for doing this! :-)
> 
> > 1. original implementation
> >
> > shenwei@5810:~$ iperf -c 10.81.16.245 -w 2m -i 1
> > ------------------------------------------------------------
> > Client connecting to 10.81.16.245, TCP port 5001 TCP window size:  416
> > KByte (WARNING: requested 1.91 MByte)
> > ------------------------------------------------------------
> > [  1] local 10.81.17.20 port 49154 connected with 10.81.16.245 port 5001
> > [ ID] Interval       Transfer     Bandwidth
> > [  1] 0.0000-1.0000 sec   104 MBytes   868 Mbits/sec
> > [  1] 1.0000-2.0000 sec   105 MBytes   878 Mbits/sec
> > [  1] 2.0000-3.0000 sec   105 MBytes   881 Mbits/sec
> > [  1] 3.0000-4.0000 sec   105 MBytes   879 Mbits/sec
> > [  1] 4.0000-5.0000 sec   105 MBytes   878 Mbits/sec
> > [  1] 5.0000-6.0000 sec   105 MBytes   878 Mbits/sec
> > [  1] 6.0000-7.0000 sec   104 MBytes   875 Mbits/sec
> > [  1] 7.0000-8.0000 sec   104 MBytes   875 Mbits/sec
> > [  1] 8.0000-9.0000 sec   104 MBytes   873 Mbits/sec
> > [  1] 9.0000-10.0000 sec   104 MBytes   875 Mbits/sec
> > [  1] 0.0000-10.0073 sec  1.02 GBytes   875 Mbits/sec
> >
> > 2. Page pool with page_pool_release_page
> >
> > shenwei@5810:~$ iperf -c 10.81.16.245 -w 2m -i 1
> > ------------------------------------------------------------
> > Client connecting to 10.81.16.245, TCP port 5001 TCP window size:  416
> > KByte (WARNING: requested 1.91 MByte)
> > ------------------------------------------------------------
> > [  1] local 10.81.17.20 port 35924 connected with 10.81.16.245 port 5001
> > [ ID] Interval       Transfer     Bandwidth
> > [  1] 0.0000-1.0000 sec   101 MBytes   849 Mbits/sec
> > [  1] 1.0000-2.0000 sec   102 MBytes   860 Mbits/sec
> > [  1] 2.0000-3.0000 sec   102 MBytes   860 Mbits/sec
> > [  1] 3.0000-4.0000 sec   102 MBytes   859 Mbits/sec
> > [  1] 4.0000-5.0000 sec   103 MBytes   863 Mbits/sec
> > [  1] 5.0000-6.0000 sec   103 MBytes   864 Mbits/sec
> > [  1] 6.0000-7.0000 sec   103 MBytes   863 Mbits/sec
> > [  1] 7.0000-8.0000 sec   103 MBytes   865 Mbits/sec
> > [  1] 8.0000-9.0000 sec   103 MBytes   862 Mbits/sec
> > [  1] 9.0000-10.0000 sec   102 MBytes   856 Mbits/sec
> > [  1] 0.0000-10.0246 sec  1.00 GBytes   858 Mbits/sec
> >
> >
> > 3. page pool with skb_mark_for_recycle
> >
> > shenwei@5810:~$ iperf -c 10.81.16.245 -w 2m -i 1
> > ------------------------------------------------------------
> > Client connecting to 10.81.16.245, TCP port 5001 TCP window size:  416
> > KByte (WARNING: requested 1.91 MByte)
> > ------------------------------------------------------------
> > [  1] local 10.81.17.20 port 42724 connected with 10.81.16.245 port 5001
> > [ ID] Interval       Transfer     Bandwidth
> > [  1] 0.0000-1.0000 sec   111 MBytes   931 Mbits/sec
> > [  1] 1.0000-2.0000 sec   112 MBytes   935 Mbits/sec
> > [  1] 2.0000-3.0000 sec   111 MBytes   934 Mbits/sec
> > [  1] 3.0000-4.0000 sec   111 MBytes   934 Mbits/sec
> > [  1] 4.0000-5.0000 sec   111 MBytes   934 Mbits/sec
> > [  1] 5.0000-6.0000 sec   112 MBytes   935 Mbits/sec
> > [  1] 6.0000-7.0000 sec   111 MBytes   934 Mbits/sec
> > [  1] 7.0000-8.0000 sec   111 MBytes   933 Mbits/sec
> > [  1] 8.0000-9.0000 sec   112 MBytes   935 Mbits/sec
> > [  1] 9.0000-10.0000 sec   111 MBytes   933 Mbits/sec
> > [  1] 0.0000-10.0069 sec  1.09 GBytes   934 Mbits/sec
> 
> This is a very significant performance improvement (page pool with
> skb_mark_for_recycle).  This is very close to the max goodput for a 1Gbit/s link.
> 
> 
> > For small packet size (64 bytes), all three cases have almost the same result:
> >
> 
> To me this indicate, that the DMA map/unmap operations on this platform are
> indeed more expensive on larger packets.  Given this is what page_pool does,
> keeping the DMA mapping intact when recycling.
> 
> Driver still need DMA-sync, although I notice you set page_pool feature flag
> PP_FLAG_DMA_SYNC_DEV, this is good as page_pool will try to reduce sync size
> where possible. E.g. in this SKB case will reduce the DMA-sync to the
> max_len=FEC_ENET_RX_FRSIZE which should also help on performance.
> 
> 
> > shenwei@5810:~$ iperf -c 10.81.16.245 -w 2m -i 1 -l 64
> > ------------------------------------------------------------
> > Client connecting to 10.81.16.245, TCP port 5001 TCP window size:  416
> > KByte (WARNING: requested 1.91 MByte)
> > ------------------------------------------------------------
> > [  1] local 10.81.17.20 port 58204 connected with 10.81.16.245 port 5001
> > [ ID] Interval       Transfer     Bandwidth
> > [  1] 0.0000-1.0000 sec  36.9 MBytes   309 Mbits/sec
> > [  1] 1.0000-2.0000 sec  36.6 MBytes   307 Mbits/sec
> > [  1] 2.0000-3.0000 sec  36.6 MBytes   307 Mbits/sec
> > [  1] 3.0000-4.0000 sec  36.5 MBytes   307 Mbits/sec
> > [  1] 4.0000-5.0000 sec  37.1 MBytes   311 Mbits/sec
> > [  1] 5.0000-6.0000 sec  37.2 MBytes   312 Mbits/sec
> > [  1] 6.0000-7.0000 sec  37.1 MBytes   311 Mbits/sec
> > [  1] 7.0000-8.0000 sec  37.1 MBytes   311 Mbits/sec
> > [  1] 8.0000-9.0000 sec  37.1 MBytes   312 Mbits/sec
> > [  1] 9.0000-10.0000 sec  37.2 MBytes   312 Mbits/sec
> > [  1] 0.0000-10.0097 sec   369 MBytes   310 Mbits/sec
> >
> > Regards,
> > Shenwei
> >
> >
> >>>> By small packets, do you mean those under the copybreak limit?
> >>>>
> >>>> Please provide some benchmark numbers with your next patchset.
> >>>
> >>> Yes, the packet size is 64 bytes and it is under the copybreak limit.
> >>> As the impact is not significant, I would prefer to remove the
> >>> copybreak  logic.
> >>
> >> +1 to removing this logic if possible, due to maintenance cost.
> >>
> >> --Jesper
> >


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [EXT] Re: [PATCH 1/1] net: fec: add initial XDP support
  2022-09-29 15:52           ` Shenwei Wang
@ 2022-09-29 18:55             ` Jesper Dangaard Brouer
  2022-10-03 12:49               ` Shenwei Wang
  0 siblings, 1 reply; 25+ messages in thread
From: Jesper Dangaard Brouer @ 2022-09-29 18:55 UTC (permalink / raw)
  To: Shenwei Wang, Jesper Dangaard Brouer, Andrew Lunn
  Cc: brouer, Joakim Zhang, David S. Miller, Eric Dumazet,
	Jakub Kicinski, Paolo Abeni, Alexei Starovoitov, Daniel Borkmann,
	Jesper Dangaard Brouer, John Fastabend, netdev, linux-kernel,
	imx



On 29/09/2022 17.52, Shenwei Wang wrote:
> 
>> From: Jesper Dangaard Brouer <jbrouer@redhat.com>
>>
>> On 29/09/2022 15.26, Shenwei Wang wrote:
>>>
>>>> From: Andrew Lunn <andrew@lunn.ch>
>>>> Sent: Thursday, September 29, 2022 8:23 AM
>> [...]
>>>>
>>>>> I actually did some compare testing regarding the page pool for
>>>>> normal traffic.  So far I don't see significant improvement in the
>>>>> current implementation. The performance for large packets improves a
>>>>> little, and the performance for small packets get a little worse.
>>>>
>>>> What hardware was this for? imx51? imx6? imx7 Vybrid? These all use the FEC.
>>>
>>> I tested on imx8qxp platform. It is ARM64.
>>
>> On mvneta driver/platform we saw huge speedup replacing:
>>
>>     page_pool_release_page(rxq->page_pool, page); with
>>     skb_mark_for_recycle(skb);
>>
>> As I mentioned: Today page_pool have SKB recycle support (you might have
>> looked at drivers that didn't utilize this yet), thus you don't need to release the
>> page (page_pool_release_page) here.  Instead you could simply mark the SKB
>> for recycling, unless driver does some page refcnt tricks I didn't notice.
>>
>> On the mvneta driver/platform the DMA unmap (in page_pool_release_page)
>> was very expensive. This imx8qxp platform might have faster DMA unmap in
>> case is it cache-coherent.
>>
>> I would be very interested in knowing if skb_mark_for_recycle() helps on this
>> platform, for normal network stack performance.
>>
> 
> Did a quick compare testing for the following 3 scenarios:

Thanks for doing this! :-)

> 1. original implementation
> 
> shenwei@5810:~$ iperf -c 10.81.16.245 -w 2m -i 1
> ------------------------------------------------------------
> Client connecting to 10.81.16.245, TCP port 5001
> TCP window size:  416 KByte (WARNING: requested 1.91 MByte)
> ------------------------------------------------------------
> [  1] local 10.81.17.20 port 49154 connected with 10.81.16.245 port 5001
> [ ID] Interval       Transfer     Bandwidth
> [  1] 0.0000-1.0000 sec   104 MBytes   868 Mbits/sec
> [  1] 1.0000-2.0000 sec   105 MBytes   878 Mbits/sec
> [  1] 2.0000-3.0000 sec   105 MBytes   881 Mbits/sec
> [  1] 3.0000-4.0000 sec   105 MBytes   879 Mbits/sec
> [  1] 4.0000-5.0000 sec   105 MBytes   878 Mbits/sec
> [  1] 5.0000-6.0000 sec   105 MBytes   878 Mbits/sec
> [  1] 6.0000-7.0000 sec   104 MBytes   875 Mbits/sec
> [  1] 7.0000-8.0000 sec   104 MBytes   875 Mbits/sec
> [  1] 8.0000-9.0000 sec   104 MBytes   873 Mbits/sec
> [  1] 9.0000-10.0000 sec   104 MBytes   875 Mbits/sec
> [  1] 0.0000-10.0073 sec  1.02 GBytes   875 Mbits/sec
> 
> 2. Page pool with page_pool_release_page
> 
> shenwei@5810:~$ iperf -c 10.81.16.245 -w 2m -i 1
> ------------------------------------------------------------
> Client connecting to 10.81.16.245, TCP port 5001
> TCP window size:  416 KByte (WARNING: requested 1.91 MByte)
> ------------------------------------------------------------
> [  1] local 10.81.17.20 port 35924 connected with 10.81.16.245 port 5001
> [ ID] Interval       Transfer     Bandwidth
> [  1] 0.0000-1.0000 sec   101 MBytes   849 Mbits/sec
> [  1] 1.0000-2.0000 sec   102 MBytes   860 Mbits/sec
> [  1] 2.0000-3.0000 sec   102 MBytes   860 Mbits/sec
> [  1] 3.0000-4.0000 sec   102 MBytes   859 Mbits/sec
> [  1] 4.0000-5.0000 sec   103 MBytes   863 Mbits/sec
> [  1] 5.0000-6.0000 sec   103 MBytes   864 Mbits/sec
> [  1] 6.0000-7.0000 sec   103 MBytes   863 Mbits/sec
> [  1] 7.0000-8.0000 sec   103 MBytes   865 Mbits/sec
> [  1] 8.0000-9.0000 sec   103 MBytes   862 Mbits/sec
> [  1] 9.0000-10.0000 sec   102 MBytes   856 Mbits/sec
> [  1] 0.0000-10.0246 sec  1.00 GBytes   858 Mbits/sec
> 
> 
> 3. page pool with skb_mark_for_recycle
> 
> shenwei@5810:~$ iperf -c 10.81.16.245 -w 2m -i 1
> ------------------------------------------------------------
> Client connecting to 10.81.16.245, TCP port 5001
> TCP window size:  416 KByte (WARNING: requested 1.91 MByte)
> ------------------------------------------------------------
> [  1] local 10.81.17.20 port 42724 connected with 10.81.16.245 port 5001
> [ ID] Interval       Transfer     Bandwidth
> [  1] 0.0000-1.0000 sec   111 MBytes   931 Mbits/sec
> [  1] 1.0000-2.0000 sec   112 MBytes   935 Mbits/sec
> [  1] 2.0000-3.0000 sec   111 MBytes   934 Mbits/sec
> [  1] 3.0000-4.0000 sec   111 MBytes   934 Mbits/sec
> [  1] 4.0000-5.0000 sec   111 MBytes   934 Mbits/sec
> [  1] 5.0000-6.0000 sec   112 MBytes   935 Mbits/sec
> [  1] 6.0000-7.0000 sec   111 MBytes   934 Mbits/sec
> [  1] 7.0000-8.0000 sec   111 MBytes   933 Mbits/sec
> [  1] 8.0000-9.0000 sec   112 MBytes   935 Mbits/sec
> [  1] 9.0000-10.0000 sec   111 MBytes   933 Mbits/sec
> [  1] 0.0000-10.0069 sec  1.09 GBytes   934 Mbits/sec

This is a very significant performance improvement (page pool with
skb_mark_for_recycle).  This is very close to the max goodput for a
1Gbit/s link.


> For small packet size (64 bytes), all three cases have almost the same result:
> 

To me this indicate, that the DMA map/unmap operations on this platform
are indeed more expensive on larger packets.  Given this is what
page_pool does, keeping the DMA mapping intact when recycling.

Driver still need DMA-sync, although I notice you set page_pool feature
flag PP_FLAG_DMA_SYNC_DEV, this is good as page_pool will try to reduce
sync size where possible. E.g. in this SKB case will reduce the DMA-sync
to the max_len=FEC_ENET_RX_FRSIZE which should also help on performance.


> shenwei@5810:~$ iperf -c 10.81.16.245 -w 2m -i 1 -l 64
> ------------------------------------------------------------
> Client connecting to 10.81.16.245, TCP port 5001
> TCP window size:  416 KByte (WARNING: requested 1.91 MByte)
> ------------------------------------------------------------
> [  1] local 10.81.17.20 port 58204 connected with 10.81.16.245 port 5001
> [ ID] Interval       Transfer     Bandwidth
> [  1] 0.0000-1.0000 sec  36.9 MBytes   309 Mbits/sec
> [  1] 1.0000-2.0000 sec  36.6 MBytes   307 Mbits/sec
> [  1] 2.0000-3.0000 sec  36.6 MBytes   307 Mbits/sec
> [  1] 3.0000-4.0000 sec  36.5 MBytes   307 Mbits/sec
> [  1] 4.0000-5.0000 sec  37.1 MBytes   311 Mbits/sec
> [  1] 5.0000-6.0000 sec  37.2 MBytes   312 Mbits/sec
> [  1] 6.0000-7.0000 sec  37.1 MBytes   311 Mbits/sec
> [  1] 7.0000-8.0000 sec  37.1 MBytes   311 Mbits/sec
> [  1] 8.0000-9.0000 sec  37.1 MBytes   312 Mbits/sec
> [  1] 9.0000-10.0000 sec  37.2 MBytes   312 Mbits/sec
> [  1] 0.0000-10.0097 sec   369 MBytes   310 Mbits/sec
> 
> Regards,
> Shenwei
> 
> 
>>>> By small packets, do you mean those under the copybreak limit?
>>>>
>>>> Please provide some benchmark numbers with your next patchset.
>>>
>>> Yes, the packet size is 64 bytes and it is under the copybreak limit.
>>> As the impact is not significant, I would prefer to remove the
>>> copybreak  logic.
>>
>> +1 to removing this logic if possible, due to maintenance cost.
>>
>> --Jesper
> 


^ permalink raw reply	[flat|nested] 25+ messages in thread

* RE: [EXT] Re: [PATCH 1/1] net: fec: add initial XDP support
  2022-09-29 15:28         ` Jesper Dangaard Brouer
  2022-09-29 15:39           ` Andrew Lunn
@ 2022-09-29 15:52           ` Shenwei Wang
  2022-09-29 18:55             ` Jesper Dangaard Brouer
  1 sibling, 1 reply; 25+ messages in thread
From: Shenwei Wang @ 2022-09-29 15:52 UTC (permalink / raw)
  To: Jesper Dangaard Brouer, Andrew Lunn
  Cc: brouer, Joakim Zhang, David S. Miller, Eric Dumazet,
	Jakub Kicinski, Paolo Abeni, Alexei Starovoitov, Daniel Borkmann,
	Jesper Dangaard Brouer, John Fastabend, netdev, linux-kernel,
	imx



> -----Original Message-----
> From: Jesper Dangaard Brouer <jbrouer@redhat.com>
> Sent: Thursday, September 29, 2022 10:29 AM
> To: Shenwei Wang <shenwei.wang@nxp.com>; Andrew Lunn <andrew@lunn.ch>
> Cc: brouer@redhat.com; Joakim Zhang <qiangqing.zhang@nxp.com>; David S.
> Miller <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>; Jakub
> Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; Alexei
> Starovoitov <ast@kernel.org>; Daniel Borkmann <daniel@iogearbox.net>;
> Jesper Dangaard Brouer <hawk@kernel.org>; John Fastabend
> <john.fastabend@gmail.com>; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; imx@lists.linux.dev
> Subject: Re: [EXT] Re: [PATCH 1/1] net: fec: add initial XDP support
> 
> Caution: EXT Email
> 
> On 29/09/2022 15.26, Shenwei Wang wrote:
> >
> >> From: Andrew Lunn <andrew@lunn.ch>
> >> Sent: Thursday, September 29, 2022 8:23 AM
> [...]
> >>
> >>> I actually did some compare testing regarding the page pool for
> >>> normal traffic.  So far I don't see significant improvement in the
> >>> current implementation. The performance for large packets improves a
> >>> little, and the performance for small packets get a little worse.
> >>
> >> What hardware was this for? imx51? imx6? imx7 Vybrid? These all use the
> FEC.
> >
> > I tested on imx8qxp platform. It is ARM64.
> 
> On mvneta driver/platform we saw huge speedup replacing:
> 
>    page_pool_release_page(rxq->page_pool, page); with
>    skb_mark_for_recycle(skb);
> 
> As I mentioned: Today page_pool have SKB recycle support (you might have
> looked at drivers that didn't utilize this yet), thus you don't need to release the
> page (page_pool_release_page) here.  Instead you could simply mark the SKB
> for recycling, unless driver does some page refcnt tricks I didn't notice.
> 
> On the mvneta driver/platform the DMA unmap (in page_pool_release_page)
> was very expensive. This imx8qxp platform might have faster DMA unmap in
> case is it cache-coherent.
> 
> I would be very interested in knowing if skb_mark_for_recycle() helps on this
> platform, for normal network stack performance.
> 

Did a quick compare testing for the following 3 scenarios: 
1. original implementation 

shenwei@5810:~$ iperf -c 10.81.16.245 -w 2m -i 1
------------------------------------------------------------
Client connecting to 10.81.16.245, TCP port 5001
TCP window size:  416 KByte (WARNING: requested 1.91 MByte)
------------------------------------------------------------
[  1] local 10.81.17.20 port 49154 connected with 10.81.16.245 port 5001
[ ID] Interval       Transfer     Bandwidth
[  1] 0.0000-1.0000 sec   104 MBytes   868 Mbits/sec
[  1] 1.0000-2.0000 sec   105 MBytes   878 Mbits/sec
[  1] 2.0000-3.0000 sec   105 MBytes   881 Mbits/sec
[  1] 3.0000-4.0000 sec   105 MBytes   879 Mbits/sec
[  1] 4.0000-5.0000 sec   105 MBytes   878 Mbits/sec
[  1] 5.0000-6.0000 sec   105 MBytes   878 Mbits/sec
[  1] 6.0000-7.0000 sec   104 MBytes   875 Mbits/sec
[  1] 7.0000-8.0000 sec   104 MBytes   875 Mbits/sec
[  1] 8.0000-9.0000 sec   104 MBytes   873 Mbits/sec
[  1] 9.0000-10.0000 sec   104 MBytes   875 Mbits/sec
[  1] 0.0000-10.0073 sec  1.02 GBytes   875 Mbits/sec

2. Page pool with page_pool_release_page

shenwei@5810:~$ iperf -c 10.81.16.245 -w 2m -i 1
------------------------------------------------------------
Client connecting to 10.81.16.245, TCP port 5001
TCP window size:  416 KByte (WARNING: requested 1.91 MByte)
------------------------------------------------------------
[  1] local 10.81.17.20 port 35924 connected with 10.81.16.245 port 5001
[ ID] Interval       Transfer     Bandwidth
[  1] 0.0000-1.0000 sec   101 MBytes   849 Mbits/sec
[  1] 1.0000-2.0000 sec   102 MBytes   860 Mbits/sec
[  1] 2.0000-3.0000 sec   102 MBytes   860 Mbits/sec
[  1] 3.0000-4.0000 sec   102 MBytes   859 Mbits/sec
[  1] 4.0000-5.0000 sec   103 MBytes   863 Mbits/sec
[  1] 5.0000-6.0000 sec   103 MBytes   864 Mbits/sec
[  1] 6.0000-7.0000 sec   103 MBytes   863 Mbits/sec
[  1] 7.0000-8.0000 sec   103 MBytes   865 Mbits/sec
[  1] 8.0000-9.0000 sec   103 MBytes   862 Mbits/sec
[  1] 9.0000-10.0000 sec   102 MBytes   856 Mbits/sec
[  1] 0.0000-10.0246 sec  1.00 GBytes   858 Mbits/sec


3. page pool with skb_mark_for_recycle

shenwei@5810:~$ iperf -c 10.81.16.245 -w 2m -i 1
------------------------------------------------------------
Client connecting to 10.81.16.245, TCP port 5001
TCP window size:  416 KByte (WARNING: requested 1.91 MByte)
------------------------------------------------------------
[  1] local 10.81.17.20 port 42724 connected with 10.81.16.245 port 5001
[ ID] Interval       Transfer     Bandwidth
[  1] 0.0000-1.0000 sec   111 MBytes   931 Mbits/sec
[  1] 1.0000-2.0000 sec   112 MBytes   935 Mbits/sec
[  1] 2.0000-3.0000 sec   111 MBytes   934 Mbits/sec
[  1] 3.0000-4.0000 sec   111 MBytes   934 Mbits/sec
[  1] 4.0000-5.0000 sec   111 MBytes   934 Mbits/sec
[  1] 5.0000-6.0000 sec   112 MBytes   935 Mbits/sec
[  1] 6.0000-7.0000 sec   111 MBytes   934 Mbits/sec
[  1] 7.0000-8.0000 sec   111 MBytes   933 Mbits/sec
[  1] 8.0000-9.0000 sec   112 MBytes   935 Mbits/sec
[  1] 9.0000-10.0000 sec   111 MBytes   933 Mbits/sec
[  1] 0.0000-10.0069 sec  1.09 GBytes   934 Mbits/sec

For small packet size (64 bytes), all three cases have almost the same result:

shenwei@5810:~$ iperf -c 10.81.16.245 -w 2m -i 1 -l 64
------------------------------------------------------------
Client connecting to 10.81.16.245, TCP port 5001
TCP window size:  416 KByte (WARNING: requested 1.91 MByte)
------------------------------------------------------------
[  1] local 10.81.17.20 port 58204 connected with 10.81.16.245 port 5001
[ ID] Interval       Transfer     Bandwidth
[  1] 0.0000-1.0000 sec  36.9 MBytes   309 Mbits/sec
[  1] 1.0000-2.0000 sec  36.6 MBytes   307 Mbits/sec
[  1] 2.0000-3.0000 sec  36.6 MBytes   307 Mbits/sec
[  1] 3.0000-4.0000 sec  36.5 MBytes   307 Mbits/sec
[  1] 4.0000-5.0000 sec  37.1 MBytes   311 Mbits/sec
[  1] 5.0000-6.0000 sec  37.2 MBytes   312 Mbits/sec
[  1] 6.0000-7.0000 sec  37.1 MBytes   311 Mbits/sec
[  1] 7.0000-8.0000 sec  37.1 MBytes   311 Mbits/sec
[  1] 8.0000-9.0000 sec  37.1 MBytes   312 Mbits/sec
[  1] 9.0000-10.0000 sec  37.2 MBytes   312 Mbits/sec
[  1] 0.0000-10.0097 sec   369 MBytes   310 Mbits/sec

Regards,
Shenwei


> >> By small packets, do you mean those under the copybreak limit?
> >>
> >> Please provide some benchmark numbers with your next patchset.
> >
> > Yes, the packet size is 64 bytes and it is under the copybreak limit.
> > As the impact is not significant, I would prefer to remove the
> > copybreak  logic.
> 
> +1 to removing this logic if possible, due to maintenance cost.
> 
> --Jesper


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [EXT] Re: [PATCH 1/1] net: fec: add initial XDP support
  2022-09-29 13:11   ` [EXT] " Shenwei Wang
@ 2022-09-29 15:44     ` Jesper Dangaard Brouer
  0 siblings, 0 replies; 25+ messages in thread
From: Jesper Dangaard Brouer @ 2022-09-29 15:44 UTC (permalink / raw)
  To: Shenwei Wang, Jesper Dangaard Brouer, Joakim Zhang,
	David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni
  Cc: brouer, Alexei Starovoitov, Daniel Borkmann,
	Jesper Dangaard Brouer, John Fastabend, netdev, linux-kernel,
	imx



On 29/09/2022 15.11, Shenwei Wang wrote:
> 
>> From: Jesper Dangaard Brouer <jbrouer@redhat.com>
 >>
>>> diff --git a/drivers/net/ethernet/freescale/fec.h
>>> b/drivers/net/ethernet/freescale/fec.h
>>> index b0100fe3c9e4..f7531503aa95 100644
>>> --- a/drivers/net/ethernet/freescale/fec.h
>>> +++ b/drivers/net/ethernet/freescale/fec.h
>>> @@ -346,8 +346,10 @@ struct bufdesc_ex {
>>>     * the skbuffer directly.
>>>     */
>>>
>>> +#define FEC_ENET_XDP_HEADROOM        (512) /* XDP_PACKET_HEADROOM
>> + NET_IP_ALIGN) */
>>
>> Why the large headroom?
>>
> 
> The accurate value here should be "XDP_PACKET_HEADROOM (256) +
> NET_IP_ALIGN" which then aligns with 64 bytes. So 256 + 64 should be
> enough here.
> 

Most other XDP drivers have 256 bytes headroom.
I don't understand why you just don't keep this at 256, like other drivers ?

>>> +
>>>    #define FEC_ENET_RX_PAGES   256
>>> -#define FEC_ENET_RX_FRSIZE   2048
>>> +#define FEC_ENET_RX_FRSIZE   (PAGE_SIZE - FEC_ENET_XDP_HEADROOM)
>>
>> This FEC_ENET_RX_FRSIZE is likely wrong, because you also need to reserve 320
>> bytes at the end for struct skb_shared_info.
>> (320 calculated as SKB_DATA_ALIGN(sizeof(struct skb_shared_info)))
>>
>>>    #define FEC_ENET_RX_FRPPG   (PAGE_SIZE / FEC_ENET_RX_FRSIZE)
>>>    #define RX_RING_SIZE                (FEC_ENET_RX_FRPPG *
>> FEC_ENET_RX_PAGES)
>>>    #define FEC_ENET_TX_FRSIZE  2048
>>> @@ -517,6 +519,22 @@ struct bufdesc_prop {
>> [...]
>>
>>> diff --git a/drivers/net/ethernet/freescale/fec_main.c
>>> b/drivers/net/ethernet/freescale/fec_main.c
>>> index 59921218a8a4..2e30182ed770 100644
>>> --- a/drivers/net/ethernet/freescale/fec_main.c
>>> +++ b/drivers/net/ethernet/freescale/fec_main.c
>>> @@ -66,6 +66,8 @@
>>>    #include <linux/mfd/syscon.h>
>>>    #include <linux/regmap.h>
>>>    #include <soc/imx/cpuidle.h>
>>> +#include <linux/filter.h>
>>> +#include <linux/bpf.h>
>>>
>>>    #include <asm/cacheflush.h>
>>>
>>> @@ -87,6 +89,11 @@ static const u16 fec_enet_vlan_pri_to_queue[8] = {0, 0,
>> 1, 1, 1, 2, 2, 2};
>>>    #define FEC_ENET_OPD_V      0xFFF0
>>>    #define FEC_MDIO_PM_TIMEOUT  100 /* ms */
>>>
>>> +#define FEC_ENET_XDP_PASS          0
>>> +#define FEC_ENET_XDP_CONSUMED      BIT(0)
>>> +#define FEC_ENET_XDP_TX            BIT(1)
>>> +#define FEC_ENET_XDP_REDIR         BIT(2)
>>> +
>>>    struct fec_devinfo {
>>>        u32 quirks;
>>>    };
>>> @@ -422,6 +429,49 @@ fec_enet_clear_csum(struct sk_buff *skb, struct
>> net_device *ndev)
>>>        return 0;
>>>    }
>>>
>>> +static int
>>> +fec_enet_create_page_pool(struct fec_enet_private *fep,
>>> +                       struct fec_enet_priv_rx_q *rxq, int size) {
>>> +     struct bpf_prog *xdp_prog = READ_ONCE(fep->xdp_prog);
>>> +     struct page_pool_params pp_params = {
>>> +             .order = 0,
>>> +             .flags = PP_FLAG_DMA_MAP | PP_FLAG_DMA_SYNC_DEV,
>>> +             .pool_size = size,
>>> +             .nid = dev_to_node(&fep->pdev->dev),
>>> +             .dev = &fep->pdev->dev,
>>> +             .dma_dir = xdp_prog ? DMA_BIDIRECTIONAL : DMA_FROM_DEVICE,
>>> +             .offset = FEC_ENET_XDP_HEADROOM,
>>> +             .max_len = FEC_ENET_RX_FRSIZE,
>>
>> XDP BPF-prog cannot access last 320 bytes, so FEC_ENET_RX_FRSIZE is wrong
>> here.
>>
> 
> So the FEC_ENET_RX_FRSIZE should subtract the sizeof(struct
> skb_shared_info) in the definition, right?
> 

Yes correct, but use:
   SKB_DATA_ALIGN(sizeof(struct skb_shared_info))


>>> +     };
>>> +     int err;
>>> +
>>> +     rxq->page_pool = page_pool_create(&pp_params);
>>> +     if (IS_ERR(rxq->page_pool)) {
>>> +             err = PTR_ERR(rxq->page_pool);
>>> +             rxq->page_pool = NULL;
>>> +             return err;
>>> +     }
>>> +
>>> +     err = xdp_rxq_info_reg(&rxq->xdp_rxq, fep->netdev, rxq->id, 0);
>>> +     if (err < 0)
>>> +             goto err_free_pp;
>>> +
>>> +     err = xdp_rxq_info_reg_mem_model(&rxq->xdp_rxq, MEM_TYPE_PAGE_POOL,
>>> +                                      rxq->page_pool);
>>> +     if (err)
>>> +             goto err_unregister_rxq;
>>> +
>>> +     return 0;
>>> +
>>> +err_unregister_rxq:
>>> +     xdp_rxq_info_unreg(&rxq->xdp_rxq);
>>> +err_free_pp:
>>> +     page_pool_destroy(rxq->page_pool);
>>> +     rxq->page_pool = NULL;
>>> +     return err;
>>> +}
>>> +
>>>    static struct bufdesc *
>>>    fec_enet_txq_submit_frag_skb(struct fec_enet_priv_tx_q *txq,
>>>                             struct sk_buff *skb, @@ -1285,7 +1335,6 @@
>>> fec_stop(struct net_device *ndev)
>>>        }
>>>    }
>>>
>>> -
>>>    static void
>>>    fec_timeout(struct net_device *ndev, unsigned int txqueue)
>>>    {
>>> @@ -1450,7 +1499,7 @@ static void fec_enet_tx(struct net_device *ndev)
>>>                fec_enet_tx_queue(ndev, i);
>>>    }
>>>
>>> -static int
>>> +static int __maybe_unused
>>>    fec_enet_new_rxbdp(struct net_device *ndev, struct bufdesc *bdp, struct sk_buff *skb)
>>>    {
>>>        struct  fec_enet_private *fep = netdev_priv(ndev); @@ -1470,8
>>> +1519,9 @@ fec_enet_new_rxbdp(struct net_device *ndev, struct bufdesc
>> *bdp, struct sk_buff
>>>        return 0;
>>>    }
>>>
>>> -static bool fec_enet_copybreak(struct net_device *ndev, struct sk_buff **skb,
>>> -                            struct bufdesc *bdp, u32 length, bool swap)
>>> +static bool __maybe_unused
>>> +fec_enet_copybreak(struct net_device *ndev, struct sk_buff **skb,
>>> +                struct bufdesc *bdp, u32 length, bool swap)
>>>    {
>>>        struct  fec_enet_private *fep = netdev_priv(ndev);
>>>        struct sk_buff *new_skb;
>>> @@ -1496,6 +1546,78 @@ static bool fec_enet_copybreak(struct net_device *ndev, struct sk_buff **skb,
>>>        return true;
>>>    }
>>>
>>> +static void fec_enet_update_cbd(struct fec_enet_priv_rx_q *rxq,
>>> +                             struct bufdesc *bdp, int index) {
>>> +     struct page *new_page;
>>> +     dma_addr_t phys_addr;
>>> +
>>> +     new_page = page_pool_dev_alloc_pages(rxq->page_pool);
>>> +     WARN_ON(!new_page);
>>> +     rxq->rx_skb_info[index].page = new_page;
>>> +
>>> +     rxq->rx_skb_info[index].offset = FEC_ENET_XDP_HEADROOM;
>>> +     phys_addr = page_pool_get_dma_addr(new_page) + FEC_ENET_XDP_HEADROOM;
>>> +     bdp->cbd_bufaddr = cpu_to_fec32(phys_addr); }
>>> +
>>> +static u32
>>> +fec_enet_run_xdp(struct fec_enet_private *fep, struct bpf_prog *prog,
>>> +              struct xdp_buff *xdp, struct fec_enet_priv_rx_q *rxq,
>>> +int index) {
>>> +     unsigned int sync, len = xdp->data_end - xdp->data;
>>> +     u32 ret = FEC_ENET_XDP_PASS;
>>> +     struct page *page;
>>> +     int err;
>>> +     u32 act;
>>> +
>>> +     act = bpf_prog_run_xdp(prog, xdp);
>>> +
>>> +     /* Due xdp_adjust_tail: DMA sync for_device cover max len CPU touch */
>>> +     sync = xdp->data_end - xdp->data_hard_start - FEC_ENET_XDP_HEADROOM;
>>> +     sync = max(sync, len);
>>> +
>>> +     switch (act) {
>>> +     case XDP_PASS:
>>> +             rxq->stats.xdp_pass++;
>>> +             ret = FEC_ENET_XDP_PASS;
>>> +             break;
>>> +
>>> +     case XDP_TX:
>>> +             rxq->stats.xdp_tx++;
>>> +             bpf_warn_invalid_xdp_action(fep->netdev, prog, act);
>>> +             fallthrough;
>>
>> This fallthrough looks wrong. The next xdp_do_redirect() call will pickup left-
>> overs in per CPU bpf_redirect_info.
>>
> 
> So before the XDP_TX is implemented, this part of codes should reside below the XDP_REDIRECT case?
> 

If that fallthrough goes to dropping packet, then yes.

>>> +
>>> +     case XDP_REDIRECT:
>>> +             err = xdp_do_redirect(fep->netdev, xdp, prog);
>>> +             rxq->stats.xdp_redirect++;
>>> -                     dma_unmap_single(&fep->pdev->dev,
> ...
> 
>>> -                                      fec32_to_cpu(bdp->cbd_bufaddr),
>>> -                                      FEC_ENET_RX_FRSIZE - fep->rx_align,
>>> -                                      DMA_FROM_DEVICE);
>>> -             }
>>> -
>>> -             prefetch(skb->data - NET_IP_ALIGN);
>>> +             skb = build_skb(page_address(page), FEC_ENET_RX_FRSIZE);
>>
>> This looks wrong, I think FEC_ENET_RX_FRSIZE should be replaced by PAGE_SIZE.
>> As build_skb() does:
>>
>>    size -= SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
>>
> 
> Agree. As the current FRSIZE definition did not subtract the sizeof(struct skb_shared_info), I happened to not see the problem during the testing.
> 

As I wrote use PAGE_SIZE here.


>>> +             skb_reserve(skb, FEC_ENET_XDP_HEADROOM);
>>
>> The skb_reserve looks correct.
>>
>>>                skb_put(skb, pkt_len - 4);
>>>                data = skb->data;
>>> +             page_pool_release_page(rxq->page_pool, page);
>>
>> Today page_pool have SKB recycle support (you might have looked at drivers
>> that didn't utilize this yet), thus you don't need to release the page
>> (page_pool_release_page) here.  Instead you could simply mark the SKB for
>> recycling, unless driver does some page refcnt tricks I didn't notice.
>>
>>    skb_mark_for_recycle(skb);

I hope you try out the above proposed change.

>>
>>> -             if (!is_copybreak && need_swap)
>>> +             if (need_swap)
>>>                        swap_buffer(data, pkt_len);
>>>
>>>    #if !defined(CONFIG_M5272)
>>> @@ -1649,16 +1781,6 @@ fec_enet_rx_queue(struct net_device *ndev, int
>>> budget, u16 queue_id)
>> [...]
> 


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [EXT] Re: [PATCH 1/1] net: fec: add initial XDP support
  2022-09-29 15:28         ` Jesper Dangaard Brouer
@ 2022-09-29 15:39           ` Andrew Lunn
  2022-09-29 15:52           ` Shenwei Wang
  1 sibling, 0 replies; 25+ messages in thread
From: Andrew Lunn @ 2022-09-29 15:39 UTC (permalink / raw)
  To: Jesper Dangaard Brouer
  Cc: Shenwei Wang, brouer, Joakim Zhang, David S. Miller,
	Eric Dumazet, Jakub Kicinski, Paolo Abeni, Alexei Starovoitov,
	Daniel Borkmann, Jesper Dangaard Brouer, John Fastabend, netdev,
	linux-kernel, imx

On Thu, Sep 29, 2022 at 05:28:43PM +0200, Jesper Dangaard Brouer wrote:
> 
> 
> On 29/09/2022 15.26, Shenwei Wang wrote:
> > 
> > > From: Andrew Lunn <andrew@lunn.ch>
> > > Sent: Thursday, September 29, 2022 8:23 AM
> [...]
> > > 
> > > > I actually did some compare testing regarding the page pool for normal
> > > > traffic.  So far I don't see significant improvement in the current
> > > > implementation. The performance for large packets improves a little,
> > > > and the performance for small packets get a little worse.
> > > 
> > > What hardware was this for? imx51? imx6? imx7 Vybrid? These all use the FEC.
> > 
> > I tested on imx8qxp platform. It is ARM64.
> 
> On mvneta driver/platform we saw huge speedup replacing:
> 
>   page_pool_release_page(rxq->page_pool, page);
> with
>   skb_mark_for_recycle(skb);
> 
> As I mentioned: Today page_pool have SKB recycle support (you might have
> looked at drivers that didn't utilize this yet), thus you don't need to
> release the page (page_pool_release_page) here.  Instead you could simply
> mark the SKB for recycling, unless driver does some page refcnt tricks I
> didn't notice.
> 
> On the mvneta driver/platform the DMA unmap (in page_pool_release_page) was
> very expensive. This imx8qxp platform might have faster DMA unmap in case is
> it cache-coherent.

I don't know about imx8qxp, but i've played with imx6 and Vybrid, and
cache flush and invalidate are very expensive.

      Andrew


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [EXT] Re: [PATCH 1/1] net: fec: add initial XDP support
  2022-09-29 13:26       ` Shenwei Wang
  2022-09-29 15:19         ` Andrew Lunn
@ 2022-09-29 15:28         ` Jesper Dangaard Brouer
  2022-09-29 15:39           ` Andrew Lunn
  2022-09-29 15:52           ` Shenwei Wang
  1 sibling, 2 replies; 25+ messages in thread
From: Jesper Dangaard Brouer @ 2022-09-29 15:28 UTC (permalink / raw)
  To: Shenwei Wang, Andrew Lunn
  Cc: brouer, Joakim Zhang, David S. Miller, Eric Dumazet,
	Jakub Kicinski, Paolo Abeni, Alexei Starovoitov, Daniel Borkmann,
	Jesper Dangaard Brouer, John Fastabend, netdev, linux-kernel,
	imx



On 29/09/2022 15.26, Shenwei Wang wrote:
> 
>> From: Andrew Lunn <andrew@lunn.ch>
>> Sent: Thursday, September 29, 2022 8:23 AM
[...]
>>
>>> I actually did some compare testing regarding the page pool for normal
>>> traffic.  So far I don't see significant improvement in the current
>>> implementation. The performance for large packets improves a little,
>>> and the performance for small packets get a little worse.
>>
>> What hardware was this for? imx51? imx6? imx7 Vybrid? These all use the FEC.
> 
> I tested on imx8qxp platform. It is ARM64.

On mvneta driver/platform we saw huge speedup replacing:

   page_pool_release_page(rxq->page_pool, page);
with
   skb_mark_for_recycle(skb);

As I mentioned: Today page_pool have SKB recycle support (you might have 
looked at drivers that didn't utilize this yet), thus you don't need to 
release the page (page_pool_release_page) here.  Instead you could 
simply mark the SKB for recycling, unless driver does some page refcnt 
tricks I didn't notice.

On the mvneta driver/platform the DMA unmap (in page_pool_release_page) 
was very expensive. This imx8qxp platform might have faster DMA unmap in 
case is it cache-coherent.

I would be very interested in knowing if skb_mark_for_recycle() helps on 
this platform, for normal network stack performance.

>> By small packets, do you mean those under the copybreak limit?
>>
>> Please provide some benchmark numbers with your next patchset.
> 
> Yes, the packet size is 64 bytes and it is under the copybreak limit.
> As the impact is not significant, I would prefer to remove the
> copybreak  logic.

+1 to removing this logic if possible, due to maintenance cost.

--Jesper


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [EXT] Re: [PATCH 1/1] net: fec: add initial XDP support
  2022-09-29 13:26       ` Shenwei Wang
@ 2022-09-29 15:19         ` Andrew Lunn
  2022-09-29 15:28         ` Jesper Dangaard Brouer
  1 sibling, 0 replies; 25+ messages in thread
From: Andrew Lunn @ 2022-09-29 15:19 UTC (permalink / raw)
  To: Shenwei Wang
  Cc: Joakim Zhang, David S. Miller, Eric Dumazet, Jakub Kicinski,
	Paolo Abeni, Alexei Starovoitov, Daniel Borkmann,
	Jesper Dangaard Brouer, John Fastabend, netdev, linux-kernel,
	imx

> > > I actually did some compare testing regarding the page pool for normal
> > > traffic.  So far I don't see significant improvement in the current
> > > implementation. The performance for large packets improves a little,
> > > and the performance for small packets get a little worse.
> > 
> > What hardware was this for? imx51? imx6? imx7 Vybrid? These all use the FEC.
> 
> I tested on imx8qxp platform. It is ARM64.

Please also test the older platforms. imx8 is quite powerful, so some
performance loss does not matter too much. But for the older systems,
i know people has spent a lot of time and effort optimising network
performance, and they will be unhappy if you make it slower.

> > By small packets, do you mean those under the copybreak limit?
> > 
> > Please provide some benchmark numbers with your next patchset.
> 

> Yes, the packet size is 64 bytes and it is under the copybreak
> limit. As the impact is not significant, I would prefer to remove
> the copybreak logic.

Lets look at the benchmark numbers, what you actually mean by not
significant, and across a range of hardware.

	     Andrew

^ permalink raw reply	[flat|nested] 25+ messages in thread

* RE: [EXT] Re: [PATCH 1/1] net: fec: add initial XDP support
  2022-09-29 13:24     ` Andrew Lunn
@ 2022-09-29 13:35       ` Shenwei Wang
  0 siblings, 0 replies; 25+ messages in thread
From: Shenwei Wang @ 2022-09-29 13:35 UTC (permalink / raw)
  To: Andrew Lunn
  Cc: Joakim Zhang, David S. Miller, Eric Dumazet, Jakub Kicinski,
	Paolo Abeni, Alexei Starovoitov, Daniel Borkmann,
	Jesper Dangaard Brouer, John Fastabend, netdev, linux-kernel,
	imx



> -----Original Message-----
> From: Andrew Lunn <andrew@lunn.ch>
> Sent: Thursday, September 29, 2022 8:24 AM
> To: Shenwei Wang <shenwei.wang@nxp.com>
> Cc: Joakim Zhang <qiangqing.zhang@nxp.com>; David S. Miller
> <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>; Jakub
> Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; Alexei
> Starovoitov <ast@kernel.org>; Daniel Borkmann <daniel@iogearbox.net>;
> Jesper Dangaard Brouer <hawk@kernel.org>; John Fastabend
> <john.fastabend@gmail.com>; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; imx@lists.linux.dev
> Subject: Re: [EXT] Re: [PATCH 1/1] net: fec: add initial XDP support
> 
> Caution: EXT Email
> 
> > > > +struct fec_enet_xdp_stats {
> > > > +     u64     xdp_pass;
> > > > +     u64     xdp_drop;
> > > > +     u64     xdp_xmit;
> > > > +     u64     xdp_redirect;
> > > > +     u64     xdp_xmit_err;
> > > > +     u64     xdp_tx;
> > > > +     u64     xdp_tx_err;
> > > > +};
> > > > +
> > > > +     switch (act) {
> > > > +     case XDP_PASS:
> > > > +             rxq->stats.xdp_pass++;
> > >
> > > Since the stats are u64, and most machines using the FEC are 32 bit,
> > > you cannot just do an increment. Took a look at u64_stats_sync.h.
> > >
> >
> 
> > As this increment is only executed under the NAPI kthread context, is
> > the protection still required?
> 
> Are the statistics values read by ethtool under NAPI kthread context?
> 

You are right. The read is not under NAPI context.

Thanks,
Shenwei

>     Andrew

^ permalink raw reply	[flat|nested] 25+ messages in thread

* RE: [EXT] Re: [PATCH 1/1] net: fec: add initial XDP support
  2022-09-29 13:22     ` Andrew Lunn
@ 2022-09-29 13:26       ` Shenwei Wang
  2022-09-29 15:19         ` Andrew Lunn
  2022-09-29 15:28         ` Jesper Dangaard Brouer
  0 siblings, 2 replies; 25+ messages in thread
From: Shenwei Wang @ 2022-09-29 13:26 UTC (permalink / raw)
  To: Andrew Lunn
  Cc: Joakim Zhang, David S. Miller, Eric Dumazet, Jakub Kicinski,
	Paolo Abeni, Alexei Starovoitov, Daniel Borkmann,
	Jesper Dangaard Brouer, John Fastabend, netdev, linux-kernel,
	imx



> -----Original Message-----
> From: Andrew Lunn <andrew@lunn.ch>
> Sent: Thursday, September 29, 2022 8:23 AM
> To: Shenwei Wang <shenwei.wang@nxp.com>
> Cc: Joakim Zhang <qiangqing.zhang@nxp.com>; David S. Miller
> <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>; Jakub
> Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; Alexei
> Starovoitov <ast@kernel.org>; Daniel Borkmann <daniel@iogearbox.net>;
> Jesper Dangaard Brouer <hawk@kernel.org>; John Fastabend
> <john.fastabend@gmail.com>; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; imx@lists.linux.dev
> Subject: Re: [EXT] Re: [PATCH 1/1] net: fec: add initial XDP support
> 
> Caution: EXT Email
> 
> > I actually did some compare testing regarding the page pool for normal
> > traffic.  So far I don't see significant improvement in the current
> > implementation. The performance for large packets improves a little,
> > and the performance for small packets get a little worse.
> 
> What hardware was this for? imx51? imx6? imx7 Vybrid? These all use the FEC.

I tested on imx8qxp platform. It is ARM64.
 
> 
> By small packets, do you mean those under the copybreak limit?
> 
> Please provide some benchmark numbers with your next patchset.

Yes, the packet size is 64 bytes and it is under the copybreak limit. As the impact is not significant, I would prefer to remove the copybreak logic.

Thanks,
Shenwei

> 
>        Andrew

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [EXT] Re: [PATCH 1/1] net: fec: add initial XDP support
  2022-09-29 12:46   ` [EXT] " Shenwei Wang
@ 2022-09-29 13:24     ` Andrew Lunn
  2022-09-29 13:35       ` Shenwei Wang
  0 siblings, 1 reply; 25+ messages in thread
From: Andrew Lunn @ 2022-09-29 13:24 UTC (permalink / raw)
  To: Shenwei Wang
  Cc: Joakim Zhang, David S. Miller, Eric Dumazet, Jakub Kicinski,
	Paolo Abeni, Alexei Starovoitov, Daniel Borkmann,
	Jesper Dangaard Brouer, John Fastabend, netdev, linux-kernel,
	imx

> > > +struct fec_enet_xdp_stats {
> > > +     u64     xdp_pass;
> > > +     u64     xdp_drop;
> > > +     u64     xdp_xmit;
> > > +     u64     xdp_redirect;
> > > +     u64     xdp_xmit_err;
> > > +     u64     xdp_tx;
> > > +     u64     xdp_tx_err;
> > > +};
> > > +
> > > +     switch (act) {
> > > +     case XDP_PASS:
> > > +             rxq->stats.xdp_pass++;
> > 
> > Since the stats are u64, and most machines using the FEC are 32 bit, you cannot
> > just do an increment. Took a look at u64_stats_sync.h.
> > 
> 

> As this increment is only executed under the NAPI kthread context,
> is the protection still required?

Are the statistics values read by ethtool under NAPI kthread context?

    Andrew

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [EXT] Re: [PATCH 1/1] net: fec: add initial XDP support
  2022-09-29 12:40   ` [EXT] " Shenwei Wang
@ 2022-09-29 13:22     ` Andrew Lunn
  2022-09-29 13:26       ` Shenwei Wang
  0 siblings, 1 reply; 25+ messages in thread
From: Andrew Lunn @ 2022-09-29 13:22 UTC (permalink / raw)
  To: Shenwei Wang
  Cc: Joakim Zhang, David S. Miller, Eric Dumazet, Jakub Kicinski,
	Paolo Abeni, Alexei Starovoitov, Daniel Borkmann,
	Jesper Dangaard Brouer, John Fastabend, netdev, linux-kernel,
	imx

> I actually did some compare testing regarding the page pool for
> normal traffic.  So far I don't see significant improvement in the
> current implementation. The performance for large packets improves a
> little, and the performance for small packets get a little worse.

What hardware was this for? imx51? imx6? imx7 Vybrid? These all use
the FEC.

By small packets, do you mean those under the copybreak limit?

Please provide some benchmark numbers with your next patchset.

       Andrew

^ permalink raw reply	[flat|nested] 25+ messages in thread

* RE: [EXT] Re: [PATCH 1/1] net: fec: add initial XDP support
  2022-09-29 10:16 ` Jesper Dangaard Brouer
@ 2022-09-29 13:11   ` Shenwei Wang
  2022-09-29 15:44     ` Jesper Dangaard Brouer
  0 siblings, 1 reply; 25+ messages in thread
From: Shenwei Wang @ 2022-09-29 13:11 UTC (permalink / raw)
  To: Jesper Dangaard Brouer, Joakim Zhang, David S. Miller,
	Eric Dumazet, Jakub Kicinski, Paolo Abeni
  Cc: brouer, Alexei Starovoitov, Daniel Borkmann,
	Jesper Dangaard Brouer, John Fastabend, netdev, linux-kernel,
	imx



> -----Original Message-----
> From: Jesper Dangaard Brouer <jbrouer@redhat.com>
> Sent: Thursday, September 29, 2022 5:17 AM
> To: Shenwei Wang <shenwei.wang@nxp.com>; Joakim Zhang
> <qiangqing.zhang@nxp.com>; David S. Miller <davem@davemloft.net>; Eric
> Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo
> Abeni <pabeni@redhat.com>
> > diff --git a/drivers/net/ethernet/freescale/fec.h
> > b/drivers/net/ethernet/freescale/fec.h
> > index b0100fe3c9e4..f7531503aa95 100644
> > --- a/drivers/net/ethernet/freescale/fec.h
> > +++ b/drivers/net/ethernet/freescale/fec.h
> > @@ -346,8 +346,10 @@ struct bufdesc_ex {
> >    * the skbuffer directly.
> >    */
> >
> > +#define FEC_ENET_XDP_HEADROOM        (512) /* XDP_PACKET_HEADROOM
> + NET_IP_ALIGN) */
> 
> Why the large headroom?
> 

The accurate value here should be "XDP_PACKET_HEADROOM (256) + NET_IP_ALIGN" which then aligns with 64 bytes. So 256 + 64 should be enough here.
 
> > +
> >   #define FEC_ENET_RX_PAGES   256
> > -#define FEC_ENET_RX_FRSIZE   2048
> > +#define FEC_ENET_RX_FRSIZE   (PAGE_SIZE - FEC_ENET_XDP_HEADROOM)
> 
> This FEC_ENET_RX_FRSIZE is likely wrong, because you also need to reserve 320
> bytes at the end for struct skb_shared_info.
> (320 calculated as SKB_DATA_ALIGN(sizeof(struct skb_shared_info)))
> 
> >   #define FEC_ENET_RX_FRPPG   (PAGE_SIZE / FEC_ENET_RX_FRSIZE)
> >   #define RX_RING_SIZE                (FEC_ENET_RX_FRPPG *
> FEC_ENET_RX_PAGES)
> >   #define FEC_ENET_TX_FRSIZE  2048
> > @@ -517,6 +519,22 @@ struct bufdesc_prop {
> [...]
> 
> > diff --git a/drivers/net/ethernet/freescale/fec_main.c
> > b/drivers/net/ethernet/freescale/fec_main.c
> > index 59921218a8a4..2e30182ed770 100644
> > --- a/drivers/net/ethernet/freescale/fec_main.c
> > +++ b/drivers/net/ethernet/freescale/fec_main.c
> > @@ -66,6 +66,8 @@
> >   #include <linux/mfd/syscon.h>
> >   #include <linux/regmap.h>
> >   #include <soc/imx/cpuidle.h>
> > +#include <linux/filter.h>
> > +#include <linux/bpf.h>
> >
> >   #include <asm/cacheflush.h>
> >
> > @@ -87,6 +89,11 @@ static const u16 fec_enet_vlan_pri_to_queue[8] = {0, 0,
> 1, 1, 1, 2, 2, 2};
> >   #define FEC_ENET_OPD_V      0xFFF0
> >   #define FEC_MDIO_PM_TIMEOUT  100 /* ms */
> >
> > +#define FEC_ENET_XDP_PASS          0
> > +#define FEC_ENET_XDP_CONSUMED      BIT(0)
> > +#define FEC_ENET_XDP_TX            BIT(1)
> > +#define FEC_ENET_XDP_REDIR         BIT(2)
> > +
> >   struct fec_devinfo {
> >       u32 quirks;
> >   };
> > @@ -422,6 +429,49 @@ fec_enet_clear_csum(struct sk_buff *skb, struct
> net_device *ndev)
> >       return 0;
> >   }
> >
> > +static int
> > +fec_enet_create_page_pool(struct fec_enet_private *fep,
> > +                       struct fec_enet_priv_rx_q *rxq, int size) {
> > +     struct bpf_prog *xdp_prog = READ_ONCE(fep->xdp_prog);
> > +     struct page_pool_params pp_params = {
> > +             .order = 0,
> > +             .flags = PP_FLAG_DMA_MAP | PP_FLAG_DMA_SYNC_DEV,
> > +             .pool_size = size,
> > +             .nid = dev_to_node(&fep->pdev->dev),
> > +             .dev = &fep->pdev->dev,
> > +             .dma_dir = xdp_prog ? DMA_BIDIRECTIONAL : DMA_FROM_DEVICE,
> > +             .offset = FEC_ENET_XDP_HEADROOM,
> > +             .max_len = FEC_ENET_RX_FRSIZE,
> 
> XDP BPF-prog cannot access last 320 bytes, so FEC_ENET_RX_FRSIZE is wrong
> here.
> 

So the FEC_ENET_RX_FRSIZE should subtract the sizeof(struct skb_shared_info) in the definition, right? 

> > +     };
> > +     int err;
> > +
> > +     rxq->page_pool = page_pool_create(&pp_params);
> > +     if (IS_ERR(rxq->page_pool)) {
> > +             err = PTR_ERR(rxq->page_pool);
> > +             rxq->page_pool = NULL;
> > +             return err;
> > +     }
> > +
> > +     err = xdp_rxq_info_reg(&rxq->xdp_rxq, fep->netdev, rxq->id, 0);
> > +     if (err < 0)
> > +             goto err_free_pp;
> > +
> > +     err = xdp_rxq_info_reg_mem_model(&rxq->xdp_rxq,
> MEM_TYPE_PAGE_POOL,
> > +                                      rxq->page_pool);
> > +     if (err)
> > +             goto err_unregister_rxq;
> > +
> > +     return 0;
> > +
> > +err_unregister_rxq:
> > +     xdp_rxq_info_unreg(&rxq->xdp_rxq);
> > +err_free_pp:
> > +     page_pool_destroy(rxq->page_pool);
> > +     rxq->page_pool = NULL;
> > +     return err;
> > +}
> > +
> >   static struct bufdesc *
> >   fec_enet_txq_submit_frag_skb(struct fec_enet_priv_tx_q *txq,
> >                            struct sk_buff *skb, @@ -1285,7 +1335,6 @@
> > fec_stop(struct net_device *ndev)
> >       }
> >   }
> >
> > -
> >   static void
> >   fec_timeout(struct net_device *ndev, unsigned int txqueue)
> >   {
> > @@ -1450,7 +1499,7 @@ static void fec_enet_tx(struct net_device *ndev)
> >               fec_enet_tx_queue(ndev, i);
> >   }
> >
> > -static int
> > +static int __maybe_unused
> >   fec_enet_new_rxbdp(struct net_device *ndev, struct bufdesc *bdp, struct
> sk_buff *skb)
> >   {
> >       struct  fec_enet_private *fep = netdev_priv(ndev); @@ -1470,8
> > +1519,9 @@ fec_enet_new_rxbdp(struct net_device *ndev, struct bufdesc
> *bdp, struct sk_buff
> >       return 0;
> >   }
> >
> > -static bool fec_enet_copybreak(struct net_device *ndev, struct sk_buff **skb,
> > -                            struct bufdesc *bdp, u32 length, bool swap)
> > +static bool __maybe_unused
> > +fec_enet_copybreak(struct net_device *ndev, struct sk_buff **skb,
> > +                struct bufdesc *bdp, u32 length, bool swap)
> >   {
> >       struct  fec_enet_private *fep = netdev_priv(ndev);
> >       struct sk_buff *new_skb;
> > @@ -1496,6 +1546,78 @@ static bool fec_enet_copybreak(struct net_device
> *ndev, struct sk_buff **skb,
> >       return true;
> >   }
> >
> > +static void fec_enet_update_cbd(struct fec_enet_priv_rx_q *rxq,
> > +                             struct bufdesc *bdp, int index) {
> > +     struct page *new_page;
> > +     dma_addr_t phys_addr;
> > +
> > +     new_page = page_pool_dev_alloc_pages(rxq->page_pool);
> > +     WARN_ON(!new_page);
> > +     rxq->rx_skb_info[index].page = new_page;
> > +
> > +     rxq->rx_skb_info[index].offset = FEC_ENET_XDP_HEADROOM;
> > +     phys_addr = page_pool_get_dma_addr(new_page) +
> FEC_ENET_XDP_HEADROOM;
> > +     bdp->cbd_bufaddr = cpu_to_fec32(phys_addr); }
> > +
> > +static u32
> > +fec_enet_run_xdp(struct fec_enet_private *fep, struct bpf_prog *prog,
> > +              struct xdp_buff *xdp, struct fec_enet_priv_rx_q *rxq,
> > +int index) {
> > +     unsigned int sync, len = xdp->data_end - xdp->data;
> > +     u32 ret = FEC_ENET_XDP_PASS;
> > +     struct page *page;
> > +     int err;
> > +     u32 act;
> > +
> > +     act = bpf_prog_run_xdp(prog, xdp);
> > +
> > +     /* Due xdp_adjust_tail: DMA sync for_device cover max len CPU touch */
> > +     sync = xdp->data_end - xdp->data_hard_start -
> FEC_ENET_XDP_HEADROOM;
> > +     sync = max(sync, len);
> > +
> > +     switch (act) {
> > +     case XDP_PASS:
> > +             rxq->stats.xdp_pass++;
> > +             ret = FEC_ENET_XDP_PASS;
> > +             break;
> > +
> > +     case XDP_TX:
> > +             rxq->stats.xdp_tx++;
> > +             bpf_warn_invalid_xdp_action(fep->netdev, prog, act);
> > +             fallthrough;
> 
> This fallthrough looks wrong. The next xdp_do_redirect() call will pickup left-
> overs in per CPU bpf_redirect_info.
> 

So before the XDP_TX is implemented, this part of codes should reside below the XDP_REDIRECT case?

> > +
> > +     case XDP_REDIRECT:
> > +             err = xdp_do_redirect(fep->netdev, xdp, prog);
> > +             rxq->stats.xdp_redirect++;
> > -                     dma_unmap_single(&fep->pdev->dev,
...

> > -                                      fec32_to_cpu(bdp->cbd_bufaddr),
> > -                                      FEC_ENET_RX_FRSIZE - fep->rx_align,
> > -                                      DMA_FROM_DEVICE);
> > -             }
> > -
> > -             prefetch(skb->data - NET_IP_ALIGN);
> > +             skb = build_skb(page_address(page), FEC_ENET_RX_FRSIZE);
> 
> This looks wrong, I think FEC_ENET_RX_FRSIZE should be replaced by PAGE_SIZE.
> As build_skb() does:
> 
>   size -= SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
> 

Agree. As the current FRSIZE definition did not subtract the sizeof(struct skb_shared_info), I happened to not see the problem during the testing.

Thanks,
Shenwei

> > +             skb_reserve(skb, FEC_ENET_XDP_HEADROOM);
> 
> The skb_reserve looks correct.
> 
> >               skb_put(skb, pkt_len - 4);
> >               data = skb->data;
> > +             page_pool_release_page(rxq->page_pool, page);
> 
> Today page_pool have SKB recycle support (you might have looked at drivers
> that didn't utilize this yet), thus you don't need to release the page
> (page_pool_release_page) here.  Instead you could simply mark the SKB for
> recycling, unless driver does some page refcnt tricks I didn't notice.
> 
>   skb_mark_for_recycle(skb);
> 
> 
> > -             if (!is_copybreak && need_swap)
> > +             if (need_swap)
> >                       swap_buffer(data, pkt_len);
> >
> >   #if !defined(CONFIG_M5272)
> > @@ -1649,16 +1781,6 @@ fec_enet_rx_queue(struct net_device *ndev, int
> > budget, u16 queue_id)
> [...]


^ permalink raw reply	[flat|nested] 25+ messages in thread

* RE: [EXT] Re: [PATCH 1/1] net: fec: add initial XDP support
  2022-09-29  1:50 ` Andrew Lunn
@ 2022-09-29 12:46   ` Shenwei Wang
  2022-09-29 13:24     ` Andrew Lunn
  0 siblings, 1 reply; 25+ messages in thread
From: Shenwei Wang @ 2022-09-29 12:46 UTC (permalink / raw)
  To: Andrew Lunn
  Cc: Joakim Zhang, David S. Miller, Eric Dumazet, Jakub Kicinski,
	Paolo Abeni, Alexei Starovoitov, Daniel Borkmann,
	Jesper Dangaard Brouer, John Fastabend, netdev, linux-kernel,
	imx



> -----Original Message-----
> From: Andrew Lunn <andrew@lunn.ch>
> Sent: Wednesday, September 28, 2022 8:51 PM
> To: Shenwei Wang <shenwei.wang@nxp.com>
> Cc: Joakim Zhang <qiangqing.zhang@nxp.com>; David S. Miller
> <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>; Jakub
> Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; Alexei
> Starovoitov <ast@kernel.org>; Daniel Borkmann <daniel@iogearbox.net>;
> Jesper Dangaard Brouer <hawk@kernel.org>; John Fastabend
> <john.fastabend@gmail.com>; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; imx@lists.linux.dev
> Subject: [EXT] Re: [PATCH 1/1] net: fec: add initial XDP support
> 
> Caution: EXT Email
> 
> > +struct fec_enet_xdp_stats {
> > +     u64     xdp_pass;
> > +     u64     xdp_drop;
> > +     u64     xdp_xmit;
> > +     u64     xdp_redirect;
> > +     u64     xdp_xmit_err;
> > +     u64     xdp_tx;
> > +     u64     xdp_tx_err;
> > +};
> > +
> > +     switch (act) {
> > +     case XDP_PASS:
> > +             rxq->stats.xdp_pass++;
> 
> Since the stats are u64, and most machines using the FEC are 32 bit, you cannot
> just do an increment. Took a look at u64_stats_sync.h.
> 

As this increment is only executed under the NAPI kthread context,  is the protection still required?

> > -#define FEC_STATS_SIZE               (ARRAY_SIZE(fec_stats) * sizeof(u64))
> > +static struct fec_xdp_stat {
> > +     char name[ETH_GSTRING_LEN];
> > +     u32 count;
> > +} fec_xdp_stats[] = {
> > +     { "rx_xdp_redirect", 0 },
> > +     { "rx_xdp_pass", 0 },
> > +     { "rx_xdp_drop", 0 },
> > +     { "rx_xdp_tx", 0 },
> > +     { "rx_xdp_tx_errors", 0 },
> > +     { "tx_xdp_xmit", 0 },
> > +     { "tx_xdp_xmit_errors", 0 },
> > +};
> > +
> > +#define FEC_STATS_SIZE       ((ARRAY_SIZE(fec_stats) + \
> > +                     ARRAY_SIZE(fec_xdp_stats)) * sizeof(u64))
> 
> The page pool also has some stats. See page_pool_get_stats(),
> page_pool_ethtool_stats_get_strings() etc.
> 

Will add those stats in the next version.

Thanks,
Shenwei

>       Andrew

^ permalink raw reply	[flat|nested] 25+ messages in thread

* RE: [EXT] Re: [PATCH 1/1] net: fec: add initial XDP support
  2022-09-29  1:33 ` Andrew Lunn
@ 2022-09-29 12:40   ` Shenwei Wang
  2022-09-29 13:22     ` Andrew Lunn
  0 siblings, 1 reply; 25+ messages in thread
From: Shenwei Wang @ 2022-09-29 12:40 UTC (permalink / raw)
  To: Andrew Lunn
  Cc: Joakim Zhang, David S. Miller, Eric Dumazet, Jakub Kicinski,
	Paolo Abeni, Alexei Starovoitov, Daniel Borkmann,
	Jesper Dangaard Brouer, John Fastabend, netdev, linux-kernel,
	imx



> -----Original Message-----
> From: Andrew Lunn <andrew@lunn.ch>
> Sent: Wednesday, September 28, 2022 8:34 PM
> To: Shenwei Wang <shenwei.wang@nxp.com>
> Cc: Joakim Zhang <qiangqing.zhang@nxp.com>; David S. Miller
> <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>; Jakub
> Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; Alexei
> Starovoitov <ast@kernel.org>; Daniel Borkmann <daniel@iogearbox.net>;
> Jesper Dangaard Brouer <hawk@kernel.org>; John Fastabend
> <john.fastabend@gmail.com>; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; imx@lists.linux.dev
> Subject: [EXT] Re: [PATCH 1/1] net: fec: add initial XDP support
> 
> Caution: EXT Email
> 
> On Wed, Sep 28, 2022 at 10:25:09AM -0500, Shenwei Wang wrote:
> > This patch adds the initial XDP support to Freescale driver. It
> > supports XDP_PASS, XDP_DROP and XDP_REDIRECT actions. Upcoming
> patches
> > will add support for XDP_TX and Zero Copy features.
> >
> > This patch also optimizes the RX buffers by using the page pool, which
> > uses one frame per page for easy management. In the future, it can be
> > further improved to use two frames per page.
> 
> Please could you split this patch up. It is rather large and hard to review. I think
> you can first add support for the page pool, and then add XDP support, for
> example.
> 

Will do it in the next version. Thanks for the review.

> I would be interesting to see how the page pool helps performance for normal
> traffic, since that is what most people use it for. And for a range of devices,
> since we need to make sure it does not cause any regressions for older devices.
> 

I actually did some compare testing regarding the page pool for normal traffic. 
So far I don't see significant improvement in the current implementation. The performance for large packets improves a little, and the performance for small packets get a little worse.

Thanks,
Shenwei

>             Andrew

^ permalink raw reply	[flat|nested] 25+ messages in thread

end of thread, other threads:[~2022-10-27  1:50 UTC | newest]

Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-10-25 20:11 [PATCH 1/1] net: fec: add initial XDP support Shenwei Wang
2022-10-25 22:08 ` Andrew Lunn
2022-10-27  1:50   ` [EXT] " Shenwei Wang
2022-10-26  7:45 ` kernel test robot
  -- strict thread matches above, loose matches on Subject: below --
2022-09-28 15:25 Shenwei Wang
2022-09-29  1:33 ` Andrew Lunn
2022-09-29 12:40   ` [EXT] " Shenwei Wang
2022-09-29 13:22     ` Andrew Lunn
2022-09-29 13:26       ` Shenwei Wang
2022-09-29 15:19         ` Andrew Lunn
2022-09-29 15:28         ` Jesper Dangaard Brouer
2022-09-29 15:39           ` Andrew Lunn
2022-09-29 15:52           ` Shenwei Wang
2022-09-29 18:55             ` Jesper Dangaard Brouer
2022-10-03 12:49               ` Shenwei Wang
2022-10-04 11:21                 ` Jesper Dangaard Brouer
2022-10-04 13:12                   ` Shenwei Wang
2022-10-04 13:34                     ` Shenwei Wang
2022-10-05 12:40                       ` Shenwei Wang
2022-10-06  8:37                         ` Jesper Dangaard Brouer
2022-10-07  8:08                           ` Ilias Apalodimas
2022-10-07 19:18                             ` Shenwei Wang
2022-09-29  1:50 ` Andrew Lunn
2022-09-29 12:46   ` [EXT] " Shenwei Wang
2022-09-29 13:24     ` Andrew Lunn
2022-09-29 13:35       ` Shenwei Wang
2022-09-29 10:16 ` Jesper Dangaard Brouer
2022-09-29 13:11   ` [EXT] " Shenwei Wang
2022-09-29 15:44     ` Jesper Dangaard Brouer

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.