From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 05389C43381 for ; Wed, 13 Feb 2019 22:20:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D24F6222CC for ; Wed, 13 Feb 2019 22:20:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404223AbfBMWUy (ORCPT ); Wed, 13 Feb 2019 17:20:54 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49290 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729530AbfBMWUy (ORCPT ); Wed, 13 Feb 2019 17:20:54 -0500 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 27A1D36807; Wed, 13 Feb 2019 22:20:54 +0000 (UTC) Received: from localhost (ovpn-200-19.brq.redhat.com [10.40.200.19]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2C3C919C7B; Wed, 13 Feb 2019 22:20:51 +0000 (UTC) Date: Wed, 13 Feb 2019 23:20:47 +0100 From: Stefano Brivio To: Stephen Hemminger Cc: Eric Dumazet , netdev@vger.kernel.org, Sabrina Dubroca , David Ahern Subject: Re: [PATCH iproute2 net-next v2 3/4] ss: Buffer raw fields first, then render them as a table Message-ID: <20190213232047.4b7c2f08@redhat.com> In-Reply-To: <20190213135534.01dacee5@shemminger-XPS-13-9360> References: <82f1bc98-df6d-2b0a-17e5-fa057563284e@gmail.com> <20190213093711.13ab560e@redhat.com> <20190213221716.5f958c2a@redhat.com> <20190213135534.01dacee5@shemminger-XPS-13-9360> Organization: Red Hat MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Wed, 13 Feb 2019 22:20:54 +0000 (UTC) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Wed, 13 Feb 2019 13:55:34 -0800 Stephen Hemminger wrote: > What I would favor: > * use big enough columns that for the common case everything lines up fine > * if column is to wide just print that element wider (which is what print %Ns does) This is very close to what was done before, but as soon as you mix, say, UNIX sockets with TCP sockets, "big enough" columns typically make output for TCP sockets unreadable. With buffering, instead, I can decide that a line split is needed, and keep fields aligned no matter what. > and > * add json output for programs that want to parse > * use print_uint etc for that Sure, I think we all agree with this, but it's not going to be quick to implement (even though it's perhaps a bit easier with abstracted columns and buffering). Eric reported a problem and I'm trying to fix it quickly. > The buffering patch (in iproute2-next) can/will be reverted. I think it received generally good feedback (also from users, later on) and this is the first report of a serious issue -- it's also an issue which looks easy to fix (I'm half way through that by now). By the way, this patch was merged in iproute2 more than one year ago (December 2017, by you). -- Stefano