From: "Tan, Jianfeng" <jianfeng.tan@intel.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] bus/vdev: add custom scan hook
Date: Wed, 6 Dec 2017 10:48:39 +0800 [thread overview]
Message-ID: <484ecb30-1eae-c1c8-adce-2318dab2f4b1@intel.com> (raw)
In-Reply-To: <1712827.SmiPysL3o0@xps>
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Tuesday, December 5, 2017 11:21 PM
> To: Tan, Jianfeng
> Cc: dev@dpdk.org
> Subject: Re: [PATCH] bus/vdev: add custom scan hook
>
> 05/12/2017 14:56, Tan, Jianfeng:
> >
> > On 12/5/2017 4:41 PM, Thomas Monjalon wrote:
> > >
> > > 05/12/2017 09:27, Tan, Jianfeng:
> > >
> > > >
> > >
> > > > On 12/4/2017 5:31 PM, Thomas Monjalon wrote:
> > >
> > > > >
> > >
> > > > > The hook is in bus->scan().
> > >
> > > > > I think we should launch a bus scan when there is a new
device event.
> > >
> > > >
> > >
> > > > That's what I'm trying to say. We finally need to execute a
handler as
> > >
> > > > of a device event to finish the job.
> > >
> > > Please be more specific, I am not sure to understand.
> > >
> >
> > By the handler, I mean when we monitor the udev by
select/poll/epoll and
> > device uevents come, the application will execute a handler (or just a
> > function) for each of such uevent. Then why not adding the vdev there?
>
> Because it must work for hotplug, and initial scan too.
> We can also think to application requiring a manual scan.
> The bus scan is the right place to have every scans called. That's
simple.
Yes, the logic is simpler; anything changes, appication just invokes a
scan.Then we will have a somewhat complex hook that: (1) scan all
devices and identify added/removed devices; (2) and add vdev for added
device; (3) remove vdev for removed device.
Compared to that, we can separate the implementation for hotplug and
initial scan:
* For initial scan, iterate all devices to add vdev for each of them.
* For hotplug, based on which device is added/removed, we just
add/remove the corresponding vdev for that device.
Anyway, since this patch does provide a new way; and will not affect the
other way. So I think it's OK to add this.
Thank you for your clarification.
Thanks,
Jianfeng
next prev parent reply other threads:[~2017-12-06 2:48 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-01 0:36 Thomas Monjalon
2017-12-01 0:40 ` Thomas Monjalon
2017-12-01 5:48 ` Tan, Jianfeng
2017-12-01 8:42 ` Thomas Monjalon
2017-12-04 8:08 ` Tan, Jianfeng
2017-12-04 9:31 ` Thomas Monjalon
2017-12-05 8:27 ` Tan, Jianfeng
2017-12-05 8:41 ` Thomas Monjalon
2017-12-05 13:56 ` Tan, Jianfeng
2017-12-05 15:21 ` Thomas Monjalon
2017-12-06 2:48 ` Tan, Jianfeng [this message]
2017-12-06 2:52 ` Tan, Jianfeng
2017-12-06 9:21 ` Thomas Monjalon
2017-12-07 2:30 ` Tan, Jianfeng
2017-12-30 21:21 ` [dpdk-dev] [PATCH v2] " Thomas Monjalon
2018-01-03 1:16 ` Tan, Jianfeng
2018-01-03 8:05 ` Thomas Monjalon
2018-01-08 23:25 ` [dpdk-dev] [PATCH v3] " Thomas Monjalon
2018-01-11 23:47 ` Thomas Monjalon
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=484ecb30-1eae-c1c8-adce-2318dab2f4b1@intel.com \
--to=jianfeng.tan@intel.com \
--cc=dev@dpdk.org \
--cc=thomas@monjalon.net \
/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).