[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJieiUhOof4P4FNkxmpQ9BvotNJBuEsAz2Tq4gvZpfgYdhMj1Q@mail.gmail.com>
Date: Sat, 9 Sep 2017 22:28:00 -0700
From: Roopa Prabhu <roopa@...ulusnetworks.com>
To: Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
Cc: Jamal Hadi Salim <jhs@...atatu.com>,
Roman Mashak <mrv@...atatu.com>,
"stephen@...workplumber.org" <stephen@...workplumber.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH iproute2 3/3] bridge: request vlans along with link information
On Sat, Sep 9, 2017 at 11:15 AM, Nikolay Aleksandrov
<nikolay@...ulusnetworks.com> wrote:
> On 09/09/17 20:23, Jamal Hadi Salim wrote:
>> On 17-09-09 12:24 PM, Roopa Prabhu wrote:
>>> On Fri, Sep 8, 2017 at 2:52 PM, Roman Mashak <mrv@...atatu.com> wrote:
>>>> Signed-off-by: Roman Mashak <mrv@...atatu.com>
>>>> ---
>
[snip]
>>>
>>> vlan information is already available with `bridge vlan show`. any
>>> specific reason why you want it in
>>> the link dump output ?
>>>
>>>
>>> The problem is this might just make the link dump larger and also add
>>> too much clutter into the regular link dump output. iproute2 detailed
>>> dump is already a bit hard to interpret. And without compression by
>>> default, vlan info can just take over the link dump output. It will be
>>> hard to look for other link attributes after that :). We deploy with
>>> thousands of vlans and without compression even bridge vlan default
>>> output is already hard to interpret.
>>>
>>
>> Agree we should be turning on this stuff by default. i.e default stays
>> compressed; otherwise it a huge dump.
>
> I think this should be dumped with the getlink request only on some additional
> flag. The getlink does not include these by default.
>
>>
>> Having said that there is a lot of mess with this stuff.
>> The bridge link events _already send this IFLA_AF_SPCE info_
>> so not much choice there but to print it.
>
> Right, on NEWLINK per port notification you'll get the compressed vlan info.
>
>> At minimal we need that part because unfortunately there is no
>> vlanfilter event in existence which will send us summaries of just
>> vlans added to a port i.e both use XXXLINK.
>
> But let's either add a new flag or use -compressvlans to print it when monitoring/showing
> link otherwise people who are monitoring only the port flags will start getting lists
> with vlans. Even compressed these can still be quite long and confusing, especially
> when monitoring.
yes agree. It will add too much clutter to the monitor output too.
Powered by blists - more mailing lists