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] ixgbevf does not recover from pf reset
Date: Mon, 25 Jan 2016 01:58:28 +0000 [thread overview]
Message-ID: <9BB6961774997848B5B42BEC655768F8D8C51C@SHSMSX104.ccr.corp.intel.com> (raw)
In-Reply-To: <CALwxeUsC=tW5z+hLtiyYyu4NJDPoAURXqsVu5=qHxxLmTLvKzA@mail.gmail.com>
Hi
Yes. But just consider about how to use DPDK on eth device. During bring up we need:
eth_dev_init
rte_pktmbuf_pool_create
rte_eth_dev_configure
rte_eth_rx_queue_setup
rte_eth_tx_queue_setup
rte_eth_dev_start
All above behavior need to be called by application, pmd driver cannot did all the
Recovery without application's help.
By the simple notification mechanism, application can simple call following step to recovery:
Stop forwarding on this device (rx, tx)
rte_eth_dev_close
rte_eth_dev_detach
rte_eth_dev_attach
rte_eth_dev_configure
rte_eth_rx_queue_setup
rte_eth_tx_queue_setup
rte_eth_dev_start
Any idea is welcome. We are eager to hear better solution on that.
Anyway, no matter whether the recovery is done by application, the patches mentioned
Is also useful to notice user about the even. Correct?
Thanks
Jingjing
> -----Original Message-----
> From: David Marchand [mailto:david.marchand@6wind.com]
> Sent: Friday, January 22, 2016 4:54 PM
> To: Wu, Jingjing
> Cc: Zhang, Helin; Ananyev, Konstantin; Lu, Wenzhuo; dev@dpdk.org
> Subject: Re: [dpdk-dev] ixgbevf does not recover from pf reset
>
> Hello,
>
> On Fri, Jan 22, 2016 at 3:05 AM, Wu, Jingjing <jingjing.wu@intel.com> wrote:
> > Hi, David
> >
> > We also noticed this issue before. And we are planning to fix this issue.
> > And the patch for i40e is ready:
> > http://dpdk.org/dev/patchwork/patch/9832/
> > http://dpdk.org/dev/patchwork/patch/9833/
> >
> > The solution is that: PF reset interrupt will be captured by DPDK VF,
> > then DPDK Call the application's callback function to reset the VF
> > device. For i40e device, application need to detach and re-attach the device.
> >
> > For ixgbe, I think the solution would be similar.
>
> Ok, so to handle a problem in hardware, the application must implement a
> new mechanism to recover the port ?
> I don't find this solution really elegant ...
>
> This should be handled by the pmd itself.
>
>
> Regards,
> --
> David Marchand
next prev parent reply other threads:[~2016-01-25 1:58 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-11 14:46 David Marchand
2016-01-22 2:05 ` Wu, Jingjing
2016-01-22 8:54 ` David Marchand
2016-01-25 1:58 ` Wu, Jingjing [this message]
2016-01-25 15:05 ` David Marchand
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=9BB6961774997848B5B42BEC655768F8D8C51C@SHSMSX104.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).