On 1/30/2018 8:14 AM, Thomas Monjalon wrote:
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
please review my patch v14 , hope i can fix all your concern, about
rte_device struct , i think if there is not better idea to handler the
null struct issue, the device name should be use as experimental and i
have verify that is ok for use.
