From: Luca Boccassi <bluca@debian.org>
To: Remy Horton <remy.horton@intel.com>, dev@dpdk.org
Cc: wenzhuo.lu@intel.com, wei.dai@intel.com
Subject: Re: [dpdk-dev] [PATCH 2/2] ethdev: pre-emptively document rte_eth_dev_reset error code
Date: Thu, 19 Oct 2017 17:14:19 +0100 [thread overview]
Message-ID: <1508429659.31273.2.camel@debian.org> (raw)
In-Reply-To: <f8b9604d-c718-8b1a-c97d-3c3ebd24a295@intel.com>
On Thu, 2017-10-19 at 15:53 +0100, Remy Horton wrote:
> On 19/10/2017 14:48, luca.boccassi@gmail.com wrote:
> > Document it immediately even if it's not yet supported, so that
> > users
> > and developers can already take into account about this use case,
> > and
> > thus avoid an API-incompatible change later on.
>
> I'm not sure about documenting unimplemented features, as API docs
> ought
> to describe what the code currently does. Then again reason seems OK
> and
> I don't think there's hard guidelines on this..
Yeah I realised that, that's why it's a separate patch :-)
I'm just trying to avoid a foreseeable API breakage given we've been
using this API in production.
OTOH there are a few cases where perhaps EAGAIN is already a possible
error code to return - for example where the driver fails to
initialise? For example there's an error path that just returns -1 in
i40evf_dev_init
> > This is based on real-world production usage and customer
> > escalations,
> > using earlier patches from Intel.
>
> Can you give the patchwork link for these patches?
>
>
> ..Remy
Based on these ones:
http://dpdk.org/dev/patchwork/patch/14009/
http://dpdk.org/dev/patchwork/patch/14011/
http://dpdk.org/dev/patchwork/patch/14010/
I had sent some feedback, as especially the ixgbe one was a blocking
call in case the PF was down, which is a deal breaker in most
situations given the API will be called from the controller thread in
most cases.
We've adapted and used these patches with the early rte_eth_dev_reset
for a year in production now, and we had a customer who requested it
since they were running into the problem it solves (PF flaps).
I have adapted them on the latest 17.11 tree and tested with X540
10gbit cards, and it seems to work as before. Should I send an RFC and
CC all of you?
Incidentally, are there specific reasons why the VF functionality was
dropped since the first patches were sent?
--
Kind regards,
Luca Boccassi
next prev parent reply other threads:[~2017-10-19 16:14 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-19 13:48 [dpdk-dev] [PATCH 1/2] ethdev: document rte_eth_dev_reset return codes luca.boccassi
2017-10-19 13:48 ` [dpdk-dev] [PATCH 2/2] ethdev: pre-emptively document rte_eth_dev_reset error code luca.boccassi
2017-10-19 14:53 ` Remy Horton
2017-10-19 16:14 ` Luca Boccassi [this message]
2017-10-24 6:18 ` Remy Horton
2017-10-24 12:01 ` Luca Boccassi
2017-10-23 22:11 ` Thomas Monjalon
2017-10-24 12:00 ` Luca Boccassi
2017-10-19 14:52 ` [dpdk-dev] [PATCH 1/2] ethdev: document rte_eth_dev_reset return codes Remy Horton
2017-10-24 11:03 ` [dpdk-dev] [PATCH v2 " luca.boccassi
2017-10-24 11:03 ` [dpdk-dev] [PATCH v2 2/2] ethdev: pre-emptively document rte_eth_dev_reset error code luca.boccassi
2017-10-24 12:29 ` Thomas Monjalon
2017-10-24 12:27 ` [dpdk-dev] [PATCH v2 1/2] ethdev: document rte_eth_dev_reset return codes Thomas Monjalon
2017-10-24 13:19 ` Luca Boccassi
2017-10-24 13:19 ` [dpdk-dev] [PATCH v3 1/2] ethdev: document error codes of reset luca.boccassi
2017-10-24 13:19 ` [dpdk-dev] [PATCH v3 2/2] ethdev: document new error code for reset luca.boccassi
2017-10-24 20:41 ` [dpdk-dev] [PATCH v3 1/2] ethdev: document error codes of reset Ferruh Yigit
2017-10-25 12:01 ` Luca Boccassi
2017-10-25 16:08 ` Ferruh Yigit
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=1508429659.31273.2.camel@debian.org \
--to=bluca@debian.org \
--cc=dev@dpdk.org \
--cc=remy.horton@intel.com \
--cc=wei.dai@intel.com \
--cc=wenzhuo.lu@intel.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).