From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Alejandro Lucero <alejandro.lucero@netronome.com>,
"Tan, Jianfeng" <jianfeng.tan@intel.com>
Cc: Gregory Etelson <gregory@weka.io>, dev <dev@dpdk.org>,
"users@dpdk.org" <users@dpdk.org>
Subject: Re: [dpdk-users] [dpdk-dev] IGB_UIO: PCI Resources Management
Date: Thu, 19 Jan 2017 16:36:58 +0000 [thread overview]
Message-ID: <af30ec3e-7410-840f-b72c-e45f5179740b@intel.com> (raw)
In-Reply-To: <CAD+H990mr0tF5WGVSo9=4q0NS4KHzgSKeZUNY_MqRkyB88AkzA@mail.gmail.com>
On 1/13/2017 11:10 AM, Alejandro Lucero wrote:
> I completely misread the patch, and I wrongly thought that code was
> linked to module removal, but I see this is not about that, but about
> releasing the /dev/uio file calling release function, what is done by
> the kernel when the process exits.
>
> So yes, the patch avoids the problem I talked about.
>
> However, calling that specific ixgbe driver function will break other
> devices relying on igb_uio. What about implementing a notifier chain for
> this? The igb_uio code would be agnostic and each interested driver,
> like ixgbe or nfp_net, could execute the specific port close code when
> the notifier chain triggers.
Can you please elaborate, how can this be done?
This is kernel code, and interested drivers are in userspace. This patch
benefit from Linux kernel driver of same device.
>
>
> On Fri, Jan 13, 2017 at 5:33 AM, Tan, Jianfeng <jianfeng.tan@intel.com
> <mailto:jianfeng.tan@intel.com>> wrote:
>
>
>
> > -----Original Message-----
> > From: Yigit, Ferruh
> > Sent: Friday, January 13, 2017 10:05 AM
> > To: Tan, Jianfeng; Alejandro Lucero
> > Cc: Gregory Etelson; dev; users@dpdk.org <mailto:users@dpdk.org>
> > Subject: Re: [dpdk-users] [dpdk-dev] IGB_UIO: PCI Resources Management
> >
> > On 1/13/2017 1:51 AM, Tan, Jianfeng wrote:
> > >
> > >
> > >> -----Original Message-----
> > >> From: users [mailto:users-bounces@dpdk.org
> <mailto:users-bounces@dpdk.org>] On Behalf Of Ferruh Yigit
> > >> Sent: Thursday, January 12, 2017 8:22 PM
> > >> To: Alejandro Lucero
> > >> Cc: Gregory Etelson; dev; users@dpdk.org <mailto:users@dpdk.org>
> > >> Subject: Re: [dpdk-users] [dpdk-dev] IGB_UIO: PCI Resources
> > Management
> > >>
> > >> On 1/12/2017 12:12 PM, Alejandro Lucero wrote:
> > >>>
> > >>>
> > >>> On Thu, Jan 12, 2017 at 11:55 AM, Ferruh Yigit
> <ferruh.yigit@intel.com <mailto:ferruh.yigit@intel.com>
> > >>> <mailto:ferruh.yigit@intel.com
> <mailto:ferruh.yigit@intel.com>>> wrote:
> > >>>
> > >>> On 12/9/2016 8:54 AM, Gregory Etelson wrote:
> > >>> > Hello,
> > >>> >
> > >>> > IGB_UIO driver does not close port PCI activities after
> DPDK process
> > >> exits.
> > >>> > DPDK API provides rte_eth_dev_close() to manage port PCI,
> > >>> > but it can be skipped if process receives SIGKILL signal
> > >>>
> > >>> I guess I understand the problem.
> > >>>
> > >>>
> > >>> This is a known problem, but it is not just a UIO problem, and
> this
> > >>> patch does not solve it, maybe it just solves part of it.
> > >>>
> > >>> In fact, a DPDK program crashing could imply the NIC DMAing
> after that
> > >>> and after that memory was assigned to another program.
> > >>
> > >> Yes.
> > >> Can there be a way to stop NIC DMA, (or prevent it access to mem
> > >> anymore) when app crashes?
> > >> I think that is what this patch is looking for.
> > >
> > > If I understand it correctly, you are looking for this patch?
> > > http://dpdk.org/dev/patchwork/patch/17495/
> <http://dpdk.org/dev/patchwork/patch/17495/>
> > >
> >
> > That is good, thanks Jianfeng, I will check it.
> >
> > btw, patch's current state is rejected, which is by mistake, it
> seems I
> > confused it with "iomem and ioport mapping" patch, sorry about it, I
> > will update its status immediately.
>
> No problem at all. This patch is rejected as it's based on "iomem
> and ioport mapping" patch. As "iomem and ioport mapping" patch has
> backward compatibility issue, we need to figure out a way to
> resubmit this patch without changing the original "iomem and ioport
> mapping" in igb_uio.
>
> Thanks,
> Jianfeng
>
>
next prev parent reply other threads:[~2017-01-19 16:37 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-09 8:54 [dpdk-users] " Gregory Etelson
2017-01-12 11:55 ` Ferruh Yigit
2017-01-12 12:12 ` [dpdk-users] [dpdk-dev] " Alejandro Lucero
2017-01-12 12:22 ` Ferruh Yigit
2017-01-12 12:58 ` Alejandro Lucero
2017-01-13 1:51 ` Tan, Jianfeng
2017-01-13 2:04 ` Ferruh Yigit
2017-01-13 5:33 ` Tan, Jianfeng
2017-01-13 11:10 ` Alejandro Lucero
2017-01-19 16:36 ` Ferruh Yigit [this message]
2017-01-19 20:33 ` Alejandro Lucero
2017-01-19 15:59 ` Ferruh Yigit
2017-01-19 16:09 ` George Prekas
2017-01-20 5:09 ` Tan, Jianfeng
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=af30ec3e-7410-840f-b72c-e45f5179740b@intel.com \
--to=ferruh.yigit@intel.com \
--cc=alejandro.lucero@netronome.com \
--cc=dev@dpdk.org \
--cc=gregory@weka.io \
--cc=jianfeng.tan@intel.com \
--cc=users@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).