From: Gregory Etelson <gregory@weka.io>
To: "Tan, Jianfeng" <jianfeng.tan@intel.com>
Cc: Ferruh Yigit <ferruh.yigit@intel.com>,
Shijith Thotton <shijith.thotton@caviumnetworks.com>,
Stephen Hemminger <stephen@networkplumber.org>,
dev@dpdk.org, Qi Zhang <qi.z.zhang@intel.com>,
Wenzhuo Lu <wenzhuo.lu@intel.com>,
Thomas Monjalon <thomas@monjalon.net>
Subject: Re: [RFC PATCH] igb_uio: issue FLR during open and release of device file
Date: Mon, 05 Jun 2017 08:57:07 +0300 [thread overview]
Message-ID: <10692952.YuU2RkIBYZ@polaris> (raw)
In-Reply-To: <4e3b8469-b9be-1963-1ca8-7dd000fe7415@intel.com>
Hello Jianfeng,
I was experimenting with pci_disable_device() in release
Tests running on Intel 82599 VF crashed server after process down,
before a new instance was started.
Tests running on Intel XL710 VF did not crash server, but could not send / receive Ethernet frames
although all DPDK initialization routines completed without errors
Regards,
Gregory
Hi Gregory,
On 6/4/2017 3:22 PM, Gregory Etelson wrote:
In my environment I could reproduce server crash
after applying the patch Different from your patch, my patch calls pci_enable_device()/pci_disable_device() instead of pci_reset_function()/pci_try_reset_function() separately in open() and release(). Could you check if that's the reason? vfio_pci actually calls both pci_try_reset_function() and pci_disable_device() in release(). Thanks, Jianfeng
Regards,
Gregory
On Wednesday, 31 May 2017 15:20:08 IDT Ferruh Yigit wrote:
> On 5/31/2017 12:09 PM, Shijith Thotton wrote:
> > Set UIO info device file operations open and release. Call pci reset
> > function inside open and release to clear device state at start and
> > end. Copied this behaviour from vfio_pci kernel module code. With this
> > change, it is not mandatory to issue FLR by PMD's during init and close.
>
> Cc: Jianfeng Tan <jianfeng.tan@intel.com>[1]
>
> Jianfeng also implemented following patch:
> http://dpdk.org/dev/patchwork/patch/17495/[2]
>
> Which also implements release and open ops, for slightly different
> reason (prevent DMA access after app exit), but mainly both are to
> gracefully handle application exit status.
>
> btw, for Jianfeng's case, can adding pci_clear_master() in release and
> moving pci_set_master() to open help preventing unwanted DMA?
>
>
> Gregory,
>
> Can you please check if this patch fixes your issue?
>
> Thanks,
> ferruh
>
> >
> > Signed-off-by: Shijith Thotton <shijith.thotton@caviumnetworks.com>[3]
> > ---
> > lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 30 ++++++++++++++++++++++++++++++
> > 1 file changed, 30 insertions(+)
> >
> > diff --git a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
> > index b9d427c..5bc58d2 100644
> > --- a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
> > +++ b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
> > @@ -170,6 +170,34 @@ struct rte_uio_pci_dev {
> > return IRQ_HANDLED;
> > }
> >
> > +/**
> > + * This gets called while opening uio device file. It clears any previous state
> > + * associated with the pci device.
> > + */
> > +static int
> > +igbuio_pci_open(struct uio_info *info, struct inode *inode)
> > +{
> > + struct rte_uio_pci_dev *udev = info->priv;
> > + struct pci_dev *dev = udev->pdev;
> > +
> > + /* reset the pci device */
> > + pci_reset_function(dev);
> > +
> > + return 0;
> > +}
> > +
> > +static int
> > +igbuio_pci_release(struct uio_info *info, struct inode *inode)
> > +{
> > + struct rte_uio_pci_dev *udev = info->priv;
> > + struct pci_dev *dev = udev->pdev;
> > +
> > + /* try to reset the pci device */
> > + pci_try_reset_function(dev);
> > +
> > + return 0;
> > +}
> > +
> > #ifdef CONFIG_XEN_DOM0
> > static int
> > igbuio_dom0_mmap_phys(struct uio_info *info, struct vm_area_struct *vma)
> > @@ -372,6 +400,8 @@ struct rte_uio_pci_dev {
> > udev->info.version = "0.1";
> > udev->info.handler = igbuio_pci_irqhandler;
> > udev->info.irqcontrol = igbuio_pci_irqcontrol;
> > + udev->info.open = igbuio_pci_open;
> > + udev->info.release = igbuio_pci_release;
> > #ifdef CONFIG_XEN_DOM0
> > /* check if the driver run on Xen Dom0 */
> > if (xen_initial_domain())
> >
>
>
--------
[1] mailto:jianfeng.tan@intel.com
[2] http://dpdk.org/dev/patchwork/patch/17495/
[3] mailto:shijith.thotton@caviumnetworks.com
next prev parent reply other threads:[~2017-06-05 5:57 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-24 11:22 i40e igb_uio: reset pci on process exit Gregory Etelson
2017-05-25 18:42 ` Stephen Hemminger
2017-05-26 4:30 ` Gregory Etelson
2017-05-26 6:05 ` Shijith Thotton
2017-05-26 6:17 ` Gregory Etelson
2017-05-26 15:53 ` Stephen Hemminger
2017-05-26 16:14 ` Gregory Etelson
2017-05-29 9:48 ` Shijith Thotton
2017-05-29 10:01 ` Gregory Etelson
2017-05-29 11:01 ` Shijith Thotton
2017-05-29 11:21 ` Gregory Etelson
2017-05-31 11:09 ` [RFC PATCH] igb_uio: issue FLR during open and release of device file Shijith Thotton
2017-05-31 12:20 ` Ferruh Yigit
2017-05-31 15:30 ` Stephen Hemminger
2017-05-31 17:11 ` Ferruh Yigit
2017-06-01 11:35 ` Shijith Thotton
2017-06-01 11:14 ` Gregory Etelson
2017-06-04 7:22 ` Gregory Etelson
2017-06-05 2:29 ` Tan, Jianfeng
2017-06-05 5:57 ` Gregory Etelson [this message]
2017-05-31 15:29 ` Stephen Hemminger
2017-06-12 9:38 ` [PATCH] " Shijith Thotton
2017-07-05 23:42 ` Thomas Monjalon
2017-07-06 16:41 ` Ferruh Yigit
2017-07-06 17:27 ` Gregory Etelson
2017-07-07 10:03 ` Shijith Thotton
2017-07-07 10:16 ` Ferruh Yigit
2017-07-07 11:13 ` [PATCH v2] " Shijith Thotton
2017-07-07 15:10 ` Ferruh Yigit
2017-07-10 3:07 ` Gregory Etelson
2017-07-11 5:42 ` Gregory Etelson
2017-07-11 11:36 ` Gregory Etelson
2017-07-10 3:38 ` Tan, Jianfeng
2017-07-10 7:10 ` Shijith Thotton
2017-07-10 9:00 ` Tan, Jianfeng
2017-07-10 10:42 ` Shijith Thotton
2017-07-12 3:37 ` Tan, Jianfeng
2017-07-12 3:40 ` Tan, Jianfeng
2017-07-19 13:32 ` Ferruh Yigit
2017-07-19 16:19 ` Gregory Etelson
2017-07-20 22:36 ` Thomas Monjalon
-- strict thread matches above, loose matches on Subject: below --
2017-07-16 4:22 [SPDK] " Gregory Etelson
2017-07-16 4:22 ` Gregory Etelson
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=10692952.YuU2RkIBYZ@polaris \
--to=gregory@weka.io \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=jianfeng.tan@intel.com \
--cc=qi.z.zhang@intel.com \
--cc=shijith.thotton@caviumnetworks.com \
--cc=stephen@networkplumber.org \
--cc=thomas@monjalon.net \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.