All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Vladimir Oltean <vladimir.oltean@nxp.com>
Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
	Jacob Keller <jacob.e.keller@intel.com>,
	Network Development <netdev@vger.kernel.org>,
	David Miller <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>
Subject: Re: [PATCH net-next] net: always dump full packets with skb_dump
Date: Tue, 6 Oct 2020 07:57:51 -0400	[thread overview]
Message-ID: <CA+FuTScxef=wytuNXgRuFFYMOZk_VzVSG9jvstuT2uAgK43v5Q@mail.gmail.com> (raw)
In-Reply-To: <20201006114322.aq276lij2ovhdtts@skbuf>

On Tue, Oct 6, 2020 at 7:43 AM Vladimir Oltean <vladimir.oltean@nxp.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.

  reply	other threads:[~2020-10-06 11:58 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-05 14:48 [PATCH net-next] net: always dump full packets with skb_dump Vladimir Oltean
2020-10-05 22:13 ` Jacob Keller
2020-10-06 11:30   ` Willem de Bruijn
2020-10-06 11:43     ` Vladimir Oltean
2020-10-06 11:57       ` Willem de Bruijn [this message]
2020-10-06 13:14 ` David Miller

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='CA+FuTScxef=wytuNXgRuFFYMOZk_VzVSG9jvstuT2uAgK43v5Q@mail.gmail.com' \
    --to=willemdebruijn.kernel@gmail.com \
    --cc=davem@davemloft.net \
    --cc=jacob.e.keller@intel.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=vladimir.oltean@nxp.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.