netdev - Re: [PATCH net-next] skbuff: Optimize SKB coalescing for page pool case

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZJySdw+RTl5CHSEy@corigine.com>
Date:   Wed, 28 Jun 2023 22:05:11 +0200
From:   Simon Horman <simon.horman@...igine.com>
To:     Liang Chen <liangchen.linux@...il.com>
Cc:     ilias.apalodimas@...aro.org, hawk@...nel.org, kuba@...nel.org,
        davem@...emloft.net, edumazet@...gle.com, pabeni@...hat.com,
        linyunsheng@...wei.com, netdev@...r.kernel.org
Subject: Re: [PATCH net-next] skbuff: Optimize SKB coalescing for page pool
 case

On Wed, Jun 28, 2023 at 08:11:50PM +0800, Liang Chen wrote:
> In order to address the issues encountered with commit 1effe8ca4e34
> ("skbuff: fix coalescing for page_pool fragment recycling"), the
> combination of the following condition was excluded from skb coalescing:
> 
> from->pp_recycle = 1
> from->cloned = 1
> to->pp_recycle = 1
> 
> However, with page pool environments, the aforementioned combination can
> be quite common. In scenarios with a higher number of small packets, it
> can significantly affect the success rate of coalescing. For example,
> when considering packets of 256 bytes size, our comparison of coalescing
> success rate is as follows:
> 
> Without page pool: 70%
> With page pool: 13%
> 
> Consequently, this has an impact on performance:
> 
> Without page pool: 2.64 Gbits/sec
> With page pool: 2.41 Gbits/sec
> 
> Therefore, it seems worthwhile to optimize this scenario and enable
> coalescing of this particular combination. To achieve this, we need to
> ensure the correct increment of the "from" SKB page's page pool fragment
> count (pp_frag_count).
> 
> Following this optimization, the success rate of coalescing measured in our
> environment has improved as follows:
> 
> With page pool: 60%
> 
> This success rate is approaching the rate achieved without using page pool,
> and the performance has also been improved:
> 
> With page pool: 2.61 Gbits/sec
> 
> Below is the performance comparison for small packets before and after this
> optimization. We observe no impact to packets larger than 4K.
> 
> without page pool fragment(PP_FLAG_PAGE_FRAG)
> packet size     before      after
> (bytes)         (Gbits/sec) (Gbits/sec)
> 128             1.28        1.37
> 256             2.41        2.61
> 512             4.56        4.87
> 1024            7.69        8.21
> 2048            12.85       13.41
> 
> with page pool fragment(PP_FLAG_PAGE_FRAG)
> packet size     before      after
> (bytes)         (Gbits/sec) (Gbits/sec)
> 128             1.28        1.37
> 256             2.35        2.62
> 512             4.37        4.86
> 1024            7.62        8.41
> 2048            13.07       13.53
> 
> with page pool fragment(PP_FLAG_PAGE_FRAG) and high order(order = 3)
> packet size     before      after
> (bytes)         (Gbits/sec) (Gbits/sec)
> 128             1.28        1.41
> 256             2.41        2.74
> 512             4.57        5.25
> 1024            8.61        9.71
> 2048            14.81       16.78
> 
> Signed-off-by: Liang Chen <liangchen.linux@...il.com>

Hi Liang Chen,

Please consider running checkpatch.pl --strict over this patch.

But, more importantly:

[text from Jakub]

## Form letter - net-next-closed

The merge window for v6.5 has begun and therefore net-next is closed
for new drivers, features, code refactoring and optimizations.
We are currently accepting bug fixes only.

Please repost when net-next reopens after July 10th.

RFC patches sent for review only are obviously welcome at any time.

See: https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#development-cycle
--
pw-bot: defer