27/01/2018 04:48, Guo, Jia:
> On 1/27/2018 12:53 AM, Bruce Richardson wrote:
> > On Fri, Jan 26, 2018 at 11:49:35AM +0800, Jeff Guo wrote:
> >> + ret = rte_service_lcore_add(slcore);
> >> + if (ret) {
> >> + RTE_LOG(ERR, EAL, "dev event monitor lcore add fail");
> >> + return ret;
> >> + }
> >> +
> > I don't think you should be taking another service core for this purpose
> > without the user asking for it. I also don't think service cores is the
> > right "tool" for monitoring the epoll. Rather than using a non-blocking
> > poll on a service core, I think you should look to reuse the existing
> > infrastructure for handling interrupts in the EAL, which relies on a
> > separate thread blocked on fd's awaiting input.
>
> bruce, seems that you might be see the other view of the mountain, so if
> service cores tools basically be born to need user knowledge and
> control it, and it is no need to add user to control service tool in the
> case, i thinks we might not use the existing interrupts infrastructure
> because it is the device uevent not interrupt as the same functional
> scope , we could use a separate thread which i have used before in v7
> to specialize poll the uevent, please check v7 part to see if it is good.
The v7 was using pthread_create, so it was not the right solution.
> @tomas, do you agree with that above , or other suggestion, could it be
> got agreement all or let it improvement later?
I have no issue about using rte_service.
I think the other events processing in EAL could use rte_service.
Maybe Harry has a different view?
My main concerns are:
1/ There is not enough review
2/ The callback lookup is using device name from uevent
3/ There is no reference to the rte_device struct
Minor extra requirement: the new __rte_experimental should be used,
see http://dpdk.org/commit/77b7b81e32e
