LinuxLists.cc - [PATCH net-next 0/6] page

[permalink] [raw]

Subject: [PATCH net-next 1/6] xdp: reduce size of struct xdp_mem_info

From: Jesper Dangaard Brouer <[email protected]>

It is possible to compress/reduce the size of struct xdp_mem_info.
This change reduce struct xdp_mem_info from 8 bytes to 4 bytes.

The member xdp_mem_info.id can be reduced to u16, as the mem_id_ht
rhashtable in net/core/xdp.c is already limited by MEM_ID_MAX=0xFFFE
which can safely fit in u16.

The member xdp_mem_info.type could be reduced more than u16, as it stores
the enum xdp_mem_type, but due to alignment it is only reduced to u16.

Signed-off-by: Jesper Dangaard Brouer <[email protected]>
---
include/net/xdp.h | 4 ++--
net/core/xdp.c | 8 ++++----
2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/include/net/xdp.h b/include/net/xdp.h
index a5bc214a49d9..c35864d59113 100644
--- a/include/net/xdp.h
+++ b/include/net/xdp.h
@@ -48,8 +48,8 @@ enum xdp_mem_type {
#define XDP_XMIT_FLAGS_MASK XDP_XMIT_FLUSH

struct xdp_mem_info {
- u32 type; /* enum xdp_mem_type, but known size type */
- u32 id;
+ u16 type; /* enum xdp_mem_type, but known size type */
+ u16 id;
};

struct page_pool;
diff --git a/net/core/xdp.c b/net/core/xdp.c
index 05354976c1fc..3dd47ed83778 100644
--- a/net/core/xdp.c
+++ b/net/core/xdp.c
@@ -35,11 +35,11 @@ static struct rhashtable *mem_id_ht;

static u32 xdp_mem_id_hashfn(const void *data, u32 len, u32 seed)
{
- const u32 *k = data;
- const u32 key = *k;
+ const u16 *k = data;
+ const u16 key = *k;

BUILD_BUG_ON(sizeof_field(struct xdp_mem_allocator, mem.id)
- != sizeof(u32));
+ != sizeof(u16));

/* Use cyclic increasing ID as direct hash key */
return key;
@@ -49,7 +49,7 @@ static int xdp_mem_id_cmp(struct rhashtable_compare_arg *arg,
const void *ptr)
{
const struct xdp_mem_allocator *xa = ptr;
- u32 mem_id = *(u32 *)arg->key;
+ u16 mem_id = *(u16 *)arg->key;

return xa->mem.id != mem_id;
}
--
2.30.2

2021-03-22 17:05:38

[permalink] [raw]

Subject: [PATCH net-next 2/6] mm: add a signature in struct page

From: Matteo Croce <[email protected]>

This is needed by the page_pool to avoid recycling a page not allocated
via page_pool.

Signed-off-by: Matteo Croce <[email protected]>
---
include/linux/mm_types.h | 1 +
include/net/page_pool.h | 2 ++
net/core/page_pool.c | 4 ++++
3 files changed, 7 insertions(+)

diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 0974ad501a47..67caade433e4 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -100,6 +100,7 @@ struct page {
* 32-bit architectures.
*/
dma_addr_t dma_addr;
+ unsigned long signature;
};
struct { /* slab, slob and slub */
union {
diff --git a/include/net/page_pool.h b/include/net/page_pool.h
index b5b195305346..b30405e84b5e 100644
--- a/include/net/page_pool.h
+++ b/include/net/page_pool.h
@@ -63,6 +63,8 @@
*/
#define PP_ALLOC_CACHE_SIZE 128
#define PP_ALLOC_CACHE_REFILL 64
+#define PP_SIGNATURE 0x20210303
+
struct pp_alloc_cache {
u32 count;
void *cache[PP_ALLOC_CACHE_SIZE];
diff --git a/net/core/page_pool.c b/net/core/page_pool.c
index ad8b0707af04..2ae9b554ef98 100644
--- a/net/core/page_pool.c
+++ b/net/core/page_pool.c
@@ -232,6 +232,8 @@ static struct page *__page_pool_alloc_pages_slow(struct page_pool *pool,
page_pool_dma_sync_for_device(pool, page, pool->p.max_len);

skip_dma_map:
+ page->signature = PP_SIGNATURE;
+
/* Track how many pages are held 'in-flight' */
pool->pages_state_hold_cnt++;

@@ -302,6 +304,8 @@ void page_pool_release_page(struct page_pool *pool, struct page *page)
DMA_ATTR_SKIP_CPU_SYNC);
page->dma_addr = 0;
skip_dma_unmap:
+ page->signature = 0;
+
/* This may be the last page returned, releasing the pool, so
* it is not safe to reference pool afterwards.
*/
--
2.30.2

2021-03-22 17:05:47

[permalink] [raw]

Subject: [PATCH net-next 3/6] page_pool: DMA handling and allow to recycles frames via SKB

From: Ilias Apalodimas <[email protected]>

During skb_release_data() intercept the packet and if it's a buffer
coming from our page_pool API recycle it back to the pool for further
usage.
To achieve that we introduce a bit in struct sk_buff (pp_recycle:1) and
store the xdp_mem_info in page->private. The SKB bit is needed since
page->private is used by skb_copy_ubufs, so we can't rely solely on
page->private to trigger recycling.

The driver has to take care of the sync operations on it's own
during the buffer recycling since the buffer is never unmapped.

In order to enable recycling the driver must call skb_mark_for_recycle()
to store the information we need for recycling in page->private and
enabling the recycling bit

Storing the information in page->private allows us to recycle both SKBs
and their fragments

Signed-off-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Jesper Dangaard Brouer <[email protected]>
Signed-off-by: Matteo Croce <[email protected]>
---
include/linux/skbuff.h | 33 +++++++++++++++++++++++++++----
include/net/page_pool.h | 13 +++++++++++++
include/net/xdp.h | 1 +
net/core/page_pool.c | 43 +++++++++++++++++++++++++++++++++++++++++
net/core/skbuff.c | 20 +++++++++++++++++--
net/core/xdp.c | 6 ++++++
6 files changed, 110 insertions(+), 6 deletions(-)

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index ecc029674ae4..3e09a070136f 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -40,6 +40,9 @@
#if IS_ENABLED(CONFIG_NF_CONNTRACK)
#include <linux/netfilter/nf_conntrack_common.h>
#endif
+#if IS_BUILTIN(CONFIG_PAGE_POOL)
+#include <net/page_pool.h>
+#endif

/* The interface for checksum offload between the stack and networking drivers
* is as follows...
@@ -247,6 +250,7 @@ struct napi_struct;
struct bpf_prog;
union bpf_attr;
struct skb_ext;
+struct xdp_mem_info;

#if IS_ENABLED(CONFIG_BRIDGE_NETFILTER)
struct nf_bridge_info {
@@ -666,6 +670,8 @@ typedef unsigned char *sk_buff_data_t;
* @head_frag: skb was allocated from page fragments,
* not allocated by kmalloc() or vmalloc().
* @pfmemalloc: skbuff was allocated from PFMEMALLOC reserves
+ * @pp_recycle: mark the packet for recycling instead of freeing (implies
+ * page_pool support on driver)
* @active_extensions: active extensions (skb_ext_id types)
* @ndisc_nodetype: router type (from link layer)
* @ooo_okay: allow the mapping of a socket to a queue to be changed
@@ -790,10 +796,12 @@ struct sk_buff {
fclone:2,
peeked:1,
head_frag:1,
- pfmemalloc:1;
+ pfmemalloc:1,
+ pp_recycle:1; /* page_pool recycle indicator */
#ifdef CONFIG_SKB_EXTENSIONS
__u8 active_extensions;
#endif
+
/* fields enclosed in headers_start/headers_end are copied
* using a single memcpy() in __copy_skb_header()
*/
@@ -3080,12 +3088,20 @@ static inline void skb_frag_ref(struct sk_buff *skb, int f)
/**
* __skb_frag_unref - release a reference on a paged fragment.
* @frag: the paged fragment
+ * @recycle: recycle the page if allocated via page_pool
*
* Releases a reference on the paged fragment @frag.
+ * or recycles the page via the page_pool API
*/
-static inline void __skb_frag_unref(skb_frag_t *frag)
+static inline void __skb_frag_unref(skb_frag_t *frag, bool recycle)
{
- put_page(skb_frag_page(frag));
+ struct page *page = skb_frag_page(frag);
+
+#if IS_BUILTIN(CONFIG_PAGE_POOL)
+ if (recycle && page_pool_return_skb_page(page_address(page)))
+ return;
+#endif
+ put_page(page);
}

/**
@@ -3097,7 +3113,7 @@ static inline void __skb_frag_unref(skb_frag_t *frag)
*/
static inline void skb_frag_unref(struct sk_buff *skb, int f)
{
- __skb_frag_unref(&skb_shinfo(skb)->frags[f]);
+ __skb_frag_unref(&skb_shinfo(skb)->frags[f], skb->pp_recycle);
}

/**
@@ -4695,5 +4711,14 @@ static inline u64 skb_get_kcov_handle(struct sk_buff *skb)
#endif
}

+#if IS_BUILTIN(CONFIG_PAGE_POOL)
+static inline void skb_mark_for_recycle(struct sk_buff *skb, struct page *page,
+ struct xdp_mem_info *mem)
+{
+ skb->pp_recycle = 1;
+ page_pool_store_mem_info(page, mem);
+}
+#endif
+
#endif /* __KERNEL__ */
#endif /* _LINUX_SKBUFF_H */
diff --git a/include/net/page_pool.h b/include/net/page_pool.h
index b30405e84b5e..75fffc15788b 100644
--- a/include/net/page_pool.h
+++ b/include/net/page_pool.h
@@ -65,6 +65,8 @@
#define PP_ALLOC_CACHE_REFILL 64
#define PP_SIGNATURE 0x20210303

+struct xdp_mem_info;
+
struct pp_alloc_cache {
u32 count;
void *cache[PP_ALLOC_CACHE_SIZE];
@@ -148,6 +150,8 @@ inline enum dma_data_direction page_pool_get_dma_dir(struct page_pool *pool)
return pool->p.dma_dir;
}

+bool page_pool_return_skb_page(void *data);
+
struct page_pool *page_pool_create(const struct page_pool_params *params);

#ifdef CONFIG_PAGE_POOL
@@ -243,4 +247,13 @@ static inline void page_pool_ring_unlock(struct page_pool *pool)
spin_unlock_bh(&pool->ring.producer_lock);
}

+/* Store mem_info on struct page and use it while recycling skb frags */
+static inline
+void page_pool_store_mem_info(struct page *page, struct xdp_mem_info *mem)
+{
+ u32 *xmi = (u32 *)mem;
+
+ set_page_private(page, *xmi);
+}
+
#endif /* _NET_PAGE_POOL_H */
diff --git a/include/net/xdp.h b/include/net/xdp.h
index c35864d59113..5d7316f1f195 100644
--- a/include/net/xdp.h
+++ b/include/net/xdp.h
@@ -235,6 +235,7 @@ void xdp_return_buff(struct xdp_buff *xdp);
void xdp_flush_frame_bulk(struct xdp_frame_bulk *bq);
void xdp_return_frame_bulk(struct xdp_frame *xdpf,
struct xdp_frame_bulk *bq);
+void xdp_return_skb_frame(void *data, struct xdp_mem_info *mem);

/* When sending xdp_frame into the network stack, then there is no
* return point callback, which is needed to release e.g. DMA-mapping
diff --git a/net/core/page_pool.c b/net/core/page_pool.c
index 2ae9b554ef98..43bfd2e3d8df 100644
--- a/net/core/page_pool.c
+++ b/net/core/page_pool.c
@@ -9,6 +9,7 @@
#include <linux/kernel.h>
#include <linux/slab.h>
#include <linux/device.h>
+#include <linux/skbuff.h>

#include <net/page_pool.h>
#include <net/xdp.h>
@@ -17,12 +18,19 @@
#include <linux/dma-mapping.h>
#include <linux/page-flags.h>
#include <linux/mm.h> /* for __put_page() */
+#include <net/xdp.h>

#include <trace/events/page_pool.h>

#define DEFER_TIME (msecs_to_jiffies(1000))
#define DEFER_WARN_INTERVAL (60 * HZ)

+/* Used to store/retrieve hi/lo bytes from xdp_mem_info to page->private */
+union page_pool_xmi {
+ u32 raw;
+ struct xdp_mem_info mem_info;
+};
+
static int page_pool_init(struct page_pool *pool,
const struct page_pool_params *params)
{
@@ -587,3 +595,38 @@ void page_pool_update_nid(struct page_pool *pool, int new_nid)
}
}
EXPORT_SYMBOL(page_pool_update_nid);
+
+bool page_pool_return_skb_page(void *data)
+{
+ struct xdp_mem_info mem_info;
+ union page_pool_xmi info;
+ struct page *page;
+
+ page = virt_to_head_page(data);
+ if (unlikely(page->signature != PP_SIGNATURE))
+ return false;
+
+ info.raw = page_private(page);
+ mem_info = info.mem_info;
+
+ /* If a buffer is marked for recycle and does not belong to
+ * MEM_TYPE_PAGE_POOL, the buffers will be eventually freed from the
+ * network stack and kfree_skb, but the DMA region will *not* be
+ * correctly unmapped. WARN here for the recycling misusage
+ */
+ if (unlikely(mem_info.type != MEM_TYPE_PAGE_POOL)) {
+ WARN_ONCE(true, "Tried to recycle non MEM_TYPE_PAGE_POOL");
+ return false;
+ }
+
+ /* Driver set this to memory recycling info. Reset it on recycle
+ * This will *not* work for NIC using a split-page memory model.
+ * The page will be returned to the pool here regardless of the
+ * 'flipped' fragment being in use or not
+ */
+ set_page_private(page, 0);
+ xdp_return_skb_frame(data, &mem_info);
+
+ return true;
+}
+EXPORT_SYMBOL(page_pool_return_skb_page);
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index e8320b5d651a..7f5c02085438 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -69,6 +69,9 @@
#include <net/xfrm.h>
#include <net/mpls.h>
#include <net/mptcp.h>
+#if IS_BUILTIN(CONFIG_PAGE_POOL)
+#include <net/page_pool.h>
+#endif

#include <linux/uaccess.h>
#include <trace/events/skb.h>
@@ -644,6 +647,11 @@ static void skb_free_head(struct sk_buff *skb)
{
unsigned char *head = skb->head;

+#if IS_BUILTIN(CONFIG_PAGE_POOL)
+ if (skb->pp_recycle && page_pool_return_skb_page(head))
+ return;
+#endif
+
if (skb->head_frag)
skb_free_frag(head);
else
@@ -663,7 +671,7 @@ static void skb_release_data(struct sk_buff *skb)
skb_zcopy_clear(skb, true);

for (i = 0; i < shinfo->nr_frags; i++)
- __skb_frag_unref(&shinfo->frags[i]);
+ __skb_frag_unref(&shinfo->frags[i], skb->pp_recycle);

if (shinfo->frag_list)
kfree_skb_list(shinfo->frag_list);
@@ -1045,6 +1053,7 @@ static struct sk_buff *__skb_clone(struct sk_buff *n, struct sk_buff *skb)
n->nohdr = 0;
n->peeked = 0;
C(pfmemalloc);
+ C(pp_recycle);
n->destructor = NULL;
C(tail);
C(end);
@@ -3453,7 +3462,7 @@ int skb_shift(struct sk_buff *tgt, struct sk_buff *skb, int shiftlen)
fragto = &skb_shinfo(tgt)->frags[merge];

skb_frag_size_add(fragto, skb_frag_size(fragfrom));
- __skb_frag_unref(fragfrom);
+ __skb_frag_unref(fragfrom, skb->pp_recycle);
}

/* Reposition in the original skb */
@@ -5234,6 +5243,13 @@ bool skb_try_coalesce(struct sk_buff *to, struct sk_buff *from,
if (skb_cloned(to))
return false;

+ /* We can't coalesce skb that are allocated from slab and page_pool
+ * The recycle mark is on the skb, so that might end up trying to
+ * recycle slab allocated skb->head
+ */
+ if (to->pp_recycle != from->pp_recycle)
+ return false;
+
if (len <= skb_tailroom(to)) {
if (len)
BUG_ON(skb_copy_bits(from, 0, skb_put(to, len), len));
diff --git a/net/core/xdp.c b/net/core/xdp.c
index 3dd47ed83778..d89b827e54a9 100644
--- a/net/core/xdp.c
+++ b/net/core/xdp.c
@@ -372,6 +372,12 @@ static void __xdp_return(void *data, struct xdp_mem_info *mem, bool napi_direct,
}
}

+void xdp_return_skb_frame(void *data, struct xdp_mem_info *mem)
+{
+ __xdp_return(data, mem, false, NULL);
+}
+EXPORT_SYMBOL_GPL(xdp_return_skb_frame);
+
void xdp_return_frame(struct xdp_frame *xdpf)
{
__xdp_return(xdpf->data, &xdpf->mem, false, NULL);
--
2.30.2

2021-03-22 17:06:02

[permalink] [raw]

Subject: [PATCH net-next 4/6] net: change users of __skb_frag_unref() and add an extra argument

From: Ilias Apalodimas <[email protected]>

On a previous patch we added an extra argument on __skb_frag_unref() to
handle recycling. Update the current users of the function with that.

Signed-off-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Matteo Croce <[email protected]>
---
drivers/net/ethernet/chelsio/inline_crypto/ch_ktls/chcr_ktls.c | 2 +-
drivers/net/ethernet/marvell/sky2.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 2 +-
net/tls/tls_device.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/chelsio/inline_crypto/ch_ktls/chcr_ktls.c b/drivers/net/ethernet/chelsio/inline_crypto/ch_ktls/chcr_ktls.c
index 169e10c91378..cbcff5518965 100644
--- a/drivers/net/ethernet/chelsio/inline_crypto/ch_ktls/chcr_ktls.c
+++ b/drivers/net/ethernet/chelsio/inline_crypto/ch_ktls/chcr_ktls.c
@@ -2125,7 +2125,7 @@ static int chcr_ktls_xmit(struct sk_buff *skb, struct net_device *dev)
/* clear the frag ref count which increased locally before */
for (i = 0; i < record->num_frags; i++) {
/* clear the frag ref count */
- __skb_frag_unref(&record->frags[i]);
+ __skb_frag_unref(&record->frags[i], false);
}
/* if any failure, come out from the loop. */
if (ret) {
diff --git a/drivers/net/ethernet/marvell/sky2.c b/drivers/net/ethernet/marvell/sky2.c
index 2a752fb6b758..1cc646fb4fe4 100644
--- a/drivers/net/ethernet/marvell/sky2.c
+++ b/drivers/net/ethernet/marvell/sky2.c
@@ -2501,7 +2501,7 @@ static void skb_put_frags(struct sk_buff *skb, unsigned int hdr_space,

if (length == 0) {
/* don't need this page */
- __skb_frag_unref(frag);
+ __skb_frag_unref(frag, false);
--skb_shinfo(skb)->nr_frags;
} else {
size = min(length, (unsigned) PAGE_SIZE);
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index e35e4d7ef4d1..cea62b8f554c 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -526,7 +526,7 @@ static int mlx4_en_complete_rx_desc(struct mlx4_en_priv *priv,
fail:
while (nr > 0) {
nr--;
- __skb_frag_unref(skb_shinfo(skb)->frags + nr);
+ __skb_frag_unref(skb_shinfo(skb)->frags + nr, false);
}
return 0;
}
diff --git a/net/tls/tls_device.c b/net/tls/tls_device.c
index d9cd229aa111..2a32a547e51a 100644
--- a/net/tls/tls_device.c
+++ b/net/tls/tls_device.c
@@ -127,7 +127,7 @@ static void destroy_record(struct tls_record_info *record)
int i;

for (i = 0; i < record->num_frags; i++)
- __skb_frag_unref(&record->frags[i]);
+ __skb_frag_unref(&record->frags[i], false);
kfree(record);
}

--
2.30.2

2021-03-22 17:06:18

[permalink] [raw]

Subject: [PATCH net-next 5/6] mvpp2: recycle buffers

From: Matteo Croce <[email protected]>

Use the new recycling API for page_pool.
In a drop rate test, the packet rate is more than doubled,
from 962 Kpps to 2047 Kpps.

perf top on a stock system shows:

Overhead Shared Object Symbol
30.67% [kernel] [k] page_pool_release_page
8.37% [kernel] [k] get_page_from_freelist
7.34% [kernel] [k] free_unref_page
6.47% [mvpp2] [k] mvpp2_rx
4.69% [kernel] [k] eth_type_trans
4.55% [kernel] [k] __netif_receive_skb_core
4.40% [kernel] [k] build_skb
4.29% [kernel] [k] kmem_cache_free
4.00% [kernel] [k] kmem_cache_alloc
3.81% [kernel] [k] dev_gro_receive

With packet rate stable at 962 Kpps:

tx: 0 bps 0 pps rx: 477.4 Mbps 962.6 Kpps
tx: 0 bps 0 pps rx: 477.6 Mbps 962.8 Kpps
tx: 0 bps 0 pps rx: 477.6 Mbps 962.9 Kpps
tx: 0 bps 0 pps rx: 477.2 Mbps 962.1 Kpps
tx: 0 bps 0 pps rx: 477.5 Mbps 962.7 Kpps

And this is the same output with recycling enabled:

Overhead Shared Object Symbol
12.75% [mvpp2] [k] mvpp2_rx
9.56% [kernel] [k] __netif_receive_skb_core
9.29% [kernel] [k] build_skb
9.27% [kernel] [k] eth_type_trans
8.39% [kernel] [k] kmem_cache_alloc
7.85% [kernel] [k] kmem_cache_free
7.36% [kernel] [k] page_pool_put_page
6.45% [kernel] [k] dev_gro_receive
4.72% [kernel] [k] __xdp_return
3.06% [kernel] [k] page_pool_refill_alloc_cache

With packet rate above 2000 Kpps:

tx: 0 bps 0 pps rx: 1015 Mbps 2046 Kpps
tx: 0 bps 0 pps rx: 1015 Mbps 2047 Kpps
tx: 0 bps 0 pps rx: 1015 Mbps 2047 Kpps
tx: 0 bps 0 pps rx: 1015 Mbps 2047 Kpps
tx: 0 bps 0 pps rx: 1015 Mbps 2047 Kpps

The major performance increase is explained by the fact that the most CPU
consuming functions (page_pool_release_page, get_page_from_freelist
and free_unref_page) are no longer called on a per packet basis.

The test was done by sending to the macchiatobin 64 byte ethernet frames
with an invalid ethertype, so the packets are dropped early in the RX path.

Signed-off-by: Matteo Croce <[email protected]>
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 1767c60056c5..8f03bbc763bc 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -3848,6 +3848,7 @@ static int mvpp2_rx(struct mvpp2_port *port, struct napi_struct *napi,
struct mvpp2_pcpu_stats ps = {};
enum dma_data_direction dma_dir;
struct bpf_prog *xdp_prog;
+ struct xdp_rxq_info *rxqi;
struct xdp_buff xdp;
int rx_received;
int rx_done = 0;
@@ -3913,15 +3914,15 @@ static int mvpp2_rx(struct mvpp2_port *port, struct napi_struct *napi,
else
frag_size = bm_pool->frag_size;

- if (xdp_prog) {
- struct xdp_rxq_info *xdp_rxq;
+ if (bm_pool->pkt_size == MVPP2_BM_SHORT_PKT_SIZE)
+ rxqi = &rxq->xdp_rxq_short;
+ else
+ rxqi = &rxq->xdp_rxq_long;

- if (bm_pool->pkt_size == MVPP2_BM_SHORT_PKT_SIZE)
- xdp_rxq = &rxq->xdp_rxq_short;
- else
- xdp_rxq = &rxq->xdp_rxq_long;
+ if (xdp_prog) {
+ xdp.rxq = rxqi;

- xdp_init_buff(&xdp, PAGE_SIZE, xdp_rxq);
+ xdp_init_buff(&xdp, PAGE_SIZE, rxqi);
xdp_prepare_buff(&xdp, data,
MVPP2_MH_SIZE + MVPP2_SKB_HEADROOM,
rx_bytes, false);
@@ -3965,7 +3966,7 @@ static int mvpp2_rx(struct mvpp2_port *port, struct napi_struct *napi,
}

if (pp)
- page_pool_release_page(pp, virt_to_page(data));
+ skb_mark_for_recycle(skb, virt_to_page(data), &rxqi->mem);
else
dma_unmap_single_attrs(dev->dev.parent, dma_addr,
bm_pool->buf_size, DMA_FROM_DEVICE,
--
2.30.2

2021-03-22 17:08:37

[permalink] [raw]

Subject: [PATCH net-next 6/6] mvneta: recycle buffers

From: Matteo Croce <[email protected]>

Use the new recycling API for page_pool.
In a drop rate test, the packet rate increased di 10%,
from 269 Kpps to 296 Kpps.

perf top on a stock system shows:

Overhead Shared Object Symbol
21.78% [kernel] [k] __pi___inval_dcache_area
21.66% [mvneta] [k] mvneta_rx_swbm
7.00% [kernel] [k] kmem_cache_alloc
6.05% [kernel] [k] eth_type_trans
4.44% [kernel] [k] kmem_cache_free.part.0
3.80% [kernel] [k] __netif_receive_skb_core
3.68% [kernel] [k] dev_gro_receive
3.65% [kernel] [k] get_page_from_freelist
3.43% [kernel] [k] page_pool_release_page
3.35% [kernel] [k] free_unref_page

And this is the same output with recycling enabled:

Overhead Shared Object Symbol
24.10% [kernel] [k] __pi___inval_dcache_area
23.02% [mvneta] [k] mvneta_rx_swbm
7.19% [kernel] [k] kmem_cache_alloc
6.50% [kernel] [k] eth_type_trans
4.93% [kernel] [k] __netif_receive_skb_core
4.77% [kernel] [k] kmem_cache_free.part.0
3.93% [kernel] [k] dev_gro_receive
3.03% [kernel] [k] build_skb
2.91% [kernel] [k] page_pool_put_page
2.85% [kernel] [k] __xdp_return

The test was done with mausezahn on the TX side with 64 byte raw
ethernet frames.

Signed-off-by: Matteo Croce <[email protected]>
---
drivers/net/ethernet/marvell/mvneta.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index a635cf84608a..8b3250394703 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -2332,7 +2332,7 @@ mvneta_swbm_build_skb(struct mvneta_port *pp, struct mvneta_rx_queue *rxq,
if (!skb)
return ERR_PTR(-ENOMEM);

- page_pool_release_page(rxq->page_pool, virt_to_page(xdp->data));
+ skb_mark_for_recycle(skb, virt_to_page(xdp->data), &xdp->rxq->mem);

skb_reserve(skb, xdp->data - xdp->data_hard_start);
skb_put(skb, xdp->data_end - xdp->data);
@@ -2344,7 +2344,7 @@ mvneta_swbm_build_skb(struct mvneta_port *pp, struct mvneta_rx_queue *rxq,
skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags,
skb_frag_page(frag), skb_frag_off(frag),
skb_frag_size(frag), PAGE_SIZE);
- page_pool_release_page(rxq->page_pool, skb_frag_page(frag));
+ skb_mark_for_recycle(skb, skb_frag_page(frag), &xdp->rxq->mem);
}

return skb;
--
2.30.2

2021-03-22 19:41:15

[permalink] [raw]

Subject: Re: [PATCH net-next 3/6] page_pool: DMA handling and allow to recycles frames via SKB

On Mon, Mar 22, 2021 at 6:03 PM Matteo Croce <[email protected]> wrote:
>
> From: Ilias Apalodimas <[email protected]>
>
> During skb_release_data() intercept the packet and if it's a buffer
> coming from our page_pool API recycle it back to the pool for further
> usage.
> To achieve that we introduce a bit in struct sk_buff (pp_recycle:1) and
> store the xdp_mem_info in page->private. The SKB bit is needed since
> page->private is used by skb_copy_ubufs, so we can't rely solely on
> page->private to trigger recycling.
>
> The driver has to take care of the sync operations on it's own
> during the buffer recycling since the buffer is never unmapped.
>
> In order to enable recycling the driver must call skb_mark_for_recycle()
> to store the information we need for recycling in page->private and
> enabling the recycling bit
>
> Storing the information in page->private allows us to recycle both SKBs
> and their fragments
>
> Signed-off-by: Ilias Apalodimas <[email protected]>
> Signed-off-by: Jesper Dangaard Brouer <[email protected]>
> Signed-off-by: Matteo Croce <[email protected]>
> ---

Hi, the patch title really should be:

page_pool: DMA handling and frame recycling via SKBs

As in the previous RFC.
Sorry,
--
per aspera ad upstream

2021-03-23 15:01:38

by David Ahern

[permalink] [raw]

Subject: Re: [PATCH net-next 0/6] page_pool: recycle buffers

On 3/22/21 11:02 AM, Matteo Croce wrote:
> From: Matteo Croce <[email protected]>
>
> This series enables recycling of the buffers allocated with the page_pool API.
> The first two patches are just prerequisite to save space in a struct and
> avoid recycling pages allocated with other API.
> Patch 2 was based on a previous idea from Jonathan Lemon.
>
> The third one is the real recycling, 4 fixes the compilation of __skb_frag_unref
> users, and 5,6 enable the recycling on two drivers.

patch 4 should be folded into 3; each patch should build without errors.

>
> In the last two patches I reported the improvement I have with the series.
>
> The recycling as is can't be used with drivers like mlx5 which do page split,
> but this is documented in a comment.
> In the future, a refcount can be used so to support mlx5 with no changes.

Is the end goal of the page_pool changes to remove driver private caches?

2021-03-23 15:06:10

[permalink] [raw]

Subject: Re: [PATCH net-next 0/6] page_pool: recycle buffers

Hi David,

On Tue, Mar 23, 2021 at 08:57:57AM -0600, David Ahern wrote:
> On 3/22/21 11:02 AM, Matteo Croce wrote:
> > From: Matteo Croce <[email protected]>
> >
> > This series enables recycling of the buffers allocated with the page_pool API.
> > The first two patches are just prerequisite to save space in a struct and
> > avoid recycling pages allocated with other API.
> > Patch 2 was based on a previous idea from Jonathan Lemon.
> >
> > The third one is the real recycling, 4 fixes the compilation of __skb_frag_unref
> > users, and 5,6 enable the recycling on two drivers.
>
> patch 4 should be folded into 3; each patch should build without errors.
>

Yes

> >
> > In the last two patches I reported the improvement I have with the series.
> >
> > The recycling as is can't be used with drivers like mlx5 which do page split,
> > but this is documented in a comment.
> > In the future, a refcount can be used so to support mlx5 with no changes.
>
> Is the end goal of the page_pool changes to remove driver private caches?
>
>

Yes. The patchset doesn't currently support that , because all the >10gbit
interfaces split the page and we don't account for that. We should be able to
extend it though and account for that. I don't have any hardware
(Intel/mlx) available, but I'll be happy to talk to anyone that does and
figure out a way to support those cards properly.

Cheers
/Ilias

2021-03-23 15:08:15

by Jesper Dangaard Brouer

[permalink] [raw]

Subject: Re: [PATCH net-next 6/6] mvneta: recycle buffers

On Mon, 22 Mar 2021 18:03:01 +0100
Matteo Croce <[email protected]> wrote:

> From: Matteo Croce <[email protected]>
>
> Use the new recycling API for page_pool.
> In a drop rate test, the packet rate increased di 10%,
> from 269 Kpps to 296 Kpps.
>
> perf top on a stock system shows:
>
> Overhead Shared Object Symbol
> 21.78% [kernel] [k] __pi___inval_dcache_area
> 21.66% [mvneta] [k] mvneta_rx_swbm
> 7.00% [kernel] [k] kmem_cache_alloc
> 6.05% [kernel] [k] eth_type_trans
> 4.44% [kernel] [k] kmem_cache_free.part.0
> 3.80% [kernel] [k] __netif_receive_skb_core
> 3.68% [kernel] [k] dev_gro_receive
> 3.65% [kernel] [k] get_page_from_freelist
> 3.43% [kernel] [k] page_pool_release_page
> 3.35% [kernel] [k] free_unref_page
>
> And this is the same output with recycling enabled:
>
> Overhead Shared Object Symbol
> 24.10% [kernel] [k] __pi___inval_dcache_area
> 23.02% [mvneta] [k] mvneta_rx_swbm
> 7.19% [kernel] [k] kmem_cache_alloc
> 6.50% [kernel] [k] eth_type_trans
> 4.93% [kernel] [k] __netif_receive_skb_core
> 4.77% [kernel] [k] kmem_cache_free.part.0
> 3.93% [kernel] [k] dev_gro_receive
> 3.03% [kernel] [k] build_skb
> 2.91% [kernel] [k] page_pool_put_page
> 2.85% [kernel] [k] __xdp_return
>
> The test was done with mausezahn on the TX side with 64 byte raw
> ethernet frames.
>
> Signed-off-by: Matteo Croce <[email protected]>
> ---
> drivers/net/ethernet/marvell/mvneta.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
> index a635cf84608a..8b3250394703 100644
> --- a/drivers/net/ethernet/marvell/mvneta.c
> +++ b/drivers/net/ethernet/marvell/mvneta.c
> @@ -2332,7 +2332,7 @@ mvneta_swbm_build_skb(struct mvneta_port *pp, struct mvneta_rx_queue *rxq,
> if (!skb)
> return ERR_PTR(-ENOMEM);
>
> - page_pool_release_page(rxq->page_pool, virt_to_page(xdp->data));
> + skb_mark_for_recycle(skb, virt_to_page(xdp->data), &xdp->rxq->mem);
>
> skb_reserve(skb, xdp->data - xdp->data_hard_start);
> skb_put(skb, xdp->data_end - xdp->data);
> @@ -2344,7 +2344,7 @@ mvneta_swbm_build_skb(struct mvneta_port *pp, struct mvneta_rx_queue *rxq,
> skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags,
> skb_frag_page(frag), skb_frag_off(frag),
> skb_frag_size(frag), PAGE_SIZE);
> - page_pool_release_page(rxq->page_pool, skb_frag_page(frag));
> + skb_mark_for_recycle(skb, skb_frag_page(frag), &xdp->rxq->mem);
> }
>
> return skb;

This cause skb_mark_for_recycle() to set 'skb->pp_recycle=1' multiple
times, for the same SKB. (copy-pasted function below signature to help
reviewers).

This makes me question if we need an API for setting this per page
fragment?
Or if the API skb_mark_for_recycle() need to walk the page fragments in
the SKB and set the info stored in the page for each?

--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer

2021-03-23 15:43:30

[permalink] [raw]

Subject: Re: [PATCH net-next 0/6] page_pool: recycle buffers

From: Matteo Croce <[email protected]>
Date: Mon, 22 Mar 2021 18:02:55 +0100

> From: Matteo Croce <[email protected]>
>
> This series enables recycling of the buffers allocated with the page_pool API.
> The first two patches are just prerequisite to save space in a struct and
> avoid recycling pages allocated with other API.
> Patch 2 was based on a previous idea from Jonathan Lemon.
>
> The third one is the real recycling, 4 fixes the compilation of __skb_frag_unref
> users, and 5,6 enable the recycling on two drivers.
>
> In the last two patches I reported the improvement I have with the series.
>
> The recycling as is can't be used with drivers like mlx5 which do page split,
> but this is documented in a comment.
> In the future, a refcount can be used so to support mlx5 with no changes.
>
> Ilias Apalodimas (2):
> page_pool: DMA handling and allow to recycles frames via SKB
> net: change users of __skb_frag_unref() and add an extra argument
>
> Jesper Dangaard Brouer (1):
> xdp: reduce size of struct xdp_mem_info
>
> Matteo Croce (3):
> mm: add a signature in struct page
> mvpp2: recycle buffers
> mvneta: recycle buffers
>
> .../chelsio/inline_crypto/ch_ktls/chcr_ktls.c | 2 +-
> drivers/net/ethernet/marvell/mvneta.c | 4 +-
> .../net/ethernet/marvell/mvpp2/mvpp2_main.c | 17 +++----
> drivers/net/ethernet/marvell/sky2.c | 2 +-
> drivers/net/ethernet/mellanox/mlx4/en_rx.c | 2 +-
> include/linux/mm_types.h | 1 +
> include/linux/skbuff.h | 33 +++++++++++--
> include/net/page_pool.h | 15 ++++++
> include/net/xdp.h | 5 +-
> net/core/page_pool.c | 47 +++++++++++++++++++
> net/core/skbuff.c | 20 +++++++-
> net/core/xdp.c | 14 ++++--
> net/tls/tls_device.c | 2 +-
> 13 files changed, 138 insertions(+), 26 deletions(-)

Just for the reference, I've performed some tests on 1G SoC NIC with
this patchset on, here's direct link: [0]

> --
> 2.30.2

[0] https://lore.kernel.org/netdev/[email protected]

Thanks,
Al

2021-03-23 15:51:24

[permalink] [raw]

Subject: Re: [PATCH net-next 0/6] page_pool: recycle buffers

On Tue, Mar 23, 2021 at 03:41:23PM +0000, Alexander Lobakin wrote:
> From: Matteo Croce <[email protected]>
> Date: Mon, 22 Mar 2021 18:02:55 +0100
>
> > From: Matteo Croce <[email protected]>
> >
> > This series enables recycling of the buffers allocated with the page_pool API.
> > The first two patches are just prerequisite to save space in a struct and
> > avoid recycling pages allocated with other API.
> > Patch 2 was based on a previous idea from Jonathan Lemon.
> >
> > The third one is the real recycling, 4 fixes the compilation of __skb_frag_unref
> > users, and 5,6 enable the recycling on two drivers.
> >
> > In the last two patches I reported the improvement I have with the series.
> >
> > The recycling as is can't be used with drivers like mlx5 which do page split,
> > but this is documented in a comment.
> > In the future, a refcount can be used so to support mlx5 with no changes.
> >
> > Ilias Apalodimas (2):
> > page_pool: DMA handling and allow to recycles frames via SKB
> > net: change users of __skb_frag_unref() and add an extra argument
> >
> > Jesper Dangaard Brouer (1):
> > xdp: reduce size of struct xdp_mem_info
> >
> > Matteo Croce (3):
> > mm: add a signature in struct page
> > mvpp2: recycle buffers
> > mvneta: recycle buffers
> >
> > .../chelsio/inline_crypto/ch_ktls/chcr_ktls.c | 2 +-
> > drivers/net/ethernet/marvell/mvneta.c | 4 +-
> > .../net/ethernet/marvell/mvpp2/mvpp2_main.c | 17 +++----
> > drivers/net/ethernet/marvell/sky2.c | 2 +-
> > drivers/net/ethernet/mellanox/mlx4/en_rx.c | 2 +-
> > include/linux/mm_types.h | 1 +
> > include/linux/skbuff.h | 33 +++++++++++--
> > include/net/page_pool.h | 15 ++++++
> > include/net/xdp.h | 5 +-
> > net/core/page_pool.c | 47 +++++++++++++++++++
> > net/core/skbuff.c | 20 +++++++-
> > net/core/xdp.c | 14 ++++--
> > net/tls/tls_device.c | 2 +-
> > 13 files changed, 138 insertions(+), 26 deletions(-)
>
> Just for the reference, I've performed some tests on 1G SoC NIC with
> this patchset on, here's direct link: [0]
>

Thanks for the testing!
Any chance you can get a perf measurement on this?
Is DMA syncing taking a substantial amount of your cpu usage?

Thanks
/Ilias

> > --
> > 2.30.2
>
> [0] https://lore.kernel.org/netdev/[email protected]
>
> Thanks,
> Al
>

2021-03-23 16:33:13

[permalink] [raw]

Subject: Re: [PATCH net-next 0/6] page_pool: recycle buffers

On Tue, Mar 23, 2021 at 5:10 PM Ilias Apalodimas
<[email protected]> wrote:
>
> On Tue, Mar 23, 2021 at 05:04:47PM +0100, Jesper Dangaard Brouer wrote:
> > On Tue, 23 Mar 2021 17:47:46 +0200
> > Ilias Apalodimas <[email protected]> wrote:
> >
> > > On Tue, Mar 23, 2021 at 03:41:23PM +0000, Alexander Lobakin wrote:
> > > > From: Matteo Croce <[email protected]>
> > > > Date: Mon, 22 Mar 2021 18:02:55 +0100
> > > >
> > > > > From: Matteo Croce <[email protected]>
> > > > >
> > > > > This series enables recycling of the buffers allocated with the page_pool API.
> > > > > The first two patches are just prerequisite to save space in a struct and
> > > > > avoid recycling pages allocated with other API.
> > > > > Patch 2 was based on a previous idea from Jonathan Lemon.
> > > > >
> > > > > The third one is the real recycling, 4 fixes the compilation of __skb_frag_unref
> > > > > users, and 5,6 enable the recycling on two drivers.
> > > > >
> > > > > In the last two patches I reported the improvement I have with the series.
> > > > >
> > > > > The recycling as is can't be used with drivers like mlx5 which do page split,
> > > > > but this is documented in a comment.
> > > > > In the future, a refcount can be used so to support mlx5 with no changes.
> > > > >
> > > > > Ilias Apalodimas (2):
> > > > > page_pool: DMA handling and allow to recycles frames via SKB
> > > > > net: change users of __skb_frag_unref() and add an extra argument
> > > > >
> > > > > Jesper Dangaard Brouer (1):
> > > > > xdp: reduce size of struct xdp_mem_info
> > > > >
> > > > > Matteo Croce (3):
> > > > > mm: add a signature in struct page
> > > > > mvpp2: recycle buffers
> > > > > mvneta: recycle buffers
> > > > >
> > > > > .../chelsio/inline_crypto/ch_ktls/chcr_ktls.c | 2 +-
> > > > > drivers/net/ethernet/marvell/mvneta.c | 4 +-
> > > > > .../net/ethernet/marvell/mvpp2/mvpp2_main.c | 17 +++----
> > > > > drivers/net/ethernet/marvell/sky2.c | 2 +-
> > > > > drivers/net/ethernet/mellanox/mlx4/en_rx.c | 2 +-
> > > > > include/linux/mm_types.h | 1 +
> > > > > include/linux/skbuff.h | 33 +++++++++++--
> > > > > include/net/page_pool.h | 15 ++++++
> > > > > include/net/xdp.h | 5 +-
> > > > > net/core/page_pool.c | 47 +++++++++++++++++++
> > > > > net/core/skbuff.c | 20 +++++++-
> > > > > net/core/xdp.c | 14 ++++--
> > > > > net/tls/tls_device.c | 2 +-
> > > > > 13 files changed, 138 insertions(+), 26 deletions(-)
> > > >
> > > > Just for the reference, I've performed some tests on 1G SoC NIC with
> > > > this patchset on, here's direct link: [0]
> > > >
> > >
> > > Thanks for the testing!
> > > Any chance you can get a perf measurement on this?
> >
> > I guess you mean perf-report (--stdio) output, right?
> >
>
> Yea,
> As hinted below, I am just trying to figure out if on Alexander's platform the
> cost of syncing, is bigger that free-allocate. I remember one armv7 were that
> was the case.
>
> > > Is DMA syncing taking a substantial amount of your cpu usage?
> >
> > (+1 this is an important question)
> >
> > > >
> > > > [0] https://lore.kernel.org/netdev/[email protected]
> > > >
> >

That would be the same as for mvneta:

Overhead Shared Object Symbol
24.10% [kernel] [k] __pi___inval_dcache_area
23.02% [mvneta] [k] mvneta_rx_swbm
7.19% [kernel] [k] kmem_cache_alloc

Anyway, I tried to use the recycling *and* napi_build_skb on mvpp2,
and I get lower packet rate than recycling alone.
I don't know why, we should investigate it.

Regards,
--
per aspera ad upstream

2021-03-23 16:57:17

[permalink] [raw]

Subject: Re: [PATCH net-next 0/6] page_pool: recycle buffers

From: Matteo Croce <[email protected]>
Date: Tue, 23 Mar 2021 17:28:32 +0100

> On Tue, Mar 23, 2021 at 5:10 PM Ilias Apalodimas
> <[email protected]> wrote:
> >
> > On Tue, Mar 23, 2021 at 05:04:47PM +0100, Jesper Dangaard Brouer wrote:
> > > On Tue, 23 Mar 2021 17:47:46 +0200
> > > Ilias Apalodimas <[email protected]> wrote:
> > >
> > > > On Tue, Mar 23, 2021 at 03:41:23PM +0000, Alexander Lobakin wrote:
> > > > > From: Matteo Croce <[email protected]>
> > > > > Date: Mon, 22 Mar 2021 18:02:55 +0100
> > > > >
> > > > > > From: Matteo Croce <[email protected]>
> > > > > >
> > > > > > This series enables recycling of the buffers allocated with the page_pool API.
> > > > > > The first two patches are just prerequisite to save space in a struct and
> > > > > > avoid recycling pages allocated with other API.
> > > > > > Patch 2 was based on a previous idea from Jonathan Lemon.
> > > > > >
> > > > > > The third one is the real recycling, 4 fixes the compilation of __skb_frag_unref
> > > > > > users, and 5,6 enable the recycling on two drivers.
> > > > > >
> > > > > > In the last two patches I reported the improvement I have with the series.
> > > > > >
> > > > > > The recycling as is can't be used with drivers like mlx5 which do page split,
> > > > > > but this is documented in a comment.
> > > > > > In the future, a refcount can be used so to support mlx5 with no changes.
> > > > > >
> > > > > > Ilias Apalodimas (2):
> > > > > > page_pool: DMA handling and allow to recycles frames via SKB
> > > > > > net: change users of __skb_frag_unref() and add an extra argument
> > > > > >
> > > > > > Jesper Dangaard Brouer (1):
> > > > > > xdp: reduce size of struct xdp_mem_info
> > > > > >
> > > > > > Matteo Croce (3):
> > > > > > mm: add a signature in struct page
> > > > > > mvpp2: recycle buffers
> > > > > > mvneta: recycle buffers
> > > > > >
> > > > > > .../chelsio/inline_crypto/ch_ktls/chcr_ktls.c | 2 +-
> > > > > > drivers/net/ethernet/marvell/mvneta.c | 4 +-
> > > > > > .../net/ethernet/marvell/mvpp2/mvpp2_main.c | 17 +++----
> > > > > > drivers/net/ethernet/marvell/sky2.c | 2 +-
> > > > > > drivers/net/ethernet/mellanox/mlx4/en_rx.c | 2 +-
> > > > > > include/linux/mm_types.h | 1 +
> > > > > > include/linux/skbuff.h | 33 +++++++++++--
> > > > > > include/net/page_pool.h | 15 ++++++
> > > > > > include/net/xdp.h | 5 +-
> > > > > > net/core/page_pool.c | 47 +++++++++++++++++++
> > > > > > net/core/skbuff.c | 20 +++++++-
> > > > > > net/core/xdp.c | 14 ++++--
> > > > > > net/tls/tls_device.c | 2 +-
> > > > > > 13 files changed, 138 insertions(+), 26 deletions(-)
> > > > >
> > > > > Just for the reference, I've performed some tests on 1G SoC NIC with
> > > > > this patchset on, here's direct link: [0]
> > > > >
> > > >
> > > > Thanks for the testing!
> > > > Any chance you can get a perf measurement on this?
> > >
> > > I guess you mean perf-report (--stdio) output, right?
> > >
> >
> > Yea,
> > As hinted below, I am just trying to figure out if on Alexander's platform the
> > cost of syncing, is bigger that free-allocate. I remember one armv7 were that
> > was the case.
> >
> > > > Is DMA syncing taking a substantial amount of your cpu usage?
> > >
> > > (+1 this is an important question)

Sure, I'll drop perf tools to my test env and share the results,
maybe tomorrow or in a few days.
From what I know for sure about MIPS and my platform,
post-Rx synching (dma_sync_single_for_cpu()) is a no-op, and
pre-Rx (dma_sync_single_for_device() etc.) is a bit expensive.
I always have sane page_pool->pp.max_len value (smth about 1668
for MTU of 1500) to minimize the overhead.

By the word, IIRC, all machines shipped with mvpp2 have hardware
cache coherency units and don't suffer from sync routines at all.
That may be the reason why mvpp2 wins the most from this series.

> > > > >
> > > > > [0] https://lore.kernel.org/netdev/[email protected]
> > > > >
> > >
>
> That would be the same as for mvneta:
>
> Overhead Shared Object Symbol
> 24.10% [kernel] [k] __pi___inval_dcache_area
> 23.02% [mvneta] [k] mvneta_rx_swbm
> 7.19% [kernel] [k] kmem_cache_alloc
>
> Anyway, I tried to use the recycling *and* napi_build_skb on mvpp2,
> and I get lower packet rate than recycling alone.
> I don't know why, we should investigate it.

mvpp2 driver doesn't use napi_consume_skb() on its Tx completion path.
As a result, NAPI percpu caches get refilled only through
kmem_cache_alloc_bulk(), and most of skbuff_head recycling
doesn't work.

> Regards,
> --
> per aspera ad upstream

Oh, I love that one!

Al

2021-03-23 17:04:32

[permalink] [raw]

Subject: Re: [PATCH net-next 0/6] page_pool: recycle buffers

On Tue, Mar 23, 2021 at 04:55:31PM +0000, Alexander Lobakin wrote:
> > > > > >

[...]

> > > > >
> > > > > Thanks for the testing!
> > > > > Any chance you can get a perf measurement on this?
> > > >
> > > > I guess you mean perf-report (--stdio) output, right?
> > > >
> > >
> > > Yea,
> > > As hinted below, I am just trying to figure out if on Alexander's platform the
> > > cost of syncing, is bigger that free-allocate. I remember one armv7 were that
> > > was the case.
> > >
> > > > > Is DMA syncing taking a substantial amount of your cpu usage?
> > > >
> > > > (+1 this is an important question)
>
> Sure, I'll drop perf tools to my test env and share the results,
> maybe tomorrow or in a few days.
> From what I know for sure about MIPS and my platform,
> post-Rx synching (dma_sync_single_for_cpu()) is a no-op, and
> pre-Rx (dma_sync_single_for_device() etc.) is a bit expensive.
> I always have sane page_pool->pp.max_len value (smth about 1668
> for MTU of 1500) to minimize the overhead.
>
> By the word, IIRC, all machines shipped with mvpp2 have hardware
> cache coherency units and don't suffer from sync routines at all.
> That may be the reason why mvpp2 wins the most from this series.

Yep exactly. It's also the reason why you explicitly have to opt-in using the
recycling (by marking the skb for it), instead of hiding the feature in the
page pool internals

Cheers
/Ilias

>
> > > > > >
> > > > > > [0] https://lore.kernel.org/netdev/[email protected]
> > > > > >
> > > >
> >
> > That would be the same as for mvneta:
> >
> > Overhead Shared Object Symbol
> > 24.10% [kernel] [k] __pi___inval_dcache_area
> > 23.02% [mvneta] [k] mvneta_rx_swbm
> > 7.19% [kernel] [k] kmem_cache_alloc
> >
> > Anyway, I tried to use the recycling *and* napi_build_skb on mvpp2,
> > and I get lower packet rate than recycling alone.
> > I don't know why, we should investigate it.
>
> mvpp2 driver doesn't use napi_consume_skb() on its Tx completion path.
> As a result, NAPI percpu caches get refilled only through
> kmem_cache_alloc_bulk(), and most of skbuff_head recycling
> doesn't work.
>
> > Regards,
> > --
> > per aspera ad upstream
>
> Oh, I love that one!
>
> Al
>

2021-03-23 20:05:45

[permalink] [raw]

Subject: Re: [PATCH net-next 0/6] page_pool: recycle buffers

From: Ilias Apalodimas <[email protected]>
Date: Tue, 23 Mar 2021 19:01:52 +0200

> On Tue, Mar 23, 2021 at 04:55:31PM +0000, Alexander Lobakin wrote:
> > > > > > >
>
> [...]
>
> > > > > >
> > > > > > Thanks for the testing!
> > > > > > Any chance you can get a perf measurement on this?
> > > > >
> > > > > I guess you mean perf-report (--stdio) output, right?
> > > > >
> > > >
> > > > Yea,
> > > > As hinted below, I am just trying to figure out if on Alexander's platform the
> > > > cost of syncing, is bigger that free-allocate. I remember one armv7 were that
> > > > was the case.
> > > >
> > > > > > Is DMA syncing taking a substantial amount of your cpu usage?
> > > > >
> > > > > (+1 this is an important question)
> >
> > Sure, I'll drop perf tools to my test env and share the results,
> > maybe tomorrow or in a few days.

Oh we-e-e-ell...
Looks like I've been fooled by I-cache misses or smth like that.
That happens sometimes, not only on my machines, and not only on
MIPS if I'm not mistaken.
Sorry for confusing you guys.

I got drastically different numbers after I enabled CONFIG_KALLSYMS +
CONFIG_PERF_EVENTS for perf tools.
The only difference in code is that I rebased onto Mel's
mm-bulk-rebase-v6r4.

(lunar is my WIP NIC driver)

1. 5.12-rc3 baseline:

TCP: 566 Mbps
UDP: 615 Mbps

perf top:
4.44% [lunar] [k] lunar_rx_poll_page_pool
3.56% [kernel] [k] r4k_wait_irqoff
2.89% [kernel] [k] free_unref_page
2.57% [kernel] [k] dma_map_page_attrs
2.32% [kernel] [k] get_page_from_freelist
2.28% [lunar] [k] lunar_start_xmit
1.82% [kernel] [k] __copy_user
1.75% [kernel] [k] dev_gro_receive
1.52% [kernel] [k] cpuidle_enter_state_coupled
1.46% [kernel] [k] tcp_gro_receive
1.35% [kernel] [k] __rmemcpy
1.33% [nf_conntrack] [k] nf_conntrack_tcp_packet
1.30% [kernel] [k] __dev_queue_xmit
1.22% [kernel] [k] pfifo_fast_dequeue
1.17% [kernel] [k] skb_release_data
1.17% [kernel] [k] skb_segment

free_unref_page() and get_page_from_freelist() consume a lot.

2. 5.12-rc3 + Page Pool recycling by Matteo:
TCP: 589 Mbps
UDP: 633 Mbps

perf top:
4.27% [lunar] [k] lunar_rx_poll_page_pool
2.68% [lunar] [k] lunar_start_xmit
2.41% [kernel] [k] dma_map_page_attrs
1.92% [kernel] [k] r4k_wait_irqoff
1.89% [kernel] [k] __copy_user
1.62% [kernel] [k] dev_gro_receive
1.51% [kernel] [k] cpuidle_enter_state_coupled
1.44% [kernel] [k] tcp_gro_receive
1.40% [kernel] [k] __rmemcpy
1.38% [nf_conntrack] [k] nf_conntrack_tcp_packet
1.37% [kernel] [k] free_unref_page
1.35% [kernel] [k] __dev_queue_xmit
1.30% [kernel] [k] skb_segment
1.28% [kernel] [k] get_page_from_freelist
1.27% [kernel] [k] r4k_dma_cache_inv

+20 Mbps increase on both TCP and UDP. free_unref_page() and
get_page_from_freelist() dropped down the list significantly.

3. 5.12-rc3 + Page Pool recycling + PP bulk allocator (Mel & Jesper):
TCP: 596
UDP: 641

perf top:
4.38% [lunar] [k] lunar_rx_poll_page_pool
3.34% [kernel] [k] r4k_wait_irqoff
3.14% [kernel] [k] dma_map_page_attrs
2.49% [lunar] [k] lunar_start_xmit
1.85% [kernel] [k] dev_gro_receive
1.76% [kernel] [k] free_unref_page
1.76% [kernel] [k] __copy_user
1.65% [kernel] [k] inet_gro_receive
1.57% [kernel] [k] tcp_gro_receive
1.48% [kernel] [k] cpuidle_enter_state_coupled
1.43% [nf_conntrack] [k] nf_conntrack_tcp_packet
1.42% [kernel] [k] __rmemcpy
1.25% [kernel] [k] skb_segment
1.21% [kernel] [k] r4k_dma_cache_inv

+10 Mbps on top of recycling.
get_page_from_freelist() is gone.
NAPI polling, CPU idle cycle (r4k_wait_irqoff) and DMA mapping
routine became the top consumers.

4-5. __always_inline for rmqueue_bulk() and __rmqueue_pcplist(),
removing 'noinline' from net/core/page_pool.c etc.

...makes absolutely no sense anymore.
I see Mel took Jesper's patch to make __rmqueue_pcplist() inline into
mm-bulk-rebase-v6r5, not sure if it's really needed now.

So I'm really glad we sorted out the things and I can see the real
performance improvements from both recycling and bulk allocations.

> > From what I know for sure about MIPS and my platform,
> > post-Rx synching (dma_sync_single_for_cpu()) is a no-op, and
> > pre-Rx (dma_sync_single_for_device() etc.) is a bit expensive.
> > I always have sane page_pool->pp.max_len value (smth about 1668
> > for MTU of 1500) to minimize the overhead.
> >
> > By the word, IIRC, all machines shipped with mvpp2 have hardware
> > cache coherency units and don't suffer from sync routines at all.
> > That may be the reason why mvpp2 wins the most from this series.
>
> Yep exactly. It's also the reason why you explicitly have to opt-in using the
> recycling (by marking the skb for it), instead of hiding the feature in the
> page pool internals
>
> Cheers
> /Ilias
>
> >
> > > > > > >
> > > > > > > [0] https://lore.kernel.org/netdev/[email protected]
> > > > > > >
> > > > >
> > >
> > > That would be the same as for mvneta:
> > >
> > > Overhead Shared Object Symbol
> > > 24.10% [kernel] [k] __pi___inval_dcache_area
> > > 23.02% [mvneta] [k] mvneta_rx_swbm
> > > 7.19% [kernel] [k] kmem_cache_alloc
> > >
> > > Anyway, I tried to use the recycling *and* napi_build_skb on mvpp2,
> > > and I get lower packet rate than recycling alone.
> > > I don't know why, we should investigate it.
> >
> > mvpp2 driver doesn't use napi_consume_skb() on its Tx completion path.
> > As a result, NAPI percpu caches get refilled only through
> > kmem_cache_alloc_bulk(), and most of skbuff_head recycling
> > doesn't work.
> >
> > > Regards,
> > > --
> > > per aspera ad upstream
> >
> > Oh, I love that one!
> >
> > Al
> >

Thanks,
Al

2021-03-24 05:38:01

by Jesper Dangaard Brouer

[permalink] [raw]

Subject: Re: [PATCH net-next 0/6] page_pool: recycle buffers

On Tue, 23 Mar 2021 17:47:46 +0200
Ilias Apalodimas <[email protected]> wrote:

> On Tue, Mar 23, 2021 at 03:41:23PM +0000, Alexander Lobakin wrote:
> > From: Matteo Croce <[email protected]>
> > Date: Mon, 22 Mar 2021 18:02:55 +0100
> >
> > > From: Matteo Croce <[email protected]>
> > >
> > > This series enables recycling of the buffers allocated with the page_pool API.
> > > The first two patches are just prerequisite to save space in a struct and
> > > avoid recycling pages allocated with other API.
> > > Patch 2 was based on a previous idea from Jonathan Lemon.
> > >
> > > The third one is the real recycling, 4 fixes the compilation of __skb_frag_unref
> > > users, and 5,6 enable the recycling on two drivers.
> > >
> > > In the last two patches I reported the improvement I have with the series.
> > >
> > > The recycling as is can't be used with drivers like mlx5 which do page split,
> > > but this is documented in a comment.
> > > In the future, a refcount can be used so to support mlx5 with no changes.
> > >
> > > Ilias Apalodimas (2):
> > > page_pool: DMA handling and allow to recycles frames via SKB
> > > net: change users of __skb_frag_unref() and add an extra argument
> > >
> > > Jesper Dangaard Brouer (1):
> > > xdp: reduce size of struct xdp_mem_info
> > >
> > > Matteo Croce (3):
> > > mm: add a signature in struct page
> > > mvpp2: recycle buffers
> > > mvneta: recycle buffers
> > >
> > > .../chelsio/inline_crypto/ch_ktls/chcr_ktls.c | 2 +-
> > > drivers/net/ethernet/marvell/mvneta.c | 4 +-
> > > .../net/ethernet/marvell/mvpp2/mvpp2_main.c | 17 +++----
> > > drivers/net/ethernet/marvell/sky2.c | 2 +-
> > > drivers/net/ethernet/mellanox/mlx4/en_rx.c | 2 +-
> > > include/linux/mm_types.h | 1 +
> > > include/linux/skbuff.h | 33 +++++++++++--
> > > include/net/page_pool.h | 15 ++++++
> > > include/net/xdp.h | 5 +-
> > > net/core/page_pool.c | 47 +++++++++++++++++++
> > > net/core/skbuff.c | 20 +++++++-
> > > net/core/xdp.c | 14 ++++--
> > > net/tls/tls_device.c | 2 +-
> > > 13 files changed, 138 insertions(+), 26 deletions(-)
> >
> > Just for the reference, I've performed some tests on 1G SoC NIC with
> > this patchset on, here's direct link: [0]
> >
>
> Thanks for the testing!
> Any chance you can get a perf measurement on this?

I guess you mean perf-report (--stdio) output, right?

> Is DMA syncing taking a substantial amount of your cpu usage?

(+1 this is an important question)

> >
> > [0] https://lore.kernel.org/netdev/[email protected]
> >

--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer

2021-03-24 05:46:14

[permalink] [raw]

Subject: Re: [PATCH net-next 0/6] page_pool: recycle buffers

On Tue, Mar 23, 2021 at 05:04:47PM +0100, Jesper Dangaard Brouer wrote:
> On Tue, 23 Mar 2021 17:47:46 +0200
> Ilias Apalodimas <[email protected]> wrote:
>
> > On Tue, Mar 23, 2021 at 03:41:23PM +0000, Alexander Lobakin wrote:
> > > From: Matteo Croce <[email protected]>
> > > Date: Mon, 22 Mar 2021 18:02:55 +0100
> > >
> > > > From: Matteo Croce <[email protected]>
> > > >
> > > > This series enables recycling of the buffers allocated with the page_pool API.
> > > > The first two patches are just prerequisite to save space in a struct and
> > > > avoid recycling pages allocated with other API.
> > > > Patch 2 was based on a previous idea from Jonathan Lemon.
> > > >
> > > > The third one is the real recycling, 4 fixes the compilation of __skb_frag_unref
> > > > users, and 5,6 enable the recycling on two drivers.
> > > >
> > > > In the last two patches I reported the improvement I have with the series.
> > > >
> > > > The recycling as is can't be used with drivers like mlx5 which do page split,
> > > > but this is documented in a comment.
> > > > In the future, a refcount can be used so to support mlx5 with no changes.
> > > >
> > > > Ilias Apalodimas (2):
> > > > page_pool: DMA handling and allow to recycles frames via SKB
> > > > net: change users of __skb_frag_unref() and add an extra argument
> > > >
> > > > Jesper Dangaard Brouer (1):
> > > > xdp: reduce size of struct xdp_mem_info
> > > >
> > > > Matteo Croce (3):
> > > > mm: add a signature in struct page
> > > > mvpp2: recycle buffers
> > > > mvneta: recycle buffers
> > > >
> > > > .../chelsio/inline_crypto/ch_ktls/chcr_ktls.c | 2 +-
> > > > drivers/net/ethernet/marvell/mvneta.c | 4 +-
> > > > .../net/ethernet/marvell/mvpp2/mvpp2_main.c | 17 +++----
> > > > drivers/net/ethernet/marvell/sky2.c | 2 +-
> > > > drivers/net/ethernet/mellanox/mlx4/en_rx.c | 2 +-
> > > > include/linux/mm_types.h | 1 +
> > > > include/linux/skbuff.h | 33 +++++++++++--
> > > > include/net/page_pool.h | 15 ++++++
> > > > include/net/xdp.h | 5 +-
> > > > net/core/page_pool.c | 47 +++++++++++++++++++
> > > > net/core/skbuff.c | 20 +++++++-
> > > > net/core/xdp.c | 14 ++++--
> > > > net/tls/tls_device.c | 2 +-
> > > > 13 files changed, 138 insertions(+), 26 deletions(-)
> > >
> > > Just for the reference, I've performed some tests on 1G SoC NIC with
> > > this patchset on, here's direct link: [0]
> > >
> >
> > Thanks for the testing!
> > Any chance you can get a perf measurement on this?
>
> I guess you mean perf-report (--stdio) output, right?
>

Yea,
As hinted below, I am just trying to figure out if on Alexander's platform the
cost of syncing, is bigger that free-allocate. I remember one armv7 were that
was the case.

> > Is DMA syncing taking a substantial amount of your cpu usage?
>
> (+1 this is an important question)
>
> > >
> > > [0] https://lore.kernel.org/netdev/[email protected]
> > >
>
> --
> Best regards,
> Jesper Dangaard Brouer
> MSc.CS, Principal Kernel Engineer at Red Hat
> LinkedIn: http://www.linkedin.com/in/brouer
>

2021-03-24 12:21:18

[permalink] [raw]

Subject: Re: [PATCH net-next 0/6] page_pool: recycle buffers

From: Ilias Apalodimas <[email protected]>
Date: Wed, 24 Mar 2021 09:50:38 +0200

> Hi Alexander,

Hi!

> On Tue, Mar 23, 2021 at 08:03:46PM +0000, Alexander Lobakin wrote:
> > From: Ilias Apalodimas <[email protected]>
> > Date: Tue, 23 Mar 2021 19:01:52 +0200
> >
> > > On Tue, Mar 23, 2021 at 04:55:31PM +0000, Alexander Lobakin wrote:
> > > > > > > > >
> > >
> > > [...]
> > >
> > > > > > > >
> > > > > > > > Thanks for the testing!
> > > > > > > > Any chance you can get a perf measurement on this?
> > > > > > >
> > > > > > > I guess you mean perf-report (--stdio) output, right?
> > > > > > >
> > > > > >
> > > > > > Yea,
> > > > > > As hinted below, I am just trying to figure out if on Alexander's platform the
> > > > > > cost of syncing, is bigger that free-allocate. I remember one armv7 were that
> > > > > > was the case.
> > > > > >
> > > > > > > > Is DMA syncing taking a substantial amount of your cpu usage?
> > > > > > >
> > > > > > > (+1 this is an important question)
> > > >
> > > > Sure, I'll drop perf tools to my test env and share the results,
> > > > maybe tomorrow or in a few days.
> >
> > Oh we-e-e-ell...
> > Looks like I've been fooled by I-cache misses or smth like that.
> > That happens sometimes, not only on my machines, and not only on
> > MIPS if I'm not mistaken.
> > Sorry for confusing you guys.
> >
> > I got drastically different numbers after I enabled CONFIG_KALLSYMS +
> > CONFIG_PERF_EVENTS for perf tools.
> > The only difference in code is that I rebased onto Mel's
> > mm-bulk-rebase-v6r4.
> >
> > (lunar is my WIP NIC driver)
> >
> > 1. 5.12-rc3 baseline:
> >
> > TCP: 566 Mbps
> > UDP: 615 Mbps
> >
> > perf top:
> > 4.44% [lunar] [k] lunar_rx_poll_page_pool
> > 3.56% [kernel] [k] r4k_wait_irqoff
> > 2.89% [kernel] [k] free_unref_page
> > 2.57% [kernel] [k] dma_map_page_attrs
> > 2.32% [kernel] [k] get_page_from_freelist
> > 2.28% [lunar] [k] lunar_start_xmit
> > 1.82% [kernel] [k] __copy_user
> > 1.75% [kernel] [k] dev_gro_receive
> > 1.52% [kernel] [k] cpuidle_enter_state_coupled
> > 1.46% [kernel] [k] tcp_gro_receive
> > 1.35% [kernel] [k] __rmemcpy
> > 1.33% [nf_conntrack] [k] nf_conntrack_tcp_packet
> > 1.30% [kernel] [k] __dev_queue_xmit
> > 1.22% [kernel] [k] pfifo_fast_dequeue
> > 1.17% [kernel] [k] skb_release_data
> > 1.17% [kernel] [k] skb_segment
> >
> > free_unref_page() and get_page_from_freelist() consume a lot.
> >
> > 2. 5.12-rc3 + Page Pool recycling by Matteo:
> > TCP: 589 Mbps
> > UDP: 633 Mbps
> >
> > perf top:
> > 4.27% [lunar] [k] lunar_rx_poll_page_pool
> > 2.68% [lunar] [k] lunar_start_xmit
> > 2.41% [kernel] [k] dma_map_page_attrs
> > 1.92% [kernel] [k] r4k_wait_irqoff
> > 1.89% [kernel] [k] __copy_user
> > 1.62% [kernel] [k] dev_gro_receive
> > 1.51% [kernel] [k] cpuidle_enter_state_coupled
> > 1.44% [kernel] [k] tcp_gro_receive
> > 1.40% [kernel] [k] __rmemcpy
> > 1.38% [nf_conntrack] [k] nf_conntrack_tcp_packet
> > 1.37% [kernel] [k] free_unref_page
> > 1.35% [kernel] [k] __dev_queue_xmit
> > 1.30% [kernel] [k] skb_segment
> > 1.28% [kernel] [k] get_page_from_freelist
> > 1.27% [kernel] [k] r4k_dma_cache_inv
> >
> > +20 Mbps increase on both TCP and UDP. free_unref_page() and
> > get_page_from_freelist() dropped down the list significantly.
> >
> > 3. 5.12-rc3 + Page Pool recycling + PP bulk allocator (Mel & Jesper):
> > TCP: 596
> > UDP: 641
> >
> > perf top:
> > 4.38% [lunar] [k] lunar_rx_poll_page_pool
> > 3.34% [kernel] [k] r4k_wait_irqoff
> > 3.14% [kernel] [k] dma_map_page_attrs
> > 2.49% [lunar] [k] lunar_start_xmit
> > 1.85% [kernel] [k] dev_gro_receive
> > 1.76% [kernel] [k] free_unref_page
> > 1.76% [kernel] [k] __copy_user
> > 1.65% [kernel] [k] inet_gro_receive
> > 1.57% [kernel] [k] tcp_gro_receive
> > 1.48% [kernel] [k] cpuidle_enter_state_coupled
> > 1.43% [nf_conntrack] [k] nf_conntrack_tcp_packet
> > 1.42% [kernel] [k] __rmemcpy
> > 1.25% [kernel] [k] skb_segment
> > 1.21% [kernel] [k] r4k_dma_cache_inv
> >
> > +10 Mbps on top of recycling.
> > get_page_from_freelist() is gone.
> > NAPI polling, CPU idle cycle (r4k_wait_irqoff) and DMA mapping
> > routine became the top consumers.
>
> Again, thanks for the extensive testing.
> I assume you dont use page pool to map the buffers right?
> Because if the ampping is preserved the only thing you have to do is sync it
> after the packet reception

No, I use Page Pool for both DMA mapping and synching for device.
The reason why DMA mapping takes a lot of CPU is that I test NATing,
so NIC firstly receives the frames and then xmits them with modified
headers -> this DMA map overhead is from lunar_start_xmit(), not
Rx path.
The actual Rx synching is r4k_dma_cache_inv() and it's not that
expensive.

> >
> > 4-5. __always_inline for rmqueue_bulk() and __rmqueue_pcplist(),
> > removing 'noinline' from net/core/page_pool.c etc.
> >
> > ...makes absolutely no sense anymore.
> > I see Mel took Jesper's patch to make __rmqueue_pcplist() inline into
> > mm-bulk-rebase-v6r5, not sure if it's really needed now.
> >
> > So I'm really glad we sorted out the things and I can see the real
> > performance improvements from both recycling and bulk allocations.
> >
>
> Those will probably be even bigger with and io(sm)/mu present

Sure, DMA mapping is way more expensive through IOMMUs. I don't have
one on my boards, so can't collect any useful info.

> [...]
>
> Cheers
> /Ilias

Thanks,
Al

2021-03-25 01:32:47

[permalink] [raw]

Subject: Re: [PATCH net-next 0/6] page_pool: recycle buffers

Hi Alexander,

On Tue, Mar 23, 2021 at 08:03:46PM +0000, Alexander Lobakin wrote:
> From: Ilias Apalodimas <[email protected]>
> Date: Tue, 23 Mar 2021 19:01:52 +0200
>
> > On Tue, Mar 23, 2021 at 04:55:31PM +0000, Alexander Lobakin wrote:
> > > > > > > >
> >
> > [...]
> >
> > > > > > >
> > > > > > > Thanks for the testing!
> > > > > > > Any chance you can get a perf measurement on this?
> > > > > >
> > > > > > I guess you mean perf-report (--stdio) output, right?
> > > > > >
> > > > >
> > > > > Yea,
> > > > > As hinted below, I am just trying to figure out if on Alexander's platform the
> > > > > cost of syncing, is bigger that free-allocate. I remember one armv7 were that
> > > > > was the case.
> > > > >
> > > > > > > Is DMA syncing taking a substantial amount of your cpu usage?
> > > > > >
> > > > > > (+1 this is an important question)
> > >
> > > Sure, I'll drop perf tools to my test env and share the results,
> > > maybe tomorrow or in a few days.
>
> Oh we-e-e-ell...
> Looks like I've been fooled by I-cache misses or smth like that.
> That happens sometimes, not only on my machines, and not only on
> MIPS if I'm not mistaken.
> Sorry for confusing you guys.
>
> I got drastically different numbers after I enabled CONFIG_KALLSYMS +
> CONFIG_PERF_EVENTS for perf tools.
> The only difference in code is that I rebased onto Mel's
> mm-bulk-rebase-v6r4.
>
> (lunar is my WIP NIC driver)
>
> 1. 5.12-rc3 baseline:
>
> TCP: 566 Mbps
> UDP: 615 Mbps
>
> perf top:
> 4.44% [lunar] [k] lunar_rx_poll_page_pool
> 3.56% [kernel] [k] r4k_wait_irqoff
> 2.89% [kernel] [k] free_unref_page
> 2.57% [kernel] [k] dma_map_page_attrs
> 2.32% [kernel] [k] get_page_from_freelist
> 2.28% [lunar] [k] lunar_start_xmit
> 1.82% [kernel] [k] __copy_user
> 1.75% [kernel] [k] dev_gro_receive
> 1.52% [kernel] [k] cpuidle_enter_state_coupled
> 1.46% [kernel] [k] tcp_gro_receive
> 1.35% [kernel] [k] __rmemcpy
> 1.33% [nf_conntrack] [k] nf_conntrack_tcp_packet
> 1.30% [kernel] [k] __dev_queue_xmit
> 1.22% [kernel] [k] pfifo_fast_dequeue
> 1.17% [kernel] [k] skb_release_data
> 1.17% [kernel] [k] skb_segment
>
> free_unref_page() and get_page_from_freelist() consume a lot.
>
> 2. 5.12-rc3 + Page Pool recycling by Matteo:
> TCP: 589 Mbps
> UDP: 633 Mbps
>
> perf top:
> 4.27% [lunar] [k] lunar_rx_poll_page_pool
> 2.68% [lunar] [k] lunar_start_xmit
> 2.41% [kernel] [k] dma_map_page_attrs
> 1.92% [kernel] [k] r4k_wait_irqoff
> 1.89% [kernel] [k] __copy_user
> 1.62% [kernel] [k] dev_gro_receive
> 1.51% [kernel] [k] cpuidle_enter_state_coupled
> 1.44% [kernel] [k] tcp_gro_receive
> 1.40% [kernel] [k] __rmemcpy
> 1.38% [nf_conntrack] [k] nf_conntrack_tcp_packet
> 1.37% [kernel] [k] free_unref_page
> 1.35% [kernel] [k] __dev_queue_xmit
> 1.30% [kernel] [k] skb_segment
> 1.28% [kernel] [k] get_page_from_freelist
> 1.27% [kernel] [k] r4k_dma_cache_inv
>
> +20 Mbps increase on both TCP and UDP. free_unref_page() and
> get_page_from_freelist() dropped down the list significantly.
>
> 3. 5.12-rc3 + Page Pool recycling + PP bulk allocator (Mel & Jesper):
> TCP: 596
> UDP: 641
>
> perf top:
> 4.38% [lunar] [k] lunar_rx_poll_page_pool
> 3.34% [kernel] [k] r4k_wait_irqoff
> 3.14% [kernel] [k] dma_map_page_attrs
> 2.49% [lunar] [k] lunar_start_xmit
> 1.85% [kernel] [k] dev_gro_receive
> 1.76% [kernel] [k] free_unref_page
> 1.76% [kernel] [k] __copy_user
> 1.65% [kernel] [k] inet_gro_receive
> 1.57% [kernel] [k] tcp_gro_receive
> 1.48% [kernel] [k] cpuidle_enter_state_coupled
> 1.43% [nf_conntrack] [k] nf_conntrack_tcp_packet
> 1.42% [kernel] [k] __rmemcpy
> 1.25% [kernel] [k] skb_segment
> 1.21% [kernel] [k] r4k_dma_cache_inv
>
> +10 Mbps on top of recycling.
> get_page_from_freelist() is gone.
> NAPI polling, CPU idle cycle (r4k_wait_irqoff) and DMA mapping
> routine became the top consumers.

Again, thanks for the extensive testing.
I assume you dont use page pool to map the buffers right?
Because if the ampping is preserved the only thing you have to do is sync it
after the packet reception

>
> 4-5. __always_inline for rmqueue_bulk() and __rmqueue_pcplist(),
> removing 'noinline' from net/core/page_pool.c etc.
>
> ...makes absolutely no sense anymore.
> I see Mel took Jesper's patch to make __rmqueue_pcplist() inline into
> mm-bulk-rebase-v6r5, not sure if it's really needed now.
>
> So I'm really glad we sorted out the things and I can see the real
> performance improvements from both recycling and bulk allocations.
>

Those will probably be even bigger with and io(sm)/mu present

[...]

Cheers
/Ilias

2021-03-25 02:15:58

by Lorenzo Bianconi

[permalink] [raw]

Subject: Re: [PATCH net-next 6/6] mvneta: recycle buffers

[...]
> > diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
> > index a635cf84608a..8b3250394703 100644
> > --- a/drivers/net/ethernet/marvell/mvneta.c
> > +++ b/drivers/net/ethernet/marvell/mvneta.c
> > @@ -2332,7 +2332,7 @@ mvneta_swbm_build_skb(struct mvneta_port *pp, struct mvneta_rx_queue *rxq,
> > if (!skb)
> > return ERR_PTR(-ENOMEM);
> >
> > - page_pool_release_page(rxq->page_pool, virt_to_page(xdp->data));
> > + skb_mark_for_recycle(skb, virt_to_page(xdp->data), &xdp->rxq->mem);
> >
> > skb_reserve(skb, xdp->data - xdp->data_hard_start);
> > skb_put(skb, xdp->data_end - xdp->data);
> > @@ -2344,7 +2344,7 @@ mvneta_swbm_build_skb(struct mvneta_port *pp, struct mvneta_rx_queue *rxq,
> > skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags,
> > skb_frag_page(frag), skb_frag_off(frag),
> > skb_frag_size(frag), PAGE_SIZE);
> > - page_pool_release_page(rxq->page_pool, skb_frag_page(frag));
> > + skb_mark_for_recycle(skb, skb_frag_page(frag), &xdp->rxq->mem);
> > }
> >
> > return skb;
>
> This cause skb_mark_for_recycle() to set 'skb->pp_recycle=1' multiple
> times, for the same SKB. (copy-pasted function below signature to help
> reviewers).
>
> This makes me question if we need an API for setting this per page
> fragment?
> Or if the API skb_mark_for_recycle() need to walk the page fragments in
> the SKB and set the info stored in the page for each?

Considering just performances, I guess it is better open-code here since the
driver already performs a loop over fragments to build the skb, but I guess
this approach is quite risky and I would prefer to have a single utility
routine to take care of linear area + fragments. What do you think?

Regards,
Lorenzo

>
>
> --
> Best regards,
> Jesper Dangaard Brouer
> MSc.CS, Principal Kernel Engineer at Red Hat
> LinkedIn: http://www.linkedin.com/in/brouer
>

Attachments:

(No filename) (1.92 kB)
signature.asc (235.00 B)
Download all attachments

2021-03-25 03:31:44