On Tue, 2023-06-20 at 15:53 +0100, David Howells wrote:
> Display information about the memory handling MSG_SPLICE_PAGES does to copy
> slabbed data into page fragments.
>
> For each CPU that has a cached folio, it displays the folio pfn, the offset
> pointer within the folio and the size of the folio.
>
> It also displays the number of pages refurbished and the number of pages
> replaced.
>
> Signed-off-by: David Howells <dhowells@xxxxxxxxxx>
> cc: Alexander Duyck <alexander.duyck@xxxxxxxxx>
> cc: Eric Dumazet <edumazet@xxxxxxxxxx>
> cc: "David S. Miller" <davem@xxxxxxxxxxxxx>
> cc: David Ahern <dsahern@xxxxxxxxxx>
> cc: Jakub Kicinski <kuba@xxxxxxxxxx>
> cc: Paolo Abeni <pabeni@xxxxxxxxxx>
> cc: Jens Axboe <axboe@xxxxxxxxx>
> cc: Matthew Wilcox <willy@xxxxxxxxxxxxx>
> cc: Menglong Dong <imagedong@xxxxxxxxxxx>
> cc: netdev@xxxxxxxxxxxxxxx
> ---
> net/core/skbuff.c | 42 +++++++++++++++++++++++++++++++++++++++---
> 1 file changed, 39 insertions(+), 3 deletions(-)
>
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index d962c93a429d..36605510a76d 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -83,6 +83,7 @@
> #include <linux/user_namespace.h>
> #include <linux/indirect_call_wrapper.h>
> #include <linux/textsearch.h>
> +#include <linux/proc_fs.h>
>
> #include "dev.h"
> #include "sock_destructor.h"
> @@ -6758,6 +6759,7 @@ nodefer: __kfree_skb(skb);
> struct skb_splice_frag_cache {
> struct folio *folio;
> void *virt;
> + unsigned int fsize;
> unsigned int offset;
> /* we maintain a pagecount bias, so that we dont dirty cache line
> * containing page->_refcount every time we allocate a fragment.
> @@ -6767,6 +6769,26 @@ struct skb_splice_frag_cache {
> };
>
> static DEFINE_PER_CPU(struct skb_splice_frag_cache, skb_splice_frag_cache);
> +static atomic_t skb_splice_frag_replaced, skb_splice_frag_refurbished;
(in case we don't agree to restrict this series to just remove
MSG_SENDPAGE_NOTLAST)
Have you considered percpu counters instead of the above atomics?
I think the increments are in not so unlikely code-paths, and the
contention there could possibly hurt performances.
Thanks,
Paolo
