On Sat, Sep 9, 2017 at 10:23 AM, Jamal Hadi Salim <j...@mojatatu.com> wrote: > On 17-09-09 12:24 PM, Roopa Prabhu wrote: >> >> On Fri, Sep 8, 2017 at 2:52 PM, Roman Mashak <m...@mojatatu.com> wrote: >>> >>> Signed-off-by: Roman Mashak <m...@mojatatu.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;
yes, its a bit messy and redundant. > yet at the same time my wireless card events are also showing up on the > bridge link even though it is not enslaved there.. that is strange. It should not.