Message ID | 20230311151756.83302-1-kerneljasonxing@gmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp339921wrd; Sat, 11 Mar 2023 07:50:41 -0800 (PST) X-Google-Smtp-Source: AK7set8EyqIDkZxuIYsbHCj0b5X3YBed708LDzHj7yHVergyRTmoEUqJOt3MlQfoyTgzVWum/E4E X-Received: by 2002:a17:90b:1e06:b0:237:4170:f63 with SMTP id pg6-20020a17090b1e0600b0023741700f63mr31275488pjb.18.1678549841294; Sat, 11 Mar 2023 07:50:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1678549841; cv=none; d=google.com; s=arc-20160816; b=zm/kKrMxPjFt3meosFpumvm9N65evtVrv4LinM2HBo0HgUnTwniMfoBcZzf7yLlZC+ OAKfZ42ai2N0fuzH8mjMjM1G0abB/gB54xVoSx2Gpivjti2igZmLLimhRbMTrw4pg96T MtzuwfKkMiWFj4804/EcdpG9fGSLM5ZQ4ffYMkn+nDsLMuPpsVtQewa1bfb8IqMRTrH2 Gv64tSQRat5ZIm4sejQYmoM/9S2AFxxX+S/lzLz7exb3iv7M7R9GH5/l9Ku1Ob5wwIJP qfGgvVIfe7jlcpWtQO+rAs2VJXgwMYKgqWuXrHfHIozxo0kGXQkAyyedRReqyY7WOHgb CgWQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=vzL0lKQA7Qxou/xZXI6wkc7TkinivUbSS7RQX8UnPsM=; b=NCtf8mFjkNX+V0DMI2LySvpIVDrQx6NHSYPg6UU2St7JhRLJZaGYWUwDCFkL27HiUP sUb6jOsvW+fyfiqV0MQuQ67j3xIGAtZaYizd/Hq22QbvVO69JRkSYaPoYh+dhsR4dyZs SfgPheVsIjmD+h7e5FLhmd8jPSSOS84WbuddL3dO4nMB1W/hcQdcmtdaOVKYnIeACLzG Nf/G5kWB223JPrrn2TsgBfz1f7bxHhm/5RSDv6ZkA2+KTVlvJzMwmjLr2v3mraD/gAgw tTjkjGKKuPnTLQS+Kl4wsmdchir4G1REpAIfXrmO613pQ5xIsB50wpcDqYmPx/RLRA3q /c1A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=p6l8O63x; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w17-20020a17090aea1100b0023b4a410ab6si469833pjy.157.2023.03.11.07.50.28; Sat, 11 Mar 2023 07:50:41 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=p6l8O63x; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230363AbjCKPSH (ORCPT <rfc822;toshivichauhan@gmail.com> + 99 others); Sat, 11 Mar 2023 10:18:07 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48874 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229791AbjCKPSF (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sat, 11 Mar 2023 10:18:05 -0500 Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C843C10A88; Sat, 11 Mar 2023 07:18:03 -0800 (PST) Received: by mail-pj1-x102f.google.com with SMTP id ce8-20020a17090aff0800b0023a61cff2c6so10090266pjb.0; Sat, 11 Mar 2023 07:18:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678547883; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=vzL0lKQA7Qxou/xZXI6wkc7TkinivUbSS7RQX8UnPsM=; b=p6l8O63x+x3Q2LUDQ3HlrBHvQtlU5v4UezfcX7HxRInV8MkJ//yj01Fw9vrEDtNRBa lwG9sPxEZdfbqgXC4II3ri4yc83g2Yg4a6BAixUz3dlMrqdEFijhekqfZOOBbKGHhwye Xs5hQ8RTrRMfBux9kgpTUFBNO0w5JYfpLxptquaoMkFo37rkSD7yQBIWMZ0v/JSW6jWY VtCO4JuefR7yhA0+lBKsgVnoo/YfJ48/shsr3GedmOA/acC/SgSPRpP2YRLNcrP8/g6k NdhpSKlRfKoIGSgsFVEqIxem7giPHnpOh8OdcDd1GKObrf02FDXiOAfFSubAfW/fXMK0 qnxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678547883; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vzL0lKQA7Qxou/xZXI6wkc7TkinivUbSS7RQX8UnPsM=; b=ZjyMeCoTECo9p6ofpbVZ2NvH8pDRI3loJ91n/epLtC8S85uzJqHYhktEAOBbqn//at X26oFL503qCty5twi3NKAg5R1AsEa/Op/XU7sG013r/OXwFTXnqIBM1b5Fm9CbOh5ACe lq1ti1Tqc7GmdBZnM4uIrww8dFxVlncnmsL8NrvnyBvFO5sa2UDt1uD3t09yBW29ZRT5 wJl4Ni6Vpo5x3sLT3jc+FOAqCElwiA1CYmZksTRZ4io3HhD4cNPBbM1lD1bn/XkdgAbV 7SLz9r+Mh7nk4AnLZlUVkpXZ5VQP8dNos0nb9pt8fueQE90+GvDrpzTUQfKZEAkap1Tn QZRA== X-Gm-Message-State: AO0yUKWDsughvy6rdOfRb8IQ6VrDp85hw5pv9GMb4nx8RSXTlyIsN/yj EWY1Gl5WcZU19ynicpOE8yk= X-Received: by 2002:a17:902:ec84:b0:19c:c87b:4740 with SMTP id x4-20020a170902ec8400b0019cc87b4740mr33928704plg.34.1678547882857; Sat, 11 Mar 2023 07:18:02 -0800 (PST) Received: from KERNELXING-MB0.tencent.com ([114.253.32.213]) by smtp.gmail.com with ESMTPSA id o11-20020a170902d4cb00b00194caf3e975sm1670922plg.208.2023.03.11.07.18.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 11 Mar 2023 07:18:02 -0800 (PST) From: Jason Xing <kerneljasonxing@gmail.com> To: davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, kerneljasonxing@gmail.com, Jason Xing <kernelxing@tencent.com> Subject: [PATCH net-next] net-sysfs: display two backlog queue len separately Date: Sat, 11 Mar 2023 23:17:56 +0800 Message-Id: <20230311151756.83302-1-kerneljasonxing@gmail.com> X-Mailer: git-send-email 2.33.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1760087078333703257?= X-GMAIL-MSGID: =?utf-8?q?1760087078333703257?= |
Series |
[net-next] net-sysfs: display two backlog queue len separately
|
|
Commit Message
Jason Xing
March 11, 2023, 3:17 p.m. UTC
From: Jason Xing <kernelxing@tencent.com> Sometimes we need to know which one of backlog queue can be exactly long enough to cause some latency when debugging this part is needed. Thus, we can then separate the display of both. Signed-off-by: Jason Xing <kernelxing@tencent.com> --- net/core/net-procfs.c | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-)
Comments
On Sat, Mar 11, 2023 at 11:17:56PM +0800, Jason Xing wrote: > From: Jason Xing <kernelxing@tencent.com> > > Sometimes we need to know which one of backlog queue can be exactly > long enough to cause some latency when debugging this part is needed. > Thus, we can then separate the display of both. > > Signed-off-by: Jason Xing <kernelxing@tencent.com> > --- > net/core/net-procfs.c | 17 ++++++++++++----- > 1 file changed, 12 insertions(+), 5 deletions(-) > > diff --git a/net/core/net-procfs.c b/net/core/net-procfs.c > index 1ec23bf8b05c..97a304e1957a 100644 > --- a/net/core/net-procfs.c > +++ b/net/core/net-procfs.c > @@ -115,10 +115,14 @@ static int dev_seq_show(struct seq_file *seq, void *v) > return 0; > } > > -static u32 softnet_backlog_len(struct softnet_data *sd) > +static u32 softnet_input_pkt_queue_len(struct softnet_data *sd) > { > - return skb_queue_len_lockless(&sd->input_pkt_queue) + > - skb_queue_len_lockless(&sd->process_queue); > + return skb_queue_len_lockless(&sd->input_pkt_queue); > +} > + > +static u32 softnet_process_queue_len(struct softnet_data *sd) > +{ > + return skb_queue_len_lockless(&sd->process_queue); > } > > static struct softnet_data *softnet_get_online(loff_t *pos) > @@ -169,12 +173,15 @@ static int softnet_seq_show(struct seq_file *seq, void *v) > * mapping the data a specific CPU > */ > seq_printf(seq, > - "%08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x\n", > + "%08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x " > + "%08x %08x\n", > sd->processed, sd->dropped, sd->time_squeeze, 0, > 0, 0, 0, 0, /* was fastroute */ > 0, /* was cpu_collision */ > sd->received_rps, flow_limit_count, > - softnet_backlog_len(sd), (int)seq->index); > + 0, /* was len of two backlog queues */ > + (int)seq->index, nit: I think you could avoid this cast by using %llx as the format specifier. > + softnet_input_pkt_queue_len(sd), softnet_process_queue_len(sd)); > return 0; > } > > -- > 2.37.3 >
On Mon, Mar 13, 2023 at 3:02 AM Simon Horman <simon.horman@corigine.com> wrote: > > On Sat, Mar 11, 2023 at 11:17:56PM +0800, Jason Xing wrote: > > From: Jason Xing <kernelxing@tencent.com> > > > > Sometimes we need to know which one of backlog queue can be exactly > > long enough to cause some latency when debugging this part is needed. > > Thus, we can then separate the display of both. > > > > Signed-off-by: Jason Xing <kernelxing@tencent.com> > > --- > > net/core/net-procfs.c | 17 ++++++++++++----- > > 1 file changed, 12 insertions(+), 5 deletions(-) > > > > diff --git a/net/core/net-procfs.c b/net/core/net-procfs.c > > index 1ec23bf8b05c..97a304e1957a 100644 > > --- a/net/core/net-procfs.c > > +++ b/net/core/net-procfs.c > > @@ -115,10 +115,14 @@ static int dev_seq_show(struct seq_file *seq, void *v) > > return 0; > > } > > > > -static u32 softnet_backlog_len(struct softnet_data *sd) > > +static u32 softnet_input_pkt_queue_len(struct softnet_data *sd) > > { > > - return skb_queue_len_lockless(&sd->input_pkt_queue) + > > - skb_queue_len_lockless(&sd->process_queue); > > + return skb_queue_len_lockless(&sd->input_pkt_queue); > > +} > > + > > +static u32 softnet_process_queue_len(struct softnet_data *sd) > > +{ > > + return skb_queue_len_lockless(&sd->process_queue); > > } > > > > static struct softnet_data *softnet_get_online(loff_t *pos) > > @@ -169,12 +173,15 @@ static int softnet_seq_show(struct seq_file *seq, void *v) > > * mapping the data a specific CPU > > */ > > seq_printf(seq, > > - "%08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x\n", > > + "%08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x " > > + "%08x %08x\n", > > sd->processed, sd->dropped, sd->time_squeeze, 0, > > 0, 0, 0, 0, /* was fastroute */ > > 0, /* was cpu_collision */ > > sd->received_rps, flow_limit_count, > > - softnet_backlog_len(sd), (int)seq->index); > > + 0, /* was len of two backlog queues */ > > + (int)seq->index, > > nit: I think you could avoid this cast by using %llx as the format specifier. I'm not sure if I should change this format since the above line is introduced in commit 7d58e6555870d ('net-sysfs: add backlog len and CPU id to softnet data'). The seq->index here manifests which cpu it uses, so it can be displayed in 'int' format. Meanwhile, using %8x to output is much cleaner if the user executes 'cat /proc/net/softnet_stat'. What do you think about this? Thanks, Jason > > > + softnet_input_pkt_queue_len(sd), softnet_process_queue_len(sd)); > > return 0; > > } > > > > -- > > 2.37.3 > >
On Mon, 13 Mar 2023 09:55:37 +0800 Jason Xing <kerneljasonxing@gmail.com> wrote: > On Mon, Mar 13, 2023 at 3:02 AM Simon Horman <simon.horman@corigine.com> wrote: > > > > On Sat, Mar 11, 2023 at 11:17:56PM +0800, Jason Xing wrote: > > > From: Jason Xing <kernelxing@tencent.com> > > > > > > Sometimes we need to know which one of backlog queue can be exactly > > > long enough to cause some latency when debugging this part is needed. > > > Thus, we can then separate the display of both. > > > > > > Signed-off-by: Jason Xing <kernelxing@tencent.com> > > > --- > > > net/core/net-procfs.c | 17 ++++++++++++----- > > > 1 file changed, 12 insertions(+), 5 deletions(-) > > > > > > diff --git a/net/core/net-procfs.c b/net/core/net-procfs.c > > > index 1ec23bf8b05c..97a304e1957a 100644 > > > --- a/net/core/net-procfs.c > > > +++ b/net/core/net-procfs.c > > > @@ -115,10 +115,14 @@ static int dev_seq_show(struct seq_file *seq, void *v) > > > return 0; > > > } > > > > > > -static u32 softnet_backlog_len(struct softnet_data *sd) > > > +static u32 softnet_input_pkt_queue_len(struct softnet_data *sd) > > > { > > > - return skb_queue_len_lockless(&sd->input_pkt_queue) + > > > - skb_queue_len_lockless(&sd->process_queue); > > > + return skb_queue_len_lockless(&sd->input_pkt_queue); > > > +} > > > + > > > +static u32 softnet_process_queue_len(struct softnet_data *sd) > > > +{ > > > + return skb_queue_len_lockless(&sd->process_queue); > > > } > > > > > > static struct softnet_data *softnet_get_online(loff_t *pos) > > > @@ -169,12 +173,15 @@ static int softnet_seq_show(struct seq_file *seq, void *v) > > > * mapping the data a specific CPU > > > */ > > > seq_printf(seq, > > > - "%08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x\n", > > > + "%08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x " > > > + "%08x %08x\n", > > > sd->processed, sd->dropped, sd->time_squeeze, 0, > > > 0, 0, 0, 0, /* was fastroute */ > > > 0, /* was cpu_collision */ > > > sd->received_rps, flow_limit_count, > > > - softnet_backlog_len(sd), (int)seq->index); > > > + 0, /* was len of two backlog queues */ > > > + (int)seq->index, > > > > nit: I think you could avoid this cast by using %llx as the format specifier. > > I'm not sure if I should change this format since the above line is > introduced in commit 7d58e6555870d ('net-sysfs: add backlog len and > CPU id to softnet data'). > The seq->index here manifests which cpu it uses, so it can be > displayed in 'int' format. Meanwhile, using %8x to output is much > cleaner if the user executes 'cat /proc/net/softnet_stat'. > > What do you think about this? > > Thanks, > Jason I consider sofnet_data a legacy API (ie don't change). Why not add to real sysfs for network device with the one value per file?
On Mon, Mar 13, 2023 at 10:28 AM Stephen Hemminger <stephen@networkplumber.org> wrote: > > On Mon, 13 Mar 2023 09:55:37 +0800 > Jason Xing <kerneljasonxing@gmail.com> wrote: > > > On Mon, Mar 13, 2023 at 3:02 AM Simon Horman <simon.horman@corigine.com> wrote: > > > > > > On Sat, Mar 11, 2023 at 11:17:56PM +0800, Jason Xing wrote: > > > > From: Jason Xing <kernelxing@tencent.com> > > > > > > > > Sometimes we need to know which one of backlog queue can be exactly > > > > long enough to cause some latency when debugging this part is needed. > > > > Thus, we can then separate the display of both. > > > > > > > > Signed-off-by: Jason Xing <kernelxing@tencent.com> > > > > --- > > > > net/core/net-procfs.c | 17 ++++++++++++----- > > > > 1 file changed, 12 insertions(+), 5 deletions(-) > > > > > > > > diff --git a/net/core/net-procfs.c b/net/core/net-procfs.c > > > > index 1ec23bf8b05c..97a304e1957a 100644 > > > > --- a/net/core/net-procfs.c > > > > +++ b/net/core/net-procfs.c > > > > @@ -115,10 +115,14 @@ static int dev_seq_show(struct seq_file *seq, void *v) > > > > return 0; > > > > } > > > > > > > > -static u32 softnet_backlog_len(struct softnet_data *sd) > > > > +static u32 softnet_input_pkt_queue_len(struct softnet_data *sd) > > > > { > > > > - return skb_queue_len_lockless(&sd->input_pkt_queue) + > > > > - skb_queue_len_lockless(&sd->process_queue); > > > > + return skb_queue_len_lockless(&sd->input_pkt_queue); > > > > +} > > > > + > > > > +static u32 softnet_process_queue_len(struct softnet_data *sd) > > > > +{ > > > > + return skb_queue_len_lockless(&sd->process_queue); > > > > } > > > > > > > > static struct softnet_data *softnet_get_online(loff_t *pos) > > > > @@ -169,12 +173,15 @@ static int softnet_seq_show(struct seq_file *seq, void *v) > > > > * mapping the data a specific CPU > > > > */ > > > > seq_printf(seq, > > > > - "%08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x\n", > > > > + "%08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x " > > > > + "%08x %08x\n", > > > > sd->processed, sd->dropped, sd->time_squeeze, 0, > > > > 0, 0, 0, 0, /* was fastroute */ > > > > 0, /* was cpu_collision */ > > > > sd->received_rps, flow_limit_count, > > > > - softnet_backlog_len(sd), (int)seq->index); > > > > + 0, /* was len of two backlog queues */ > > > > + (int)seq->index, > > > > > > nit: I think you could avoid this cast by using %llx as the format specifier. > > > > I'm not sure if I should change this format since the above line is > > introduced in commit 7d58e6555870d ('net-sysfs: add backlog len and > > CPU id to softnet data'). > > The seq->index here manifests which cpu it uses, so it can be > > displayed in 'int' format. Meanwhile, using %8x to output is much > > cleaner if the user executes 'cat /proc/net/softnet_stat'. > > > > What do you think about this? > > > > Thanks, > > Jason > > I consider sofnet_data a legacy API (ie don't change). Yeah, people seldomly touch this file in these years. > Why not add to real sysfs for network device with the one value per file? Thanks for your advice. It's worth thinking about what kind of output can replace the softnet_stat file because this file includes almost everything which makes it more user-friendly. I'm a little bit confused if we can use a fully new way to completely replace the legacy file. Do other maintainers have some precious opinion on this? Thanks, Jason
On Mon, Mar 13, 2023 at 10:28 AM Stephen Hemminger <stephen@networkplumber.org> wrote: > > On Mon, 13 Mar 2023 09:55:37 +0800 > Jason Xing <kerneljasonxing@gmail.com> wrote: > > > On Mon, Mar 13, 2023 at 3:02 AM Simon Horman <simon.horman@corigine.com> wrote: > > > > > > On Sat, Mar 11, 2023 at 11:17:56PM +0800, Jason Xing wrote: > > > > From: Jason Xing <kernelxing@tencent.com> > > > > > > > > Sometimes we need to know which one of backlog queue can be exactly > > > > long enough to cause some latency when debugging this part is needed. > > > > Thus, we can then separate the display of both. > > > > > > > > Signed-off-by: Jason Xing <kernelxing@tencent.com> > > > > --- > > > > net/core/net-procfs.c | 17 ++++++++++++----- > > > > 1 file changed, 12 insertions(+), 5 deletions(-) > > > > > > > > diff --git a/net/core/net-procfs.c b/net/core/net-procfs.c > > > > index 1ec23bf8b05c..97a304e1957a 100644 > > > > --- a/net/core/net-procfs.c > > > > +++ b/net/core/net-procfs.c > > > > @@ -115,10 +115,14 @@ static int dev_seq_show(struct seq_file *seq, void *v) > > > > return 0; > > > > } > > > > > > > > -static u32 softnet_backlog_len(struct softnet_data *sd) > > > > +static u32 softnet_input_pkt_queue_len(struct softnet_data *sd) > > > > { > > > > - return skb_queue_len_lockless(&sd->input_pkt_queue) + > > > > - skb_queue_len_lockless(&sd->process_queue); > > > > + return skb_queue_len_lockless(&sd->input_pkt_queue); > > > > +} > > > > + > > > > +static u32 softnet_process_queue_len(struct softnet_data *sd) > > > > +{ > > > > + return skb_queue_len_lockless(&sd->process_queue); > > > > } > > > > > > > > static struct softnet_data *softnet_get_online(loff_t *pos) > > > > @@ -169,12 +173,15 @@ static int softnet_seq_show(struct seq_file *seq, void *v) > > > > * mapping the data a specific CPU > > > > */ > > > > seq_printf(seq, > > > > - "%08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x\n", > > > > + "%08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x " > > > > + "%08x %08x\n", > > > > sd->processed, sd->dropped, sd->time_squeeze, 0, > > > > 0, 0, 0, 0, /* was fastroute */ > > > > 0, /* was cpu_collision */ > > > > sd->received_rps, flow_limit_count, > > > > - softnet_backlog_len(sd), (int)seq->index); > > > > + 0, /* was len of two backlog queues */ > > > > + (int)seq->index, > > > > > > nit: I think you could avoid this cast by using %llx as the format specifier. > > > > I'm not sure if I should change this format since the above line is > > introduced in commit 7d58e6555870d ('net-sysfs: add backlog len and > > CPU id to softnet data'). > > The seq->index here manifests which cpu it uses, so it can be > > displayed in 'int' format. Meanwhile, using %8x to output is much > > cleaner if the user executes 'cat /proc/net/softnet_stat'. > > > > What do you think about this? > > > > Thanks, > > Jason > > I consider sofnet_data a legacy API (ie don't change). [...] > Why not add to real sysfs for network device with the one value per file? Well, I'm wondering if the way you suggested is probably not proper because this structure is per cpu which means that we have 'num_cpus' * 'how many members we should print' files. It's too many, I think. /proc/net/softnet_stat is still a good choice :) I need more advice on this. Thanks, Jason
On Mon, Mar 13, 2023 at 09:55:37AM +0800, Jason Xing wrote: > On Mon, Mar 13, 2023 at 3:02 AM Simon Horman <simon.horman@corigine.com> wrote: > > > > On Sat, Mar 11, 2023 at 11:17:56PM +0800, Jason Xing wrote: > > > From: Jason Xing <kernelxing@tencent.com> > > > > > > Sometimes we need to know which one of backlog queue can be exactly > > > long enough to cause some latency when debugging this part is needed. > > > Thus, we can then separate the display of both. > > > > > > Signed-off-by: Jason Xing <kernelxing@tencent.com> > > > --- > > > net/core/net-procfs.c | 17 ++++++++++++----- > > > 1 file changed, 12 insertions(+), 5 deletions(-) > > > > > > diff --git a/net/core/net-procfs.c b/net/core/net-procfs.c > > > index 1ec23bf8b05c..97a304e1957a 100644 > > > --- a/net/core/net-procfs.c > > > +++ b/net/core/net-procfs.c > > > @@ -115,10 +115,14 @@ static int dev_seq_show(struct seq_file *seq, void *v) > > > return 0; > > > } > > > > > > -static u32 softnet_backlog_len(struct softnet_data *sd) > > > +static u32 softnet_input_pkt_queue_len(struct softnet_data *sd) > > > { > > > - return skb_queue_len_lockless(&sd->input_pkt_queue) + > > > - skb_queue_len_lockless(&sd->process_queue); > > > + return skb_queue_len_lockless(&sd->input_pkt_queue); > > > +} > > > + > > > +static u32 softnet_process_queue_len(struct softnet_data *sd) > > > +{ > > > + return skb_queue_len_lockless(&sd->process_queue); > > > } > > > > > > static struct softnet_data *softnet_get_online(loff_t *pos) > > > @@ -169,12 +173,15 @@ static int softnet_seq_show(struct seq_file *seq, void *v) > > > * mapping the data a specific CPU > > > */ > > > seq_printf(seq, > > > - "%08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x\n", > > > + "%08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x " > > > + "%08x %08x\n", > > > sd->processed, sd->dropped, sd->time_squeeze, 0, > > > 0, 0, 0, 0, /* was fastroute */ > > > 0, /* was cpu_collision */ > > > sd->received_rps, flow_limit_count, > > > - softnet_backlog_len(sd), (int)seq->index); > > > + 0, /* was len of two backlog queues */ > > > + (int)seq->index, > > > > nit: I think you could avoid this cast by using %llx as the format specifier. > > I'm not sure if I should change this format since the above line is > introduced in commit 7d58e6555870d ('net-sysfs: add backlog len and > CPU id to softnet data'). > The seq->index here manifests which cpu it uses, so it can be > displayed in 'int' format. Meanwhile, using %8x to output is much > cleaner if the user executes 'cat /proc/net/softnet_stat'. > > What do you think about this? I think %08llx might be a good way to go. But perhaps I'm missing something wrt to changing user-facing output. In any case, this is more a suggestion than a request for a change.
On Mon, Mar 13, 2023 at 8:11 PM Simon Horman <simon.horman@corigine.com> wrote: > > On Mon, Mar 13, 2023 at 09:55:37AM +0800, Jason Xing wrote: > > On Mon, Mar 13, 2023 at 3:02 AM Simon Horman <simon.horman@corigine.com> wrote: > > > > > > On Sat, Mar 11, 2023 at 11:17:56PM +0800, Jason Xing wrote: > > > > From: Jason Xing <kernelxing@tencent.com> > > > > > > > > Sometimes we need to know which one of backlog queue can be exactly > > > > long enough to cause some latency when debugging this part is needed. > > > > Thus, we can then separate the display of both. > > > > > > > > Signed-off-by: Jason Xing <kernelxing@tencent.com> > > > > --- > > > > net/core/net-procfs.c | 17 ++++++++++++----- > > > > 1 file changed, 12 insertions(+), 5 deletions(-) > > > > > > > > diff --git a/net/core/net-procfs.c b/net/core/net-procfs.c > > > > index 1ec23bf8b05c..97a304e1957a 100644 > > > > --- a/net/core/net-procfs.c > > > > +++ b/net/core/net-procfs.c > > > > @@ -115,10 +115,14 @@ static int dev_seq_show(struct seq_file *seq, void *v) > > > > return 0; > > > > } > > > > > > > > -static u32 softnet_backlog_len(struct softnet_data *sd) > > > > +static u32 softnet_input_pkt_queue_len(struct softnet_data *sd) > > > > { > > > > - return skb_queue_len_lockless(&sd->input_pkt_queue) + > > > > - skb_queue_len_lockless(&sd->process_queue); > > > > + return skb_queue_len_lockless(&sd->input_pkt_queue); > > > > +} > > > > + > > > > +static u32 softnet_process_queue_len(struct softnet_data *sd) > > > > +{ > > > > + return skb_queue_len_lockless(&sd->process_queue); > > > > } > > > > > > > > static struct softnet_data *softnet_get_online(loff_t *pos) > > > > @@ -169,12 +173,15 @@ static int softnet_seq_show(struct seq_file *seq, void *v) > > > > * mapping the data a specific CPU > > > > */ > > > > seq_printf(seq, > > > > - "%08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x\n", > > > > + "%08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x " > > > > + "%08x %08x\n", > > > > sd->processed, sd->dropped, sd->time_squeeze, 0, > > > > 0, 0, 0, 0, /* was fastroute */ > > > > 0, /* was cpu_collision */ > > > > sd->received_rps, flow_limit_count, > > > > - softnet_backlog_len(sd), (int)seq->index); > > > > + 0, /* was len of two backlog queues */ > > > > + (int)seq->index, > > > > > > nit: I think you could avoid this cast by using %llx as the format specifier. > > > > I'm not sure if I should change this format since the above line is > > introduced in commit 7d58e6555870d ('net-sysfs: add backlog len and > > CPU id to softnet data'). > > The seq->index here manifests which cpu it uses, so it can be > > displayed in 'int' format. Meanwhile, using %8x to output is much > > cleaner if the user executes 'cat /proc/net/softnet_stat'. > > > > What do you think about this? > > I think %08llx might be a good way to go. > But perhaps I'm missing something wrt to changing user-facing output. > > In any case, this is more a suggestion than a request for a change. Ah, now I see. Thanks again for your review and suggestion :) Thanks, Jason
On Sat, Mar 11, 2023 at 7:18 AM Jason Xing <kerneljasonxing@gmail.com> wrote: > > From: Jason Xing <kernelxing@tencent.com> > > Sometimes we need to know which one of backlog queue can be exactly > long enough to cause some latency when debugging this part is needed. > Thus, we can then separate the display of both. > > Signed-off-by: Jason Xing <kernelxing@tencent.com> > --- > net/core/net-procfs.c | 17 ++++++++++++----- > 1 file changed, 12 insertions(+), 5 deletions(-) > > diff --git a/net/core/net-procfs.c b/net/core/net-procfs.c > index 1ec23bf8b05c..97a304e1957a 100644 > --- a/net/core/net-procfs.c > +++ b/net/core/net-procfs.c > @@ -115,10 +115,14 @@ static int dev_seq_show(struct seq_file *seq, void *v) > return 0; > } > > -static u32 softnet_backlog_len(struct softnet_data *sd) > +static u32 softnet_input_pkt_queue_len(struct softnet_data *sd) > { > - return skb_queue_len_lockless(&sd->input_pkt_queue) + > - skb_queue_len_lockless(&sd->process_queue); > + return skb_queue_len_lockless(&sd->input_pkt_queue); > +} > + > +static u32 softnet_process_queue_len(struct softnet_data *sd) > +{ > + return skb_queue_len_lockless(&sd->process_queue); > } > > static struct softnet_data *softnet_get_online(loff_t *pos) > @@ -169,12 +173,15 @@ static int softnet_seq_show(struct seq_file *seq, void *v) > * mapping the data a specific CPU > */ > seq_printf(seq, > - "%08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x\n", > + "%08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x " > + "%08x %08x\n", > sd->processed, sd->dropped, sd->time_squeeze, 0, > 0, 0, 0, 0, /* was fastroute */ > 0, /* was cpu_collision */ > sd->received_rps, flow_limit_count, > - softnet_backlog_len(sd), (int)seq->index); > + 0, /* was len of two backlog queues */ You can not pretend the sum is zero, some user space tools out there would be fooled. > + (int)seq->index, > + softnet_input_pkt_queue_len(sd), softnet_process_queue_len(sd)); > return 0; > } > > -- > 2.37.3 > In general I would prefer we no longer change this file. Perhaps add a tracepoint instead ?
On Mon, Mar 13, 2023 at 8:34 PM Eric Dumazet <edumazet@google.com> wrote: > > On Sat, Mar 11, 2023 at 7:18 AM Jason Xing <kerneljasonxing@gmail.com> wrote: > > > > From: Jason Xing <kernelxing@tencent.com> > > > > Sometimes we need to know which one of backlog queue can be exactly > > long enough to cause some latency when debugging this part is needed. > > Thus, we can then separate the display of both. > > > > Signed-off-by: Jason Xing <kernelxing@tencent.com> > > --- > > net/core/net-procfs.c | 17 ++++++++++++----- > > 1 file changed, 12 insertions(+), 5 deletions(-) > > > > diff --git a/net/core/net-procfs.c b/net/core/net-procfs.c > > index 1ec23bf8b05c..97a304e1957a 100644 > > --- a/net/core/net-procfs.c > > +++ b/net/core/net-procfs.c > > @@ -115,10 +115,14 @@ static int dev_seq_show(struct seq_file *seq, void *v) > > return 0; > > } > > > > -static u32 softnet_backlog_len(struct softnet_data *sd) > > +static u32 softnet_input_pkt_queue_len(struct softnet_data *sd) > > { > > - return skb_queue_len_lockless(&sd->input_pkt_queue) + > > - skb_queue_len_lockless(&sd->process_queue); > > + return skb_queue_len_lockless(&sd->input_pkt_queue); > > +} > > + > > +static u32 softnet_process_queue_len(struct softnet_data *sd) > > +{ > > + return skb_queue_len_lockless(&sd->process_queue); > > } > > > > static struct softnet_data *softnet_get_online(loff_t *pos) > > @@ -169,12 +173,15 @@ static int softnet_seq_show(struct seq_file *seq, void *v) > > * mapping the data a specific CPU > > */ > > seq_printf(seq, > > - "%08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x\n", > > + "%08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x " > > + "%08x %08x\n", > > sd->processed, sd->dropped, sd->time_squeeze, 0, > > 0, 0, 0, 0, /* was fastroute */ > > 0, /* was cpu_collision */ > > sd->received_rps, flow_limit_count, > > - softnet_backlog_len(sd), (int)seq->index); > > + 0, /* was len of two backlog queues */ > > You can not pretend the sum is zero, some user space tools out there > would be fooled. > > > + (int)seq->index, > > + softnet_input_pkt_queue_len(sd), softnet_process_queue_len(sd)); > > return 0; > > } > > > > -- > > 2.37.3 > > > > In general I would prefer we no longer change this file. Fine. Since now, let this legacy file be one part of history. > > Perhaps add a tracepoint instead ? Thanks, Eric. It's one good idea. It seems acceptable if we only need to trace two separate backlog queues where it can probably hit the limit, say, in the enqueue_to_backlog(). Similarly I decide to write another two tracepoints of time_squeeze and budget_squeeze which I introduced to distinguish from time_squeeze as the below link shows: https://lore.kernel.org/lkml/CAL+tcoAwodpnE2NjMLPhBbmHUvmKMgSykqx0EQ4YZaQHjrx0Hw@mail.gmail.com/. For that change, any suggestions are deeply welcome :) Thanks, Jason
On Mon, Mar 13, 2023 at 6:16 AM Jason Xing <kerneljasonxing@gmail.com> wrote: > > On Mon, Mar 13, 2023 at 8:34 PM Eric Dumazet <edumazet@google.com> wrote: > > > > On Sat, Mar 11, 2023 at 7:18 AM Jason Xing <kerneljasonxing@gmail.com> wrote: > > > > > > From: Jason Xing <kernelxing@tencent.com> > > > > > > Sometimes we need to know which one of backlog queue can be exactly > > > long enough to cause some latency when debugging this part is needed. > > > Thus, we can then separate the display of both. > > > > > > Signed-off-by: Jason Xing <kernelxing@tencent.com> > > > --- > > > net/core/net-procfs.c | 17 ++++++++++++----- > > > 1 file changed, 12 insertions(+), 5 deletions(-) > > > > > > diff --git a/net/core/net-procfs.c b/net/core/net-procfs.c > > > index 1ec23bf8b05c..97a304e1957a 100644 > > > --- a/net/core/net-procfs.c > > > +++ b/net/core/net-procfs.c > > > @@ -115,10 +115,14 @@ static int dev_seq_show(struct seq_file *seq, void *v) > > > return 0; > > > } > > > > > > -static u32 softnet_backlog_len(struct softnet_data *sd) > > > +static u32 softnet_input_pkt_queue_len(struct softnet_data *sd) > > > { > > > - return skb_queue_len_lockless(&sd->input_pkt_queue) + > > > - skb_queue_len_lockless(&sd->process_queue); > > > + return skb_queue_len_lockless(&sd->input_pkt_queue); > > > +} > > > + > > > +static u32 softnet_process_queue_len(struct softnet_data *sd) > > > +{ > > > + return skb_queue_len_lockless(&sd->process_queue); > > > } > > > > > > static struct softnet_data *softnet_get_online(loff_t *pos) > > > @@ -169,12 +173,15 @@ static int softnet_seq_show(struct seq_file *seq, void *v) > > > * mapping the data a specific CPU > > > */ > > > seq_printf(seq, > > > - "%08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x\n", > > > + "%08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x " > > > + "%08x %08x\n", > > > sd->processed, sd->dropped, sd->time_squeeze, 0, > > > 0, 0, 0, 0, /* was fastroute */ > > > 0, /* was cpu_collision */ > > > sd->received_rps, flow_limit_count, > > > - softnet_backlog_len(sd), (int)seq->index); > > > + 0, /* was len of two backlog queues */ > > > > You can not pretend the sum is zero, some user space tools out there > > would be fooled. > > > > > + (int)seq->index, > > > + softnet_input_pkt_queue_len(sd), softnet_process_queue_len(sd)); > > > return 0; > > > } > > > > > > -- > > > 2.37.3 > > > > > > > In general I would prefer we no longer change this file. > > Fine. Since now, let this legacy file be one part of history. > > > > > Perhaps add a tracepoint instead ? > > Thanks, Eric. It's one good idea. It seems acceptable if we only need > to trace two separate backlog queues where it can probably hit the > limit, say, in the enqueue_to_backlog(). Note that enqueue_to_backlog() already uses a specific kfree_skb_reason() reason (SKB_DROP_REASON_CPU_BACKLOG) so existing infrastructure should work just fine. > > Similarly I decide to write another two tracepoints of time_squeeze > and budget_squeeze which I introduced to distinguish from time_squeeze > as the below link shows: > https://lore.kernel.org/lkml/CAL+tcoAwodpnE2NjMLPhBbmHUvmKMgSykqx0EQ4YZaQHjrx0Hw@mail.gmail.com/. > For that change, any suggestions are deeply welcome :) > For your workloads to hit these limits enough for you to be worried, it looks like you are not using any scaling stuff documented in Documentation/networking/scaling.rst
On Mon, Mar 13, 2023 at 11:59 PM Eric Dumazet <edumazet@google.com> wrote: > > On Mon, Mar 13, 2023 at 6:16 AM Jason Xing <kerneljasonxing@gmail.com> wrote: > > > > On Mon, Mar 13, 2023 at 8:34 PM Eric Dumazet <edumazet@google.com> wrote: > > > > > > On Sat, Mar 11, 2023 at 7:18 AM Jason Xing <kerneljasonxing@gmail.com> wrote: > > > > > > > > From: Jason Xing <kernelxing@tencent.com> > > > > > > > > Sometimes we need to know which one of backlog queue can be exactly > > > > long enough to cause some latency when debugging this part is needed. > > > > Thus, we can then separate the display of both. > > > > > > > > Signed-off-by: Jason Xing <kernelxing@tencent.com> > > > > --- > > > > net/core/net-procfs.c | 17 ++++++++++++----- > > > > 1 file changed, 12 insertions(+), 5 deletions(-) > > > > > > > > diff --git a/net/core/net-procfs.c b/net/core/net-procfs.c > > > > index 1ec23bf8b05c..97a304e1957a 100644 > > > > --- a/net/core/net-procfs.c > > > > +++ b/net/core/net-procfs.c > > > > @@ -115,10 +115,14 @@ static int dev_seq_show(struct seq_file *seq, void *v) > > > > return 0; > > > > } > > > > > > > > -static u32 softnet_backlog_len(struct softnet_data *sd) > > > > +static u32 softnet_input_pkt_queue_len(struct softnet_data *sd) > > > > { > > > > - return skb_queue_len_lockless(&sd->input_pkt_queue) + > > > > - skb_queue_len_lockless(&sd->process_queue); > > > > + return skb_queue_len_lockless(&sd->input_pkt_queue); > > > > +} > > > > + > > > > +static u32 softnet_process_queue_len(struct softnet_data *sd) > > > > +{ > > > > + return skb_queue_len_lockless(&sd->process_queue); > > > > } > > > > > > > > static struct softnet_data *softnet_get_online(loff_t *pos) > > > > @@ -169,12 +173,15 @@ static int softnet_seq_show(struct seq_file *seq, void *v) > > > > * mapping the data a specific CPU > > > > */ > > > > seq_printf(seq, > > > > - "%08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x\n", > > > > + "%08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x " > > > > + "%08x %08x\n", > > > > sd->processed, sd->dropped, sd->time_squeeze, 0, > > > > 0, 0, 0, 0, /* was fastroute */ > > > > 0, /* was cpu_collision */ > > > > sd->received_rps, flow_limit_count, > > > > - softnet_backlog_len(sd), (int)seq->index); > > > > + 0, /* was len of two backlog queues */ > > > > > > You can not pretend the sum is zero, some user space tools out there > > > would be fooled. > > > > > > > + (int)seq->index, > > > > + softnet_input_pkt_queue_len(sd), softnet_process_queue_len(sd)); > > > > return 0; > > > > } > > > > > > > > -- > > > > 2.37.3 > > > > > > > > > > In general I would prefer we no longer change this file. > > > > Fine. Since now, let this legacy file be one part of history. > > > > > > > > Perhaps add a tracepoint instead ? > > > > Thanks, Eric. It's one good idea. It seems acceptable if we only need > > to trace two separate backlog queues where it can probably hit the > > limit, say, in the enqueue_to_backlog(). > > [...] > Note that enqueue_to_backlog() already uses a specific kfree_skb_reason() reason > (SKB_DROP_REASON_CPU_BACKLOG) so existing infrastructure should work just fine. Sure, I noticed that. It traces all the kfree_skb paths, not only softnet_data. If it isn't proper, what would you recommend where to put the trace function into? Now I'm thinking of resorting to the legacy file we discussed above :( > > > > > > Similarly I decide to write another two tracepoints of time_squeeze > > and budget_squeeze which I introduced to distinguish from time_squeeze > > as the below link shows: > > https://lore.kernel.org/lkml/CAL+tcoAwodpnE2NjMLPhBbmHUvmKMgSykqx0EQ4YZaQHjrx0Hw@mail.gmail.com/. > > For that change, any suggestions are deeply welcome :) > > > > For your workloads to hit these limits enough for you to be worried, > it looks like you are not using any scaling stuff documented > in Documentation/networking/scaling.rst Thanks for the guidance. Scaling is a good way to go really. But I just would like to separate these two kinds of limits to watch them closely. More often we cannot decide to adjust accurately which one should be adjusted. Time squeeze may not be clear and we cannot randomly write a larger number into both proc files which may do harm to some external customers unless we can show some proof to them. Maybe I got something wrong. If adding some tracepoints for those limits in softnet_data is not elegant, please enlighten me :) Thanks, Jason
On Mon, Mar 13, 2023 at 10:16 AM Jason Xing <kerneljasonxing@gmail.com> wrote: > > Thanks for the guidance. Scaling is a good way to go really. But I > just would like to separate these two kinds of limits to watch them > closely. More often we cannot decide to adjust accurately which one > should be adjusted. Time squeeze may not be clear and we cannot > randomly write a larger number into both proc files which may do harm > to some external customers unless we can show some proof to them. > > Maybe I got something wrong. If adding some tracepoints for those > limits in softnet_data is not elegant, please enlighten me :) > I dunno, but it really looks like you are re-discovering things that we dealt with about 10 years ago. I wonder why new ways of tracing stuff are needed nowadays, while ~10 years ago nothing officially put and maintained forever in the kernel was needed.
On Tue, Mar 14, 2023 at 1:34 AM Eric Dumazet <edumazet@google.com> wrote: > > On Mon, Mar 13, 2023 at 10:16 AM Jason Xing <kerneljasonxing@gmail.com> wrote: > > > > > Thanks for the guidance. Scaling is a good way to go really. But I > > just would like to separate these two kinds of limits to watch them > > closely. More often we cannot decide to adjust accurately which one > > should be adjusted. Time squeeze may not be clear and we cannot > > randomly write a larger number into both proc files which may do harm > > to some external customers unless we can show some proof to them. > > > > Maybe I got something wrong. If adding some tracepoints for those > > limits in softnet_data is not elegant, please enlighten me :) > > > [...] > I dunno, but it really looks like you are re-discovering things that > we dealt with about 10 years ago. > > I wonder why new ways of tracing stuff are needed nowadays, while ~10 > years ago nothing > officially put and maintained forever in the kernel was needed. Well, that's not my original intention. All I want to do is show more important members in softnet_data to help users know more about this part and decide which one to tune. I think what you said (which is "You can not pretend the sum is zero, some user space tools out there would be fooled.") is quite right, I can keep this softnet_backlog_len() untouched as the old days. Thanks, Jason
diff --git a/net/core/net-procfs.c b/net/core/net-procfs.c index 1ec23bf8b05c..97a304e1957a 100644 --- a/net/core/net-procfs.c +++ b/net/core/net-procfs.c @@ -115,10 +115,14 @@ static int dev_seq_show(struct seq_file *seq, void *v) return 0; } -static u32 softnet_backlog_len(struct softnet_data *sd) +static u32 softnet_input_pkt_queue_len(struct softnet_data *sd) { - return skb_queue_len_lockless(&sd->input_pkt_queue) + - skb_queue_len_lockless(&sd->process_queue); + return skb_queue_len_lockless(&sd->input_pkt_queue); +} + +static u32 softnet_process_queue_len(struct softnet_data *sd) +{ + return skb_queue_len_lockless(&sd->process_queue); } static struct softnet_data *softnet_get_online(loff_t *pos) @@ -169,12 +173,15 @@ static int softnet_seq_show(struct seq_file *seq, void *v) * mapping the data a specific CPU */ seq_printf(seq, - "%08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x\n", + "%08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x " + "%08x %08x\n", sd->processed, sd->dropped, sd->time_squeeze, 0, 0, 0, 0, 0, /* was fastroute */ 0, /* was cpu_collision */ sd->received_rps, flow_limit_count, - softnet_backlog_len(sd), (int)seq->index); + 0, /* was len of two backlog queues */ + (int)seq->index, + softnet_input_pkt_queue_len(sd), softnet_process_queue_len(sd)); return 0; }