From: Bruce Richardson <bruce.richardson@intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v4 2/2] i40evf: support to report pf reset event
Date: Wed, 9 Mar 2016 11:01:38 +0000 [thread overview]
Message-ID: <20160309110138.GB16076@bricha3-MOBL3> (raw)
In-Reply-To: <3177758.3DUFdx3GZH@xps13>
On Wed, Mar 09, 2016 at 10:59:56AM +0100, Thomas Monjalon wrote:
> 2016-03-09 14:00, Jingjing Wu:
> > When Linux PF and DPDK VF are used for i40e PMD, In case of PF reset,
> > interrupt will go via adminq event, VF need be informed the event,
> > a callback mechanism is introduced by VF. This will allow VF to
> > invoke callback when reset happens.
> > Users can register a callback for this interrupt event like:
> > rte_eth_dev_callback_register(portid,
> > RTE_ETH_EVENT_INTR_RESET,
> > reset_event_callback,
> > arg);
> [...]
> > --- a/doc/guides/rel_notes/release_16_04.rst
> > +++ b/doc/guides/rel_notes/release_16_04.rst
> > @@ -105,6 +105,8 @@ This section should contain new features added in this release. Sample format:
> > be down.
> > We added the support of auto-neg by SW to avoid this link down issue.
> >
> > +* **Added pf reset event reported in i40e vf PMD driver.
>
> Bruce, is this comment clear enough for an user?
>
> Beware of the wrong formating (missing **)
It's pretty ok, though I might word it a little differently myself. "reported"
should be "reporting".
Your question, though, does bring up the issue of scope and reviews again. I, as
committer, spend a lot of time tweaking commit messages, sanity checking
patches for compilation errors under various settings, and running checkpatch
etc. before applying them. However, IMHO it is up to the maintainers of the
various subsystems to enforce proper documentation in the patches submitted.
The maintainers are the primary gatekeepers here, and I, for one, don't want to
end up having to review all patches in detail before I apply them - otherwise
we'll be limited to a very small number of driver patches per release :)
In this case, if the submitter of the patch and the maintainer of the driver in
question are happy with the documentation, then who am I to go querying that. :-)
Having committers do full review on apply will only have two possible effects:
1. make the maintainers less conscientious about their job, since they know the
committers will catch any real bugs or issues on apply
2. cause a lot of problems for submitters as they see a lot of issues being
flagged at the last minute by committers, when they thought their patch was
safely acked and ready for commit for some time.
We certainly see lots of the second issue occurring right now, I believe - [I'm
obvously not going to comment on the former :-)]
I'd be very much in favour of having a rule that once a patch is acked by a
maintainer, then it must be applied. We may suffer a bit from slightly lower
quality patches getting applied, but the speed of applying patches should
increase, and the patch contents can always be fixed by subsequent patches later.
[Unlike commit message which can't be fixed later without rewriting git history]
In this case, I feel that phrase "the perfect is the enemy of the good" applies.
https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good
Just my 2c on this. I'm sure you have a different view, Thomas, so it's probably
a discussion worth having.
/Bruce
next prev parent reply other threads:[~2016-03-09 11:01 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-13 12:31 [dpdk-dev] [PATCH 0/2] i40evf: support interrupt based pf reset request Jingjing Wu
2016-01-13 12:31 ` [dpdk-dev] [PATCH 1/2] i40evf: allocate virtchnl cmd buffer for each vf Jingjing Wu
2016-01-13 12:31 ` [dpdk-dev] [PATCH 2/2] i40evf: support interrupt based pf reset request Jingjing Wu
2016-01-27 1:49 ` [dpdk-dev] [PATCH v2 0/2] " Jingjing Wu
2016-01-27 1:49 ` [dpdk-dev] [PATCH v2 1/2] i40evf: allocate virtchnl cmd buffer for each vf Jingjing Wu
2016-01-29 7:28 ` Tao, Zhe
2016-02-14 2:22 ` Wu, Jingjing
2016-02-22 7:26 ` Zhang, Helin
2016-01-27 1:49 ` [dpdk-dev] [PATCH v2 2/2] i40evf: support interrupt based pf reset request Jingjing Wu
2016-01-27 8:34 ` David Marchand
2016-02-14 3:25 ` Wu, Jingjing
2016-02-15 13:16 ` David Marchand
2016-02-18 4:06 ` Zhe Tao
2016-02-19 5:51 ` Wu, Jingjing
2016-01-28 7:03 ` Tao, Zhe
2016-02-14 2:12 ` Wu, Jingjing
2016-01-29 8:50 ` Tao, Zhe
2016-02-14 3:04 ` Wu, Jingjing
2016-02-22 8:26 ` Zhang, Helin
2016-02-26 6:51 ` [dpdk-dev] [PATCH v3 0/2] i40evf: pf reset event report Jingjing Wu
2016-02-26 6:51 ` [dpdk-dev] [PATCH v3 1/2] i40evf: allocate virtchnl cmd buffer for each vf Jingjing Wu
2016-02-26 8:12 ` Zhang, Helin
2016-02-26 6:51 ` [dpdk-dev] [PATCH v3 2/2] i40evf: support to report pf reset event Jingjing Wu
2016-02-26 8:13 ` Zhang, Helin
2016-03-08 17:44 ` [dpdk-dev] [PATCH v3 0/2] i40evf: pf reset event report Bruce Richardson
2016-03-09 3:08 ` Zhe Tao
2016-03-09 6:00 ` [dpdk-dev] [PATCH v4 " Jingjing Wu
2016-03-09 6:00 ` [dpdk-dev] [PATCH v4 1/2] i40evf: allocate virtchnl cmd buffer for each vf Jingjing Wu
2016-03-09 6:00 ` [dpdk-dev] [PATCH v4 2/2] i40evf: support to report pf reset event Jingjing Wu
2016-03-09 9:59 ` Thomas Monjalon
2016-03-09 11:01 ` Bruce Richardson [this message]
2016-03-09 11:26 ` [dpdk-dev] expectations on maintainer's review Thomas Monjalon
2016-03-09 14:15 ` Bruce Richardson
2016-03-09 14:19 ` Thomas Monjalon
2016-03-10 3:41 ` [dpdk-dev] [PATCH v5 0/2] i40evf: pf reset event report Jingjing Wu
2016-03-10 3:41 ` [dpdk-dev] [PATCH v5 1/2] i40evf: allocate virtchnl cmd buffer for each vf Jingjing Wu
2016-03-14 12:21 ` Bruce Richardson
2016-03-10 3:41 ` [dpdk-dev] [PATCH v5 2/2] i40evf: support to report pf reset event Jingjing Wu
2016-03-15 1:59 ` [dpdk-dev] [PATCH v6 0/2] i40evf: pf reset event report Jingjing Wu
2016-03-15 1:59 ` [dpdk-dev] [PATCH v6 1/2] i40evf: allocate virtchnl cmd buffer for each vf Jingjing Wu
2016-03-15 1:59 ` [dpdk-dev] [PATCH v6 2/2] i40evf: support to report pf reset event Jingjing Wu
2016-03-22 15:13 ` [dpdk-dev] [PATCH v6 0/2] i40evf: pf reset event report Bruce Richardson
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=20160309110138.GB16076@bricha3-MOBL3 \
--to=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=thomas.monjalon@6wind.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).