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:

quoted

On 2/22/22 5:26 PM, Jakub Kicinski wrote:

quoted

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.

quoted

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 :)