[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <beb8ec07-f28e-4378-e8dd-fa6fe290377b@gmail.com>
Date: Mon, 26 Aug 2019 18:17:08 -0600
From: David Ahern <dsahern@...il.com>
To: David Miller <davem@...emloft.net>
Cc: jakub.kicinski@...ronome.com, jiri@...nulli.us,
roopa@...ulusnetworks.com, netdev@...r.kernel.org,
sthemmin@...rosoft.com, dcbw@...hat.com, mkubecek@...e.cz,
andrew@...n.ch, parav@...lanox.com, saeedm@...lanox.com,
mlxsw@...lanox.com
Subject: Re: [patch net-next rfc 3/7] net: rtnetlink: add commands to add and
delete alternative ifnames
On 8/26/19 4:25 PM, David Miller wrote:
> From: David Ahern <dsahern@...il.com>
> Date: Mon, 26 Aug 2019 16:24:38 -0600
>
>> On 8/26/19 4:18 PM, David Miller wrote:
>>> I honestly think that the size of link dumps are out of hand as-is.
>>
>> so you are suggesting new alternate names should not appear in kernel
>> generated RTM_NEWLINK messages - be it a link dump or a notification on
>> a change?
>
> I counter with the question of how much crap can we keep sticking in there
> before we have to do something else to provide that information?
>
Something a bit stand alone would be a better choice - like all of the
VF stuff, stats, per-device type configuration. Yes, that ship has
sailed, but as I recall that is where the overhead is.
An attribute as basic as a name is the wrong place for that split.
Powered by blists - more mailing lists