From: Jesper Dangaard Brouer <hawk@kernel.org>
To: Andrew Kanner <andrew.kanner@gmail.com>,
Jason Wang <jasowang@redhat.com>
Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, netdev@vger.kernel.org, dsahern@gmail.com,
jbrouer@redhat.com, john.fastabend@gmail.com,
linux-kernel@vger.kernel.org,
linux-kernel-mentees@lists.linuxfoundation.org,
syzbot+f817490f5bd20541b90a@syzkaller.appspotmail.com,
Alexander Duyck <alexander.duyck@gmail.com>
Subject: Re: [PATCH v4 1/2] drivers: net: prevent tun_build_skb() to exceed the packet size limit
Date: Fri, 4 Aug 2023 11:30:03 +0200 [thread overview]
Message-ID: <224e100b-6874-2993-a743-0a93ca0201fd@kernel.org> (raw)
In-Reply-To: <64cbe991.190a0220.b646b.04c1@mx.google.com>
On 03/08/2023 19.53, Andrew Kanner wrote:
>>> Question to Jason Wang:
>>> Why fall back (to e.g. tun_alloc_skb()) when size is above PAGE_SIZE?
>>>
>>> AFAIK tun_build_skb()*can* create get larger packets than PAGE_SIZE
>>> from it's page_frag. Is there a reason for this limitation?
>> >> I couldn't recall but I think we can relax.
> > Jesper already sent enough info for this idea in v2, I will use it for
> the next patch/series.
>
I have some more input and considerations when selecting the new
constant that replace PAGE_SIZE.
Lets see if Eric Dumazet or Alex Duyck disagree?
("inventors" of page_frag scheme)
The function tun_alloc_skb() uses a page_frag scheme for allocation.
The maximim size is 32768 bytes (Order-3), but using something that is
close to this max alloc size can cause memory waste and fragmentation.
My suggestion would be to use the constant SKB_MAX_ALLOC (16KiB).
Maybe Eric or Alex would recommend using something smaller? (e.g. 8192)
page_frag limit comes from:
#define SKB_FRAG_PAGE_ORDER get_order(32768)
> Jesper, I will add this tag for this next patch/series if you don't
> mind:
> Suggested-by: Jesper Dangaard Brouer <hawk@kernel.org>
ACK
prev parent reply other threads:[~2023-08-04 9:30 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-01 22:07 Andrew Kanner
2023-08-01 22:07 ` [PATCH v4 2/2] net: core: remove unnecessary frame_sz check in bpf_xdp_adjust_tail() Andrew Kanner
2023-08-02 13:56 ` Jesper Dangaard Brouer
2023-08-03 3:20 ` Jason Wang
2023-08-03 18:06 ` Andrew Kanner
2023-08-02 1:07 ` [PATCH v4 1/2] drivers: net: prevent tun_build_skb() to exceed the packet size limit David Ahern
2023-08-02 12:16 ` Andrew Kanner
2023-08-02 14:13 ` Jesper Dangaard Brouer
2023-08-03 3:19 ` Jason Wang
2023-08-03 17:53 ` Andrew Kanner
2023-08-04 9:30 ` Jesper Dangaard Brouer [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=224e100b-6874-2993-a743-0a93ca0201fd@kernel.org \
--to=hawk@kernel.org \
--cc=alexander.duyck@gmail.com \
--cc=andrew.kanner@gmail.com \
--cc=davem@davemloft.net \
--cc=dsahern@gmail.com \
--cc=edumazet@google.com \
--cc=jasowang@redhat.com \
--cc=jbrouer@redhat.com \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel-mentees@lists.linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=syzbot+f817490f5bd20541b90a@syzkaller.appspotmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®