From: Roman Mashak <mrv@mojatatu.com>
To: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Cc: Roopa Prabhu <roopa@cumulusnetworks.com>,
"stephen\@networkplumber.org" <stephen@networkplumber.org>,
"netdev\@vger.kernel.org" <netdev@vger.kernel.org>,
Jamal Hadi Salim <jhs@mojatatu.com>
Subject: Re: [PATCH iproute2 3/3] bridge: request vlans along with link information
Date: Sun, 10 Sep 2017 14:18:47 -0400 [thread overview]
Message-ID: <85poayquwo.fsf@mojatatu.com> (raw)
In-Reply-To: <93aaf641-5063-e5d2-799c-718c85ca60a5@cumulusnetworks.com> (Nikolay Aleksandrov's message of "Sun, 10 Sep 2017 17:21:48 +0300")
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> writes:
> On 10/09/17 16:38, Roman Mashak wrote:
[...]
>> 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).
Yes, I understand it, I was referring to link events in the previous
comment. However, why not to report compressed vlans for GETLINK by
default if show_details is true, this would be consistent with events monitor.
It seems to be more clear and intuitive from the user's perspective, the
same set of command line options for \monitor' or 'show' commands.
> 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.
>>
>> [...]
>>
next prev parent reply other threads:[~2017-09-10 18:18 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-08 21:52 [PATCH iproute2 0/3] Process IFLA_BRIDGE_VLAN_INFO tlv Roman Mashak
2017-09-08 21:52 ` [PATCH iproute2 1/3] bridge: isolate vlans parsing code in a separate API Roman Mashak
2017-09-08 21:52 ` [PATCH iproute2 2/3] bridge: dump vlan table information for link Roman Mashak
2017-09-08 21:52 ` [PATCH iproute2 3/3] bridge: request vlans along with link information Roman Mashak
2017-09-09 16:24 ` Roopa Prabhu
2017-09-09 17:23 ` Jamal Hadi Salim
2017-09-09 18:15 ` Nikolay Aleksandrov
2017-09-10 5:28 ` Roopa Prabhu
2017-09-10 5:26 ` Roopa Prabhu
2017-09-10 10:24 ` Nikolay Aleksandrov
2017-09-10 13:38 ` Roman Mashak
2017-09-10 14:21 ` Nikolay Aleksandrov
2017-09-10 18:18 ` Roman Mashak [this message]
2017-09-10 18:36 ` Nikolay Aleksandrov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=85poayquwo.fsf@mojatatu.com \
--to=mrv@mojatatu.com \
--cc=jhs@mojatatu.com \
--cc=netdev@vger.kernel.org \
--cc=nikolay@cumulusnetworks.com \
--cc=roopa@cumulusnetworks.com \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).