On 1/9/2018 9:44 PM, Thomas Monjalon wrote:
09/01/2018 13:08, Guo, Jia:
Your comments about split it totally make sense ,no doubt that, but my question
is that if split api with the funcational , so the function part should be set
null implement or stake. Any other good idea or tip for that.
bject: Re: [dpdk-dev] [PATCH v7 1/2] eal: add uevent monitor for hot plug
09/01/2018 12:39, Guo, Jia:
So, how can separate the patch into more small patch, use stake or null
implement in function. I think we should consider if it is a economic way now,
if I could explain more detail in code fo
09/01/2018 13:08, Guo, Jia:
> Your comments about split it totally make sense ,no doubt that, but my
> question is that if split api with the funcational , so the function part
> should be set null implement or stake. Any other good idea or tip for that.
Yes when introducing the callback API fi
> --- a/lib/librte_eal/common/include/rte_bus.h
> +++ b/lib/librte_eal/common/include/rte_bus.h
> /**
> + * Device iterator to find a device on a bus.
> + *
> + * This function returns an rte_device if one of those held by the bus
> + * matches the data passed
:45 PM
> To: Guo, Jia
> Cc: Mordechay Haimovsky ; dev@dpdk.org;
> step...@networkplumber.org; Richardson, Bruce ;
> Yigit, Ferruh ; gaetan.ri...@6wind.com; Ananyev,
> Konstantin ; shreyansh.j...@nxp.com; Wu,
> Jingjing ; Zhang, Helin ; Van
> Haaren, Harry
> Subject: Re:
Haaren,
Harry
Subject: Re: [dpdk-dev] [PATCH v7 1/2] eal: add uevent monitor for hot plug
09/01/2018 12:39, Guo, Jia:
> So, how can separate the patch into more small patch, use stake or null
> implement in function. I think we should consider if it is a economic way
> now, if I could exp
On 1/9/2018 7:38 PM, Thomas Monjalon wrote:
09/01/2018 09:25, Guo, Jia:
On 1/9/2018 8:39 AM, Thomas Monjalon wrote:
+int
+_rte_dev_callback_process(struct rte_device *device,
+ enum rte_eal_dev_event_type event,
+ void *cb_arg, void *ret_param)
cb_
; step...@networkplumber.org; Richardson, Bruce
; Yigit, Ferruh ;
gaetan.ri...@6wind.com; Ananyev, Konstantin ;
shreyansh.j...@nxp.com; Wu, Jingjing ; Zhang, Helin
; Van Haaren, Harry
Subject: RE: [dpdk-dev] [PATCH v7 1/2] eal: add uevent monitor for hot plug
Hi Jeff,
The following will not work
09/01/2018 12:39, Guo, Jia:
> So, how can separate the patch into more small patch, use stake or null
> implement in function. I think we should consider if it is a economic way
> now, if I could explain more detail in code for you all not very familiar the
> background? I have sent v8, please c
; shreyansh.j...@nxp.com; Wu, Jingjing
; Zhang, Helin ; Van Haaren,
Harry
Subject: Re: [dpdk-dev] [PATCH v7 1/2] eal: add uevent monitor for hot plug
09/01/2018 11:31, Mordechay Haimovsky:
> From: Guo, Jia [mailto:jia@intel.com]
> > On 1/9/2018 8:39 AM, Thomas Monjalon wrote:
> > >
09/01/2018 09:25, Guo, Jia:
> On 1/9/2018 8:39 AM, Thomas Monjalon wrote:
> >> +int
> >> +_rte_dev_callback_process(struct rte_device *device,
> >> + enum rte_eal_dev_event_type event,
> >> + void *cb_arg, void *ret_param)
> >
> > cb_arg must be an opaque paramete
09/01/2018 11:31, Mordechay Haimovsky:
> From: Guo, Jia [mailto:jia@intel.com]
> > On 1/9/2018 8:39 AM, Thomas Monjalon wrote:
> > > At last there is the kernel binding effort - this one will probably
> > > be ignored for 18.02, because it is another huge topic.
> > > Without bothering with ker
nd.com; konstantin.anan...@intel.com;
shreyansh.j...@nxp.com; jingjing...@intel.com; helin.zh...@intel.com; Mordechay
Haimovsky ; harry.van.haa...@intel.com
Subject: Re: [dpdk-dev] [PATCH v7 1/2] eal: add uevent monitor for hot plug
On 1/9/2018 8:39 AM, Thomas Monjalon wrote:
Hi Jeff,
I am surpris
On 1/9/2018 8:39 AM, Thomas Monjalon wrote:
Hi Jeff,
I am surprised that there is not a lot of review of these very
important patches. Maybe it is not easy to review.
Let's try to progress in the following days.
This patch is really too big with a lot of concepts spread
in separate files, so
Hi Jeff,
I am surprised that there is not a lot of review of these very
important patches. Maybe it is not easy to review.
Let's try to progress in the following days.
This patch is really too big with a lot of concepts spread
in separate files, so it is difficult to properly review.
Please, try
Hi Guo
I answered for the 2 threads here.
From: Guo, Jia, Monday, January 8, 2018 7:27 AM
> On 1/3/2018 1:02 AM, Matan Azrad wrote:
> > Hi Jeff
> >
> > Maybe I'm touching in previous discussions but please see some
> comments\questions.
> >
> > From: Jeff Guo:
> >> This patch aim to add a genera
add one more comment.
On 1/3/2018 1:02 AM, Matan Azrad wrote:
Hi Jeff
Maybe I'm touching in previous discussions but please see some
comments\questions.
From: Jeff Guo:
This patch aim to add a general uevent mechanism in eal device layer,
to enable all linux kernel object hot plug monitorin
thanks , matan
On 1/3/2018 1:02 AM, Matan Azrad wrote:
Hi Jeff
Maybe I'm touching in previous discussions but please see some
comments\questions.
From: Jeff Guo:
This patch aim to add a general uevent mechanism in eal device layer,
to enable all linux kernel object hot plug monitoring, so u
Hi Jeff
Maybe I'm touching in previous discussions but please see some
comments\questions.
From: Jeff Guo:
> This patch aim to add a general uevent mechanism in eal device layer,
> to enable all linux kernel object hot plug monitoring, so user could use these
> APIs to monitor and read out the d
This patch aim to add a general uevent mechanism in eal device layer,
to enable all linux kernel object hot plug monitoring, so user could use these
APIs to monitor and read out the device status info that sent from the kernel
side, then corresponding to handle it, such as detach or attach the
devi
20 matches
Mail list logo