Messages in this thread | | | Date | Tue, 01 Aug 2023 09:14:08 -0400 | From | Willem de Bruijn <> | Subject | Re: [PATCH v2] tun: avoid high-order page allocation for packet header |
| |
Eric Dumazet wrote: > On Tue, Aug 1, 2023 at 11:37 AM Eric Dumazet <edumazet@google.com> wrote: > > > > On Tue, Aug 1, 2023 at 1:07 AM Tahsin Erdogan <trdgn@amazon.com> wrote: > > > > > > When GSO is not enabled and a packet is transmitted via writev(), all > > > payload is treated as header which requires a contiguous memory allocation. > > > This allocation request is harder to satisfy, and may even fail if there is > > > enough fragmentation. > > > > > > Note that sendmsg() code path limits the linear copy length, so this change > > > makes writev() and sendmsg() more consistent. > > > > > > Signed-off-by: Tahsin Erdogan <trdgn@amazon.com> > > > --- > > > > I will have to tweak one existing packetdrill test, nothing major. > > > > Tested-by: Eric Dumazet <edumazet@google.com> > > Reviewed-by: Eric Dumazet <edumazet@google.com> > > I have to take this back, sorry. > > We need to change alloc_skb_with_frags() and tun.c to attempt > high-order allocations, > otherwise tun users sending very large buffers will regress. > (Even if this _could_ fail as you pointed out if memory is tight/fragmented) > > I am working to make the change in alloc_skb_with_frags() and in tun, > we can apply your patch after this prereq.
This exactly same allocation logic also exists in packet_alloc_skb and tap_alloc_skb. If changing one of them, perhaps should address convert all at the same time, to keep behavior consistent.
| |