Netdev List
 help / color / mirror / Atom feed
From: Stefan Assmann <sassmann@redhat.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Tony Nguyen <anthony.l.nguyen@intel.com>,
	davem@davemloft.net,
	Jedrzej Jagielski <jedrzej.jagielski@intel.com>,
	netdev@vger.kernel.org,
	Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>,
	Konrad Jankowski <konrad0.jankowski@intel.com>
Subject: Re: [PATCH net-next 06/12] iavf: Add trace while removing device
Date: Thu, 25 Nov 2021 16:43:49 +0100	[thread overview]
Message-ID: <20211125154349.ozf6jfq5kmzoou4j@x230> (raw)
In-Reply-To: <20211125071316.69c3319a@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>

On 2021-11-25 07:13, Jakub Kicinski wrote:
> On Thu, 25 Nov 2021 07:50:49 +0100 Stefan Assmann wrote:
> > On 2021-11-24 15:48, Jakub Kicinski wrote:
> > > On Wed, 24 Nov 2021 09:16:46 -0800 Tony Nguyen wrote:  
> > > > Add kernel trace that device was removed.
> > > > Currently there is no such information.
> > > > I.e. Host admin removes a PCI device from a VM,
> > > > than on VM shall be info about the event.
> > > > 
> > > > This patch adds info log to iavf_remove function.  
> > > 
> > > Why is this an important thing to print to logs about?
> > > If it is why is PCI core not doing the printing?
> > 
> > From personal experience I'd say this piece of information has value,
> > especially when debugging it can be interesting to know exactly when
> > the driver was removed.
> 
> But there isn't anything specific to iavf here, right? If it really 
> is important then core should be doing the printing for all drivers.
> 
> Actually, I can't come up with any uses for this print on the spot.
> What debugging scenarios do you have in mind?

There was a lot of trouble with iavf in terms of device reset, device
unbinding (DPDK), stress testing of driver load/unload issues. When
looking through the crash logs it was not always easy to determine if
the driver was still loaded.
Especially on problems that weren't easy to reproduce.

So for iavf having that information would have been valuable. Not sure
if that justifies a PCI core message or if others might find that too
verbose.

  Stefan


  reply	other threads:[~2021-11-25 15:46 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-24 17:16 [PATCH net-next 00/12][pull request] 40GbE Intel Wired LAN Driver Updates 2021-11-24 Tony Nguyen
2021-11-24 17:16 ` [PATCH net-next 01/12] iavf: restore MSI state on reset Tony Nguyen
2021-11-24 23:42   ` Jakub Kicinski
2021-11-29 18:41     ` Nguyen, Anthony L
2021-11-24 17:16 ` [PATCH net-next 02/12] iavf: Add change MTU message Tony Nguyen
2021-11-24 23:46   ` Jakub Kicinski
2021-11-29 18:43     ` Nguyen, Anthony L
2021-11-30  0:53       ` Jakub Kicinski
2021-11-24 17:16 ` [PATCH net-next 04/12] iavf: return errno code instead of status code Tony Nguyen
2021-11-24 17:16 ` [PATCH net-next 05/12] iavf: don't be so alarming Tony Nguyen
2021-11-25  6:45   ` Stefan Assmann
2021-11-29 18:44     ` Nguyen, Anthony L
2021-11-24 17:16 ` [PATCH net-next 06/12] iavf: Add trace while removing device Tony Nguyen
2021-11-24 23:48   ` Jakub Kicinski
2021-11-25  6:50     ` Stefan Assmann
2021-11-25 15:13       ` Jakub Kicinski
2021-11-25 15:43         ` Stefan Assmann [this message]
2021-11-25 15:57           ` Jakub Kicinski
2021-11-25 16:46             ` Stefan Assmann
2021-11-24 17:16 ` [PATCH net-next 07/12] iavf: Enable setting RSS hash key Tony Nguyen
2021-11-24 17:16 ` [PATCH net-next 08/12] iavf: Refactor iavf_mac_filter struct memory usage Tony Nguyen
2021-11-24 23:49   ` Jakub Kicinski
2021-11-26 10:13     ` Jagielski, Jedrzej
2021-11-24 17:16 ` [PATCH net-next 09/12] iavf: Fix static code analysis warning Tony Nguyen
2021-11-24 17:16 ` [PATCH net-next 10/12] iavf: Refactor text of informational message Tony Nguyen
2021-11-24 17:16 ` [PATCH net-next 11/12] iavf: Refactor string format to avoid static analysis warnings Tony Nguyen
2021-11-24 17:16 ` [PATCH net-next 12/12] iavf: Fix displaying queue statistics shown by ethtool Tony Nguyen
2021-11-24 23:42 ` [PATCH net-next 00/12][pull request] 40GbE Intel Wired LAN Driver Updates 2021-11-24 Jakub Kicinski
2021-11-29 18:46   ` Nguyen, Anthony L

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=20211125154349.ozf6jfq5kmzoou4j@x230 \
    --to=sassmann@redhat.com \
    --cc=anthony.l.nguyen@intel.com \
    --cc=arkadiusz.kubalewski@intel.com \
    --cc=davem@davemloft.net \
    --cc=jedrzej.jagielski@intel.com \
    --cc=konrad0.jankowski@intel.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.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