[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 9 Sep 2017 13:23:19 -0400
From: Jamal Hadi Salim <jhs@...atatu.com>
To: Roopa Prabhu <roopa@...ulusnetworks.com>,
Roman Mashak <mrv@...atatu.com>
Cc: "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 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>
>> ---
>> bridge/link.c | 16 +++++++++++++---
>> 1 file changed, 13 insertions(+), 3 deletions(-)
>>
>> diff --git a/bridge/link.c b/bridge/link.c
>> index 60200f1..9e4206f 100644
>> --- a/bridge/link.c
>> +++ b/bridge/link.c
>> @@ -461,9 +461,19 @@ static int brlink_show(int argc, char **argv)
>> }
>> }
>>
>> - if (rtnl_wilddump_request(&rth, PF_BRIDGE, RTM_GETLINK) < 0) {
>> - perror("Cannon send dump request");
>> - exit(1);
>> + if (show_details) {
>> + if (rtnl_wilddump_req_filter(&rth, PF_BRIDGE, RTM_GETLINK,
>> + (compress_vlans ?
>> + RTEXT_FILTER_BRVLAN_COMPRESSED :
>> + RTEXT_FILTER_BRVLAN)) < 0) {
>> + perror("Cannon send dump request");
>> + exit(1);
>> + }
>
> 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.
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.
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.
In general, the XXXLINK interface with these master devices (bridge,
bond etc) continues to get messy. Recently started seeing events with
devices claiming to be of KIND_slave etc on the bridge and bond devices;
yet at the same time my wireless card events are also showing up on the
bridge link even though it is not enslaved there..
cheers,
jamal
> Can you please paste a sample default detailed output with your patch
> with a few hundred vlans ?
>
Powered by blists - more mailing lists