From: "Wu, Jingjing" <jingjing.wu@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: Fri, 19 Feb 2016 05:51:15 +0000 [thread overview]
Message-ID: <9BB6961774997848B5B42BEC655768F8DA8650@SHSMSX103.ccr.corp.intel.com> (raw)
In-Reply-To: <CALwxeUunZn1SRWP_j-HsDYH4RKzQwb9UuXuMdS9ZO-98bXJwRw@mail.gmail.com>
> I reported an issue on ixgbe.
Yes, thanks, we also notice such issue on ixgbe.
> What you provide here is a workaround for i40e.
> I am not even sure this can be applied to ixgbe.
>
Yes, not just workaround, also a basic one, without the patch, DPDK VF even
doesn't know the pf reset happened. I think ixgbe also need to know that.
> 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 ?
Currently as my understanding DPDK PMD driver is part of DPDK library.
Even the driver loading is in the thread which is created by application. From this
side, there is no a task which managed by driver internally. In fact, we also help
the reset process can be down automatically or at least provide an simple API to
application to help them recovery simply. Maybe the latter one is following the
current DPDK's framework. Otherwise, we need a thread for each driver?
And back to this patch, the patch just make the interrupt of pf reset can be received
by i40e vf PMD driver. It didn't change the ethdev/eal.....
I don't think you have objection to it, right?
About how to process the reset event, we can raise another thread to discuss?
> 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.
>
Agree about the resource listing. But again, about the "internally", can you share your idea about it?
As you know, pmd driver even have no internal thread.
> If this proves to be generic enough, maybe moving part of this to
> ethdev will then make sense.
>
We can discuss, I think most NICs may have such issue. We need to make agreement on that.
Thanks
Jingjing
>
> Thanks.
>
> --
> David Marchand
next prev parent reply other threads:[~2016-02-19 5:51 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
2016-02-19 5:51 ` Wu, Jingjing [this message]
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=9BB6961774997848B5B42BEC655768F8DA8650@SHSMSX103.ccr.corp.intel.com \
--to=jingjing.wu@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).