| Message ID | cover.1540910943.git.sbrivio@redhat.com |
|---|---|
| Headers | show |
| Series | ss: Allow selection of columns to be displayed | expand |
On 10/30/18 9:05 AM, Stefano Brivio wrote: > Now that we have an abstraction for columns, it's relatively easy to > selectively display only some of them, and Yoann has a use case for it. > > Patch 1/3 fixes a rendering issue that shows up only when display of > arbitrary columns is disabled. Patch 2/3 implements the relevant option, > and patch 3/3 makes the output more readable when some columns are > disabled. > > I like the intent, and I have prototyped something similar for 'ip'. A more flexible approach is to use format strings to allow users to customize the output order and whitespace as well. So for ss and your column list (winging it here): netid = %N state = %S recv Q = %Qr send Q = %Qs local address = %Al lport port = %Pl remote address = %Ar remote port = %Pr process data = %p ... then a format string could be: "%S %Qr %Qs %Al:%Pl %Ar:%Pr %p\n" or for csv output: "%S,%Qr,%Qs,%Al,%Pl,%Ar,%Pr,%p\n" I have not had time to look into an implementation for ip. Conceptually - and scanning the kernel's vsprintf code - it does not look that difficult, just time consuming on the frontend with the initial setup.
On Tue, 30 Oct 2018 10:34:45 -0600 David Ahern <dsahern@gmail.com> wrote: > On 10/30/18 9:05 AM, Stefano Brivio wrote: > > Now that we have an abstraction for columns, it's relatively easy to > > selectively display only some of them, and Yoann has a use case for it. > > > > Patch 1/3 fixes a rendering issue that shows up only when display of > > arbitrary columns is disabled. Patch 2/3 implements the relevant option, > > and patch 3/3 makes the output more readable when some columns are > > disabled. > > > > > > I like the intent, and I have prototyped something similar for 'ip'. > > A more flexible approach is to use format strings to allow users to > customize the output order and whitespace as well. So for ss and your > column list (winging it here): > > netid = %N > state = %S > recv Q = %Qr > send Q = %Qs > local address = %Al > lport port = %Pl > remote address = %Ar > remote port = %Pr > process data = %p > ... > > then a format string could be: "%S %Qr %Qs %Al:%Pl %Ar:%Pr %p\n" > > or for csv output: "%S,%Qr,%Qs,%Al,%Pl,%Ar,%Pr,%p\n" > > I have not had time to look into an implementation for ip. Conceptually > - and scanning the kernel's vsprintf code - it does not look that > difficult, just time consuming on the frontend with the initial setup. The problem with custom formats is that you lose all ability for Gcc to check format strings.
On 10/30/18 10:38 AM, Stephen Hemminger wrote: > On Tue, 30 Oct 2018 10:34:45 -0600 > David Ahern <dsahern@gmail.com> wrote: > >> On 10/30/18 9:05 AM, Stefano Brivio wrote: >>> Now that we have an abstraction for columns, it's relatively easy to >>> selectively display only some of them, and Yoann has a use case for it. >>> >>> Patch 1/3 fixes a rendering issue that shows up only when display of >>> arbitrary columns is disabled. Patch 2/3 implements the relevant option, >>> and patch 3/3 makes the output more readable when some columns are >>> disabled. >>> >>> >> >> I like the intent, and I have prototyped something similar for 'ip'. >> >> A more flexible approach is to use format strings to allow users to >> customize the output order and whitespace as well. So for ss and your >> column list (winging it here): >> >> netid = %N >> state = %S >> recv Q = %Qr >> send Q = %Qs >> local address = %Al >> lport port = %Pl >> remote address = %Ar >> remote port = %Pr >> process data = %p >> ... >> >> then a format string could be: "%S %Qr %Qs %Al:%Pl %Ar:%Pr %p\n" >> >> or for csv output: "%S,%Qr,%Qs,%Al,%Pl,%Ar,%Pr,%p\n" >> >> I have not had time to look into an implementation for ip. Conceptually >> - and scanning the kernel's vsprintf code - it does not look that >> difficult, just time consuming on the frontend with the initial setup. > > The problem with custom formats is that you lose all ability for Gcc > to check format strings. > Sure, trade-offs. A custom print string is powerful. While selecting columns is an improvement, column ordering is also important - even handling other output formats (csv).
On Tue, 30 Oct 2018 10:34:45 -0600 David Ahern <dsahern@gmail.com> wrote: > A more flexible approach is to use format strings to allow users to > customize the output order and whitespace as well. So for ss and your > column list (winging it here): > > netid = %N > state = %S > recv Q = %Qr > send Q = %Qs > local address = %Al > lport port = %Pl > remote address = %Ar > remote port = %Pr > process data = %p > ... > > then a format string could be: "%S %Qr %Qs %Al:%Pl %Ar:%Pr %p\n" I like the idea indeed, but I see two issues with ss: - the current column abstraction is rather lightweight, things are already buffered in the defined column order so we don't have to jump back and forth in the buffer while rendering. Doing that needs some extra care to avoid a performance hit, but it's probably doable, I can put that on my to-do list - how would you model automatic spacing in a format string? Should we support width specifiers? Disable automatic spacing if a format string is given? It might even make sense to allow partial automatic spacing with a special character in the format string, that is: "%S.%Qr.%Qs %Al:%Pl %Ar:%Pr %p\n" would mean "align everything to the right, distribute remaining whitespace between %S, %Qr and %Qs". But it looks rather complicated at a glance.
[ sorry, too many distractions and I forgot to respond ] On 10/30/18 11:34 AM, Stefano Brivio wrote: > On Tue, 30 Oct 2018 10:34:45 -0600 > David Ahern <dsahern@gmail.com> wrote: > >> A more flexible approach is to use format strings to allow users to >> customize the output order and whitespace as well. So for ss and your >> column list (winging it here): >> >> netid = %N >> state = %S >> recv Q = %Qr >> send Q = %Qs >> local address = %Al >> lport port = %Pl >> remote address = %Ar >> remote port = %Pr >> process data = %p >> ... >> >> then a format string could be: "%S %Qr %Qs %Al:%Pl %Ar:%Pr %p\n" > > I like the idea indeed, but I see two issues with ss: > > - the current column abstraction is rather lightweight, things are > already buffered in the defined column order so we don't have to jump > back and forth in the buffer while rendering. Doing that needs some > extra care to avoid a performance hit, but it's probably doable, I > can put that on my to-do list The ss command is always a pain; it's much better in newer releases but I am always having to adjust terminal width. > > - how would you model automatic spacing in a format string? Should we > support width specifiers? Disable automatic spacing if a format > string is given? It might even make sense to allow partial automatic Follow the format string for whitespace and order, and yes, on the width specifiers if possible. > spacing with a special character in the format string, that is: > > "%S.%Qr.%Qs %Al:%Pl %Ar:%Pr %p\n" > > would mean "align everything to the right, distribute remaining > whitespace between %S, %Qr and %Qs". But it looks rather complicated > at a glance. > My concern here is that once this goes in for 1 command, the others in iproute2 need to follow suit - meaning same syntax style for all commands. Given that I'd prefer we get a reasonable consensus on syntax that will work across commands -- ss, ip, tc. If it is as simple as column names with a fixed order, that is fine but just give proper consideration given the impact. The 'ip' syntax for example gets ugly quick with the various link types and their options. We don't need to allow every detail of each link type to be customized, but there are common attributes for links (e.g., mtu, ifindex, link flags, lladdr), addresses, and link types such as bridges and bonds where we can improve the amount of data thrown at a user -- a better, more customizable version of what the brief option targeted.
On Wed, 31 Oct 2018 20:48:05 -0600, David Ahern wrote: > > spacing with a special character in the format string, that is: > > > > "%S.%Qr.%Qs %Al:%Pl %Ar:%Pr %p\n" > > > > would mean "align everything to the right, distribute remaining > > whitespace between %S, %Qr and %Qs". But it looks rather complicated > > at a glance. > > > > My concern here is that once this goes in for 1 command, the others in > iproute2 need to follow suit - meaning same syntax style for all > commands. Given that I'd prefer we get a reasonable consensus on syntax > that will work across commands -- ss, ip, tc. If it is as simple as > column names with a fixed order, that is fine but just give proper > consideration given the impact. FWIW I just started piping iproute2 commands to jq. Example: tc -s -j qdisc show dev em1 | \ jq -r '.[] | [.kind,.parent,.handle,.offloaded,.bytes,.packets,.drops,.overlimits,.requeues,.backlog,.qlen,.marked] | @tsv' JSONification would probably be quite an undertaking for ss :(
On 11/1/18 3:06 PM, Jakub Kicinski wrote: > On Wed, 31 Oct 2018 20:48:05 -0600, David Ahern wrote: >>> spacing with a special character in the format string, that is: >>> >>> "%S.%Qr.%Qs %Al:%Pl %Ar:%Pr %p\n" >>> >>> would mean "align everything to the right, distribute remaining >>> whitespace between %S, %Qr and %Qs". But it looks rather complicated >>> at a glance. >>> >> >> My concern here is that once this goes in for 1 command, the others in >> iproute2 need to follow suit - meaning same syntax style for all >> commands. Given that I'd prefer we get a reasonable consensus on syntax >> that will work across commands -- ss, ip, tc. If it is as simple as >> column names with a fixed order, that is fine but just give proper >> consideration given the impact. > > FWIW I just started piping iproute2 commands to jq. Example: > > tc -s -j qdisc show dev em1 | \ > jq -r '.[] | [.kind,.parent,.handle,.offloaded,.bytes,.packets,.drops,.overlimits,.requeues,.backlog,.qlen,.marked] | @tsv' > > JSONification would probably be quite an undertaking for ss :( > Right, that is used in some of the scripts under tools/testing/selftests. I would put that in the 'heavyweight solution' category. A number of key commands offer the capability to control the output via command line argument (e.g., ps, perf script). Given the amount of data iproute2 commands throw at a user by default, it would be a good usability feature to allow a user to customize the output without having to pipe it into other commands.
On Thu, 1 Nov 2018 15:18:03 -0600 David Ahern <dsahern@gmail.com> wrote: > On 11/1/18 3:06 PM, Jakub Kicinski wrote: > > On Wed, 31 Oct 2018 20:48:05 -0600, David Ahern wrote: > >>> spacing with a special character in the format string, that is: > >>> > >>> "%S.%Qr.%Qs %Al:%Pl %Ar:%Pr %p\n" > >>> > >>> would mean "align everything to the right, distribute remaining > >>> whitespace between %S, %Qr and %Qs". But it looks rather complicated > >>> at a glance. > >>> > >> > >> My concern here is that once this goes in for 1 command, the others in > >> iproute2 need to follow suit - meaning same syntax style for all > >> commands. Given that I'd prefer we get a reasonable consensus on syntax > >> that will work across commands -- ss, ip, tc. If it is as simple as > >> column names with a fixed order, that is fine but just give proper > >> consideration given the impact. > > > > FWIW I just started piping iproute2 commands to jq. Example: > > > > tc -s -j qdisc show dev em1 | \ > > jq -r '.[] | [.kind,.parent,.handle,.offloaded,.bytes,.packets,.drops,.overlimits,.requeues,.backlog,.qlen,.marked] | @tsv' > > > > JSONification would probably be quite an undertaking for ss :( > > > > Right, that is used in some of the scripts under > tools/testing/selftests. I would put that in the 'heavyweight solution' > category. > > A number of key commands offer the capability to control the output via > command line argument (e.g., ps, perf script). Given the amount of data > iproute2 commands throw at a user by default, it would be a good > usability feature to allow a user to customize the output without having > to pipe it into other commands. I would rather see ss grow json support than having to make the output formatting of every iproute2 command grow a new format management. The jq tool looks cool, and I can see how someone could easily have a bunch of mini-scripts to do what they want.
On Wed, 31 Oct 2018 20:48:05 -0600 David Ahern <dsahern@gmail.com> wrote: > On 10/30/18 11:34 AM, Stefano Brivio wrote: > > > > - the current column abstraction is rather lightweight, things are > > already buffered in the defined column order so we don't have to jump > > back and forth in the buffer while rendering. Doing that needs some > > extra care to avoid a performance hit, but it's probably doable, I > > can put that on my to-do list > > The ss command is always a pain; it's much better in newer releases but > I am always having to adjust terminal width. Ouch. Do you have some examples?
On Thu, 1 Nov 2018 14:06:23 -0700
Jakub Kicinski <kubakici@wp.pl> wrote:
> JSONification would probably be quite an undertaking for ss :(
Probably not too much, and we would skip buffering for JSON as we don't
need to print columns, so we don't have to care about buffering and
rendering performance too much.
All it takes is to extend a bit the out() function and pass the right
arguments to it -- it looks way easier than implementing format
strings, even though I'd like the latter more.
Now that we have an abstraction for columns, it's relatively easy to selectively display only some of them, and Yoann has a use case for it. Patch 1/3 fixes a rendering issue that shows up only when display of arbitrary columns is disabled. Patch 2/3 implements the relevant option, and patch 3/3 makes the output more readable when some columns are disabled. Stefano Brivio (3): ss: Discard empty descriptor at the end of buffer, if any, before rendering ss: Introduce option to display selected columns only ss: Beautify output when arbitrary columns are hidden man/man8/ss.8 | 5 +++ misc/ss.c | 85 +++++++++++++++++++++++++++++++++++++++++++-------- 2 files changed, 77 insertions(+), 13 deletions(-)