From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <jia.guo@intel.com>
Received: from mga03.intel.com (mga03.intel.com [134.134.136.65])
by dpdk.org (Postfix) with ESMTP id 0098A1B3FA
for <dev@dpdk.org>; Tue, 30 Jan 2018 13:20:51 +0100 (CET)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga006.fm.intel.com ([10.253.24.20])
by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
30 Jan 2018 04:20:45 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.46,435,1511856000"; d="scan'208";a="199925857"
Received: from junhaoga-mobl1.ccr.corp.intel.com (HELO [10.255.26.165])
([10.255.26.165])
by fmsmga006.fm.intel.com with ESMTP; 30 Jan 2018 04:20:43 -0800
To: Thomas Monjalon <thomas@monjalon.net>,
Bruce Richardson <bruce.richardson@intel.com>, harry.van.haaren@intel.com
References: <1516248723-16985-3-git-send-email-jia.guo@intel.com>
<20180126165340.GA21468@bricha3-MOBL3.ger.corp.intel.com>
<4dba572b-38e1-33b8-2009-c7d977b8b012@intel.com> <2094855.jKUssMJQjQ@xps>
Cc: dev@dpdk.org, stephen@networkplumber.org, gaetan.rivet@6wind.com,
jingjing.wu@intel.com, motih@mellanox.com, ferruh.yigit@intel.com,
konstantin.ananyev@intel.com, shreyansh.jain@nxp.com, helin.zhang@intel.com
From: "Guo, Jia" <jia.guo@intel.com>
Message-ID: <9767bc3a-7592-ec77-e849-b0f53044b4d3@intel.com>
Date: Tue, 30 Jan 2018 20:20:42 +0800
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101
Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <2094855.jKUssMJQjQ@xps>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [dpdk-dev] [PATCH V13 1/3] eal: add uevent monitor api and
callback func
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Jan 2018 12:20:52 -0000
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.