netdev - Re: [PATCH net-next v2 07/12] rtnetlink: add new rtm tunnel api for tunnel id filtering

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 22 Feb 2022 18:49:03 -0800
From:   Roopa Prabhu <roopa@...dia.com>
To:     Jakub Kicinski <kuba@...nel.org>
CC:     <davem@...emloft.net>, <netdev@...r.kernel.org>,
        <stephen@...workplumber.org>, <nikolay@...ulusnetworks.com>,
        <idosch@...dia.com>, <dsahern@...il.com>, <bpoirier@...dia.com>
Subject: Re: [PATCH net-next v2 07/12] rtnetlink: add new rtm tunnel api for
 tunnel id filtering


On 2/22/22 5:26 PM, Jakub Kicinski wrote:
> On Tue, 22 Feb 2022 02:52:25 +0000 Roopa Prabhu wrote:
>> +	RTM_NEWTUNNEL = 120,
>> +#define RTM_NEWTUNNEL	RTM_NEWTUNNEL
>> +	RTM_DELTUNNEL,
>> +#define RTM_DELTUNNEL	RTM_DELTUNNEL
>> +	RTM_GETTUNNEL,
>> +#define RTM_GETTUNNEL	RTM_GETTUNNEL
> Why create new RTM_ commands instead of using changelink?
>
> I thought we had to add special commands for bridge because
> if the target of the command is not a bridge device but possibly
> a bridge port, which could be anything. That's not the case here.
>
> Is it only about the convenience of add/del vs changelink where
> we'd potentially have to pass and parse the entire vni list each time?

yes, exactly. that's the reason. My first internal version used 
changelink and soon realized it was too limiting.

especially notifications. Its too heavy to notify the full vni list 
every-time.

IIRC bridge also went through a similar transition. Now bridge also has 
RTM_*VLAN commands.

Couldn't think of another way than adding a new msg. Tried to keep the 
name generic for use by potentially other dst/collect metadata devices