[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABAhCOSvhUZE_FE4xFsOimzVBQpQYLNk51uYNLw+46fibzfM2Q@mail.gmail.com>
Date: Fri, 8 Nov 2024 00:53:55 +0800
From: Xiao Liang <shaw.leon@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Eric Dumazet <edumazet@...gle.com>, netdev@...r.kernel.org,
linux-kselftest@...r.kernel.org, Kuniyuki Iwashima <kuniyu@...zon.com>,
"David S. Miller" <davem@...emloft.net>, David Ahern <dsahern@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, Ido Schimmel <idosch@...dia.com>,
Andrew Lunn <andrew+netdev@...n.ch>, Simon Horman <horms@...nel.org>,
Donald Hunter <donald.hunter@...il.com>, Shuah Khan <shuah@...nel.org>,
Jiri Pirko <jiri@...nulli.us>, Hangbin Liu <liuhangbin@...il.com>
Subject: Re: [PATCH net-next v2 5/8] net: ip_gre: Add netns_atomic module parameter
On Thu, Nov 7, 2024 at 11:59 PM Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Thu, 7 Nov 2024 22:11:24 +0800 Xiao Liang wrote:
> > > Instead, add new rtnetlink attributes ?
> >
> > It is to control driver behavior at rtnl_ops registration time. I
> > think rtnetlink
> > attributes are too late for that, maybe? Can't think of a way other than
> > module parameters or register separate ops. Any suggestions?
>
> Step back from the implementation you have a little, forget that there
> is a boolean in rtnl_link_ops. User makes a request to spawn an
> interface, surely a flag inside that request can dictate how the netns
> attrs are interpreted.
IMO, this is about driver capability, not about user requests.
As you've pointed out earlier, probably no one would actually want
the old behavior whenever the driver supports the new one.
I added the module parameter just for compatibility, because ip_tunnels
was not implemented to support src_net properly. Yes it's possible to
add an extra flag in user request, but I don't think it's a good approach.
BTW, I didn't find what's going on with module parameters, is there
any documentation?
Thanks.
Powered by blists - more mailing lists