Message ID | 20230307015620.18301-1-kerneljasonxing@gmail.com (mailing list archive) |
---|---|
State | Superseded |
Delegated to: | Netdev Maintainers |
Headers | show |
Series | [v3,net-next] udp: introduce __sk_mem_schedule() usage | expand |
On Tue, 2023-03-07 at 09:56 +0800, Jason Xing wrote: > From: Jason Xing <kernelxing@tencent.com> > > Keep the accounting schema consistent across different protocols > with __sk_mem_schedule(). Besides, it adjusts a little bit on how > to calculate forward allocated memory compared to before. After > applied this patch, we could avoid receive path scheduling extra > amount of memory. > > Link: https://lore.kernel.org/lkml/20230221110344.82818-1-kerneljasonxing@gmail.com/ > Signed-off-by: Jason Xing <kernelxing@tencent.com> > --- > v3: > 1) get rid of inline suggested by Simon Horman > > v2: > 1) change the title and body message > 2) use __sk_mem_schedule() instead suggested by Paolo Abeni > --- > net/ipv4/udp.c | 31 ++++++++++++++++++------------- > 1 file changed, 18 insertions(+), 13 deletions(-) > > diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c > index c605d171eb2d..60473781933c 100644 > --- a/net/ipv4/udp.c > +++ b/net/ipv4/udp.c > @@ -1531,10 +1531,23 @@ static void busylock_release(spinlock_t *busy) > spin_unlock(busy); > } > > +static int udp_rmem_schedule(struct sock *sk, int size) > +{ > + int delta; > + > + delta = size - sk->sk_forward_alloc; > + if (delta > 0 && !__sk_mem_schedule(sk, delta, SK_MEM_RECV)) > + return -ENOBUFS; > + > + sk->sk_forward_alloc -= size; I think it's better if you maintain the above statement outside of this helper: it's a bit confusing that rmem_schedule() actually consumes fwd memory. Side note Cheers, Paolo
On Tue, Mar 7, 2023 at 10:55 PM Paolo Abeni <pabeni@redhat.com> wrote: > > On Tue, 2023-03-07 at 09:56 +0800, Jason Xing wrote: > > From: Jason Xing <kernelxing@tencent.com> > > > > Keep the accounting schema consistent across different protocols > > with __sk_mem_schedule(). Besides, it adjusts a little bit on how > > to calculate forward allocated memory compared to before. After > > applied this patch, we could avoid receive path scheduling extra > > amount of memory. > > > > Link: https://lore.kernel.org/lkml/20230221110344.82818-1-kerneljasonxing@gmail.com/ > > Signed-off-by: Jason Xing <kernelxing@tencent.com> > > --- > > v3: > > 1) get rid of inline suggested by Simon Horman > > > > v2: > > 1) change the title and body message > > 2) use __sk_mem_schedule() instead suggested by Paolo Abeni > > --- > > net/ipv4/udp.c | 31 ++++++++++++++++++------------- > > 1 file changed, 18 insertions(+), 13 deletions(-) > > > > diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c > > index c605d171eb2d..60473781933c 100644 > > --- a/net/ipv4/udp.c > > +++ b/net/ipv4/udp.c > > @@ -1531,10 +1531,23 @@ static void busylock_release(spinlock_t *busy) > > spin_unlock(busy); > > } > > > > +static int udp_rmem_schedule(struct sock *sk, int size) > > +{ > > + int delta; > > + > > + delta = size - sk->sk_forward_alloc; > > + if (delta > 0 && !__sk_mem_schedule(sk, delta, SK_MEM_RECV)) > > + return -ENOBUFS; > > + > > + sk->sk_forward_alloc -= size; > > I think it's better if you maintain the above statement outside of this > helper: it's a bit confusing that rmem_schedule() actually consumes fwd > memory. It does make sense. Thanks, Jason > > Side note > > Cheers, > > Paolo >
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c index c605d171eb2d..60473781933c 100644 --- a/net/ipv4/udp.c +++ b/net/ipv4/udp.c @@ -1531,10 +1531,23 @@ static void busylock_release(spinlock_t *busy) spin_unlock(busy); } +static int udp_rmem_schedule(struct sock *sk, int size) +{ + int delta; + + delta = size - sk->sk_forward_alloc; + if (delta > 0 && !__sk_mem_schedule(sk, delta, SK_MEM_RECV)) + return -ENOBUFS; + + sk->sk_forward_alloc -= size; + + return 0; +} + int __udp_enqueue_schedule_skb(struct sock *sk, struct sk_buff *skb) { struct sk_buff_head *list = &sk->sk_receive_queue; - int rmem, delta, amt, err = -ENOMEM; + int rmem, err = -ENOMEM; spinlock_t *busy = NULL; int size; @@ -1567,20 +1580,12 @@ int __udp_enqueue_schedule_skb(struct sock *sk, struct sk_buff *skb) goto uncharge_drop; spin_lock(&list->lock); - if (size >= sk->sk_forward_alloc) { - amt = sk_mem_pages(size); - delta = amt << PAGE_SHIFT; - if (!__sk_mem_raise_allocated(sk, delta, amt, SK_MEM_RECV)) { - err = -ENOBUFS; - spin_unlock(&list->lock); - goto uncharge_drop; - } - - sk->sk_forward_alloc += delta; + err = udp_rmem_schedule(sk, size); + if (err) { + spin_unlock(&list->lock); + goto uncharge_drop; } - sk->sk_forward_alloc -= size; - /* no need to setup a destructor, we will explicitly release the * forward allocated memory on dequeue */