[dpdk-dev] [PATCH V13 1/3] eal: add uevent monitor api and callback func

Thomas Monjalon thomas at monjalon.net
Tue Jan 30 01:14:06 CET 2018


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


More information about the dev mailing list