From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olivier MATZ Subject: Re: [PATCH v5 19/19] timer: add support to non-EAL thread Date: Fri, 13 Feb 2015 10:57:40 +0100 Message-ID: <54DDCA94.2070300@6wind.com> References: <1422842559-13617-1-git-send-email-cunming.liang@intel.com> <1423728996-3004-1-git-send-email-cunming.liang@intel.com> <1423728996-3004-20-git-send-email-cunming.liang@intel.com> <2601191342CEEE43887BDE71AB977258213E5585@irsmsx105.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit To: "Liang, Cunming" , "Ananyev, Konstantin" , "dev-VfR2kkLFssw@public.gmane.org" Return-path: In-Reply-To: List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" Hi, On 02/13/2015 01:55 AM, Liang, Cunming wrote: >> About ' lcore_id != LCORE_ID_ANY' vs ' lcore_id < RTE_MAX_LCORE'. >> I think both ways are valid right now. >> Though using ' lcore_id != LCORE_ID_ANY' means, that if user will setup >> PER_LCORE(_lcore_id) for dynamically created thread to some value >= >> RTE_MAX_LCORE, >> then our code will not work properly. >> Konstantin > [LCM] Ok, now we get the agreement as below. > 1. only using '< RTE_MAX_LCORE' to check the EAL thread with valid lcore_id. > 2. LCORE_ID_ANY is used as lcore_id default value or used for any unspecified lcore_id assignment. Doing like this is fine for me, although I don't really agree with the initial argument: it's should not be allowed for an application to modify an eal variable (_lcore_id). Regards, Olivier