[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+FuTScxef=wytuNXgRuFFYMOZk_VzVSG9jvstuT2uAgK43v5Q@mail.gmail.com>
Date: Tue, 6 Oct 2020 07:57:51 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Vladimir Oltean <vladimir.oltean@....com>
Cc: Willem de Bruijn <willemdebruijn.kernel@...il.com>,
Jacob Keller <jacob.e.keller@...el.com>,
Network Development <netdev@...r.kernel.org>,
David Miller <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>
Subject: Re: [PATCH net-next] net: always dump full packets with skb_dump
On Tue, Oct 6, 2020 at 7:43 AM Vladimir Oltean <vladimir.oltean@....com> wrote:
>
> On Tue, Oct 06, 2020 at 07:30:13AM -0400, Willem de Bruijn wrote:
> > skb_dump is called from skb_warn_bad_offload and netdev_rx_csum_fault.
> > Previously when these were triggered, a few example bad packets were
> > sufficient to debug the issue.
>
> Yes, and it's only netdev_rx_csum_fault that matters, because
> skb_warn_bad_offload calls with full_pkt=false anyway.
>
> During the times when I had netdev_rx_csum_fault triggered, it was
> pretty bad anyway. I don't think that full_pkt getting unset after 5
> skbs made too big of a difference.
>
> > A full dump can add a lot of data to the kernel log, so I limited to
> > what is strictly needed.
>
> Yes, well my expectation is that other people are using skb_dump for
> debugging, even beyond those 2 callers in the mainline kernel. And when
> they want to dump with full_pkt=true, they really want to dump with
> full_pkt=true.
Sure, that makes sense.
Powered by blists - more mailing lists