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

Guo, Jia jia.guo at intel.com
Tue Jan 30 13:20:42 CET 2018



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.



More information about the dev mailing list