DPDK patches and discussions
 help / color / mirror / Atom feed
From: Zhe Tao <zhe.tao@intel.com>
To: David Marchand <david.marchand@6wind.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v2 2/2] i40evf: support interrupt based pf reset request
Date: Thu, 18 Feb 2016 12:06:20 +0800	[thread overview]
Message-ID: <20160218040620.GA17470@intel.com> (raw)
In-Reply-To: <CALwxeUunZn1SRWP_j-HsDYH4RKzQwb9UuXuMdS9ZO-98bXJwRw@mail.gmail.com>

On Mon, Feb 15, 2016 at 02:16:16PM +0100, David Marchand wrote:
Hello,
> 
> On Sun, Feb 14, 2016 at 4:25 AM, Wu, Jingjing <jingjing.wu@intel.com> wrote:
> >> -----Original Message-----
> >> From: David Marchand [mailto:david.marchand@6wind.com]
> >> Having this infrastructure is one thing, but the initial problem was that the
> >> driver did not recover from this reset event.
> >> The linux i40e vf driver handles this kind of event itself.
> >> Could we have something similar ?
> >>
> >
> > Considering about the how to use DPDK PMD, and how to setup resource, we can
> > know that lots of resources are managed by application. I think based on current
> > PMD driver framework, driver cannot reset without application's help.
> 
> I reported an issue on ixgbe.
> What you provide here is a workaround for i40e.
> I am not even sure this can be applied to ixgbe.
> 
> Does it mean that anytime we have a problem with drivers, workarounds
> should be applied to ethdev / eal ... so that you don't have to handle
> anything in the drivers ?
I think this patch provides a necessary framework for i40e VF to handle
the asynchronous event, maybe Jingjing can help to change the description of
this patch to let it does not limit to the VF reset event. 
> This is not the first time I complain about this kind of design issues.
> 
> 
> > If we need to support driver recovery automatically, we'd better to find a way to do that.
> > Do you have any idea?
> 
> First, list those "lots of resources" that "are managed by application".
> If your driver needs to keep track of those, this is i40e driver job
> to do this internally without requiring ethdev to be modified.
> 
> If this proves to be generic enough, maybe moving part of this to
> ethdev will then make sense.
> 
> 
> Thanks.
> 
> -- 
> David Marchand
Thanks,

Zhe Tao

  reply	other threads:[~2016-02-18  4:06 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-13 12:31 [dpdk-dev] [PATCH 0/2] " 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 [this message]
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
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
2016-01-27  1:46 [dpdk-dev] [PATCH v2 0/2] i40evf: support interrupt based pf reset request Jingjing Wu
2016-01-27  1:46 ` [dpdk-dev] [PATCH v2 2/2] " Jingjing Wu

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=20160218040620.GA17470@intel.com \
    --to=zhe.tao@intel.com \
    --cc=david.marchand@6wind.com \
    --cc=dev@dpdk.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;
as well as URLs for NNTP newsgroup(s).