Re: [PATCH iproute2 3/3] bridge: request vlans along with link information

On 10/09/17 16:38, Roman Mashak wrote:

Roopa Prabhu [off-list ref] writes:

quoted

On Fri, Sep 8, 2017 at 2:52 PM, Roman Mashak [off-list ref] wrote:

quoted

Signed-off-by: Roman Mashak <redacted>
---
 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 ?

Since VLAN info is already in link messages, there is no other option but
dump it in monitor or "bridge link show". Yes, the output may be lengthy

To make sure there's no misunderstanding - on GETLINK the vlan info is _not_
dumped by default (not compressed or otherwise).
It is only dumped compressed on port notifications, that is why I suggested to
use the already present flag (-compressvlans, -c) in order to include that info
when monitoring or dumping link info, so people watching for the port flags
(show_details) would not suddenly start getting a lot more and it makes sense
to dump it only on specific request.

and hard to digest for a human, that is why I put it under "show_details"
kludge - if one is requesting details, he/she should be prepared for
large volumes of data to be shown :)

As Nikolay suggested, it'll make sense to request compressed
output by default, this will be addresses in v2 patch.

[...]