* [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.