From: Steven Rostedt <rostedt@goodmis.org>
To: Eric Dumazet <edumazet@google.com>
Cc: Brendan Gregg <brendan.d.gregg@gmail.com>,
Zhongya Yan <yan2228598786@gmail.com>,
Jakub Kicinski <kuba@kernel.org>, netdev <netdev@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@redhat.com>,
David Miller <davem@davemloft.net>,
Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
David Ahern <dsahern@kernel.org>,
hengqi.chen@gmail.com, Yonghong Song <yhs@fb.com>
Subject: Re: [PATCH] net: tcp_drop adds `reason` parameter for tracing v2
Date: Wed, 01 Sep 2021 13:44:12 -0400 [thread overview]
Message-ID: <FC4E868F-CAF2-4DB9-A7A5-80E43CB73213@goodmis.org> (raw)
In-Reply-To: <CANn89i+rHC4AC88-V8QqBU36waaOxTVoii0xaEKk+oerzC3Egw@mail.gmail.com>
On September 1, 2021 11:20:58 AM EDT, Eric Dumazet <edumazet@google.com> wrote:
>On Wed, Sep 1, 2021 at 7:36 AM Steven Rostedt <rostedt@goodmis.org>
>wrote:
>>
>> On Thu, 26 Aug 2021 15:13:07 +1000
>> Brendan Gregg <brendan.d.gregg@gmail.com> wrote:
>>
>> > On Thu, Aug 26, 2021 at 1:20 PM Steven Rostedt
><rostedt@goodmis.org> wrote:
>> > >
>> > > On Wed, 25 Aug 2021 08:47:46 -0700
>> > > Eric Dumazet <edumazet@google.com> wrote:
>> > >
>> > > > > @@ -5703,15 +5700,15 @@ static bool
>tcp_validate_incoming(struct sock *sk, struct sk_buff *skb,
>> > > > > TCP_INC_STATS(sock_net(sk),
>TCP_MIB_INERRS);
>> > > > > NET_INC_STATS(sock_net(sk),
>LINUX_MIB_TCPSYNCHALLENGE);
>> > > > > tcp_send_challenge_ack(sk, skb);
>> > > > > - goto discard;
>> > > > > + tcp_drop(sk, skb, TCP_DROP_MASK(__LINE__,
>TCP_VALIDATE_INCOMING));
>> > > >
>> > > > I'd rather use a string. So that we can more easily identify
>_why_ the
>> > > > packet was drop, without looking at the source code
>> > > > of the exact kernel version to locate line number 1057
>> > > >
>> > > > You can be sure that we will get reports in the future from
>users of
>> > > > heavily modified kernels.
>> > > > Having to download a git tree, or apply semi-private patches is
>a no go.
>> > > >
>> > > > If you really want to include __FILE__ and __LINE__, these both
>can be
>> > > > stringified and included in the report, with the help of
>macros.
>> > >
>> > > I agree the __LINE__ is pointless, but if this has a tracepoint
>> > > involved, then you can simply enable the stacktrace trigger to it
>and
>> > > it will save a stack trace in the ring buffer for you.
>> > >
>> > > echo stacktrace >
>/sys/kernel/tracing/events/tcp/tcp_drop/trigger
>> > >
>> > > And when the event triggers it will record a stack trace. You can
>also
>> > > even add a filter to do it only for specific reasons.
>> > >
>> > > echo 'stacktrace if reason == 1' >
>/sys/kernel/tracing/events/tcp/tcp_drop/trigger
>> > >
>> > > And it even works for flags:
>> > >
>> > > echo 'stacktrace if reason & 0xa' >
>/sys/kernel/tracing/events/tcp/tcp_drop/trigger
>> > >
>> > > Which gives another reason to use an enum over a string.
>> >
>> > You can't do string comparisons? The more string support Ftrace
>has,
>> > the more convenient they will be. Using bpftrace as an example of
>> > convenience and showing drop frequency counted by human-readable
>> > reason and stack trace:
>>
>> Yes, you can (and pretty much always had this ability), but having
>> flags is usually makes it easier (and faster).
>>
>> You can have 'stacktrace if reason ~ "*string*"' which will match
>> anything with "string" in it.
>>
>> My main argument against strings is more of the space they take up in
>> the ring buffer than the ability to filter.
>
>Understood the concern about size, but it seems the trace includes many
>things.
>Can we have an estimate of the size needed per event ?
>If we do not use symbolic, but numbers, I am afraid this trace event
>will only be used by a few TCP experts.
Note, the output is still text, not numeric, as the __print_symbolic() macro will convert the numbers to text.
Or is there another issue you have with the enum?
-- Steve
>
>+ TP_printk("src=%pISpc dest=%pISpc mark=%#x data_len=%d
>snd_nxt=%#x snd_una=%#x \
>+ snd_cwnd=%u ssthresh=%u snd_wnd=%u
>srtt=%u rcv_wnd=%u \
>+ sock_cookie=%llx reason=%d
>reason_type=%s reason_line=%d",
> __entry->saddr, __entry->daddr, __entry->mark,
> __entry->data_len, __entry->snd_nxt,
>__entry->snd_una,
> __entry->snd_cwnd, __entry->ssthresh,
>__entry->snd_wnd,
>- __entry->srtt, __entry->rcv_wnd,
>__entry->sock_cookie, __entry->reason)
>+ __entry->srtt, __entry->rcv_wnd,
>__entry->sock_cookie,
>+ __entry->reason,
>+ __print_symbolic(__entry->reason_code,
>TCP_DROP_REASON),
>+ __entry->reason_line)
> );
--
Sent from my Android device with K-9 Mail. Please excuse my brevity and top posting.
prev parent reply other threads:[~2021-09-01 17:44 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-25 15:40 [PATCH] net: tcp_drop adds `reason` parameter for tracing v2 Zhongya Yan
2021-08-25 15:47 ` Eric Dumazet
2021-08-25 16:04 ` Jakub Kicinski
2021-08-25 16:20 ` Eric Dumazet
2021-08-25 17:06 ` Jakub Kicinski
2021-08-26 3:19 ` Steven Rostedt
2021-08-26 5:13 ` Brendan Gregg
2021-09-01 14:36 ` Steven Rostedt
2021-09-01 15:20 ` Eric Dumazet
2021-09-01 17:44 ` Steven Rostedt [this message]
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=FC4E868F-CAF2-4DB9-A7A5-80E43CB73213@goodmis.org \
--to=rostedt@goodmis.org \
--cc=brendan.d.gregg@gmail.com \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=hengqi.chen@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=yan2228598786@gmail.com \
--cc=yhs@fb.com \
--cc=yoshfuji@linux-ipv6.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