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]

Message-ID: <7184c4eb-7378-5ce3-f24e-4a8e9344aa87@nvidia.com>
Date:   Tue, 22 Feb 2022 22:31:18 -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 7:50 PM, Jakub Kicinski wrote:
> On Tue, 22 Feb 2022 18:49:03 -0800 Roopa Prabhu wrote:
>> On 2/22/22 5:26 PM, Jakub Kicinski wrote:
>>> 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.
> Makes sense. I wasn't quite sure if this isn't over-engineering
>   - do deployments really use VxLAN devs with many VNIs?


yes, vnis are unfortunately used to stretch layer 2 domains exceeding 
the 4k vlan limit

In the example provided in this series, vnis can be deployed in the 
ranges of more than 15k if each customer is allocated a 4k vlan range 
(bridge domain),

and a single switch can host 3-4 customers.

the scale is also the reason to switch to dst metadata devices when 
deployed vni numbers get large. The traditional vxlan netdev per vni 
does not work well at this scale.



>
>> 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
> Ack, I don't have any better ideas either :)