[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210118131528.72e194d6@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date: Mon, 18 Jan 2021 13:15:28 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Christian Brauner <christian.brauner@...ntu.com>
Cc: menglong8.dong@...il.com, davem@...emloft.net,
yoshfuji@...ux-ipv6.org, dong.menglong@....com.cn,
daniel@...earbox.net, gnault@...hat.com, ast@...nel.org,
nicolas.dichtel@...nd.com, ap420073@...il.com, edumazet@...gle.com,
pabeni@...hat.com, jakub@...udflare.com, bjorn.topel@...el.com,
keescook@...omium.org, viro@...iv.linux.org.uk, rdna@...com,
maheshb@...gle.com, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next] net: core: Namespace-ify sysctl_wmem_default
and sysctl_rmem_default
On Mon, 18 Jan 2021 12:15:18 +0100 Christian Brauner wrote:
> On Sun, Jan 17, 2021 at 06:23:19PM +0800, menglong8.dong@...il.com wrote:
> > From: Menglong Dong <dong.menglong@....com.cn>
> >
> > For now, sysctl_wmem_default and sysctl_rmem_default are globally
> > unified. It's not convenient in some case. For example, when we
> > use docker and try to control the default udp socket receive buffer
> > for each container.
> >
> > For that reason, make sysctl_wmem_default and sysctl_rmem_default
> > per-namespace.
> >
> > Signed-off-by: Menglong Dong <dong.menglong@....com.cn>
> > ---
>
> Hey Menglong,
>
> I was about to review the two patches you sent:
>
> 1. [PATCH net-next] net: core: Namespace-ify sysctl_rmem_max and sysctl_wmem_max
> https://lore.kernel.org/lkml/20210117104743.217194-1-dong.menglong@zte.com.cn
> 2. [PATCH net-next] net: core: Namespace-ify sysctl_wmem_default and sysctl_rmem_default
> https://lore.kernel.org/lkml/20210117102319.193756-1-dong.menglong@zte.com.cn
And perhaps
0. [PATCH net-next] net: core: init every ctl_table in netns_core_table
?
I'm dropping these three from patchwork please follow Christian
suggestions on how to repost properly, thanks!
> and I had to spend some time figuring out that 2. is dependent on 1. I
> first thought I got the base wrong.
>
> I'd suggest you resend both patches as a part of a single series with a
> cover letter mentioning the goal and use-case for these changes and also
> pass --base=<base-commit>
> when creating the patch series which makes it way easier to figure out
> what to apply it to when wanting to review a series in the larger
> context of a tree.
Powered by blists - more mailing lists