Re: [PATCH] net: micro-optimize skb_datagram_iter

On Wed, Jun 19, 2024 at 4:51 PM Eric Dumazet [off-list ref] wrote:

On Wed, Jun 19, 2024 at 3:54 PM Sagi Grimberg [off-list ref] wrote:

quoted

On 19/06/2024 15:46, David Howells wrote:

quoted

Jakub Kicinski [off-list ref] wrote:

quoted

On Mon, 17 Jun 2024 09:29:53 +0300 Sagi Grimberg wrote:

quoted

quoted

Probably because kmap() returns page_address() for non-highmem pages
while kmap_local_page() actually returns a kmap address:

          if (!IS_ENABLED(CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP) && !PageHighMem(page))
                  return page_address(page);
          return __kmap_local_pfn_prot(page_to_pfn(page), prot);

so if skb frags are always lowmem (are they?) this is a false positive.

AFAIR these buffers are coming from the RX ring, so they should be
coming from a page_frag_cache,
so I want to say always low memory?

quoted

if they can be highmem, then you've uncovered a bug that nobody's
noticed because nobody's testing on 32-bit any more.

Not sure, Jakub? Eric?

My uneducated guess would be that until recent(ish) sendpage rework
from David Howells all high mem pages would have been single pages.

Um.  I touched the Tx side, not the Rx side.

I also don't know whether all high mem pages would be single pages.  I'll have
to defer that one to the MM folks.

What prevents from gro to expand frags from crossing PAGE_SIZE?

btw, at least from the code in skb_gro_receive() it appears that
page_address() is called directly,
which suggest that these netmem pages are lowmem?

GRO should only be fed with lowmem pages.

But the trace involves af_unix, not GRO ?

I guess that with splice games, it is possible to add high order pages to skbs.

I think skb_frag_foreach_page() could be used to fix this issue.

For reference, please look at

commit c613c209c3f351d47158f728271d0c73b6dd24c6
Author: Willem de Bruijn [off-list ref]
Date:   Mon Jul 31 08:15:47 2017 -0400

    net: add skb_frag_foreach_page and use with kmap_atomic