On 10/09/17 16:38, Roman Mashak wrote:
> Roopa Prabhu <ro...@cumulusnetworks.com> writes:
>
>> 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 ?
>
> 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.
>
> [...]
>
