On Tue, Mar 7, 2023 at 10:55 PM Paolo Abeni <pabeni@xxxxxxxxxx> wrote: > > On Tue, 2023-03-07 at 09:56 +0800, Jason Xing wrote: > > From: Jason Xing <kernelxing@xxxxxxxxxxx> > > > > 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@xxxxxxxxx/ > > Signed-off-by: Jason Xing <kernelxing@xxxxxxxxxxx> > > --- > > 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 >
