From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id AC6A3A0C4D;
	Thu,  2 Sep 2021 08:02:01 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id 314FE40140;
	Thu,  2 Sep 2021 08:02:01 +0200 (CEST)
Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113])
 by mails.dpdk.org (Postfix) with ESMTP id 4719E4013F
 for <dev@dpdk.org>; Thu,  2 Sep 2021 08:01:59 +0200 (CEST)
Received: from [192.168.38.17] (aros.oktetlabs.ru [192.168.38.17])
 (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by shelob.oktetlabs.ru (Postfix) with ESMTPSA id 896477F5F5;
 Thu,  2 Sep 2021 09:01:58 +0300 (MSK)
DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 896477F5F5
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru;
 s=default; t=1630562518;
 bh=IKIKdj7/OMmqZNDreFolFa+//R/qb5pxIzJrLULKy0g=;
 h=Subject:To:Cc:References:From:Date:In-Reply-To;
 b=qKCRDGeykeM/BLniFGXfMloMLL6xg9cgW4p8TB3FdFNqMJ9z1OnfGQeGBEOEQ4ICJ
 dVQP2MDUYv7vXuL5JDb/q8ULkikr3S4QTxCJVZ6+kJsXn6TAaObjG8z+ESyQ9hUBvI
 hTj85+SDYab2+sOhxqfK49vJGLV2yJ+r9yrs0Tqs=
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: dev@dpdk.org
References: <20210831200839.93556-1-stephen@networkplumber.org>
 <057efbd9-f3ec-b4c7-5add-fdf7baeebbee@oktetlabs.ru>
 <20210901101611.260d79bc@hermes.local>
From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Organization: OKTET Labs
Message-ID: <ae3c4e88-8731-9df0-7ad0-225c45d4391b@oktetlabs.ru>
Date: Thu, 2 Sep 2021 09:01:58 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <20210901101611.260d79bc@hermes.local>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [dpdk-dev] [PATCH] eal: make rte_lcore_cpuset and
 rte_lcore_to_cpu_id stable
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On 9/1/21 8:16 PM, Stephen Hemminger wrote:
> 
>>>  /**
>>> - * @warning
>>> - * @b EXPERIMENTAL: this API may change without prior notice.
>>> - *
>>>   * Return the cpuset for a given lcore.
>>>   * @param lcore_id
>>>   *   the targeted lcore, which MUST be between 0 and RTE_MAX_LCORE-1.
>>>   * @return
>>>   *   The cpuset of that lcore
>>>   */
>>> -__rte_experimental
>>>  rte_cpuset_t
>>>  rte_lcore_cpuset(unsigned int lcore_id);  
>>
>> I'm wondering why negative lcore_id is supported above
>> with special meaning, but not supported here.
> 
> The DPDK API stability in this case means staying bug-for-bug
> compatible. I.e passing -1 as unsigned int results in UINT_MAX which
> is invalid.

Isn't promotion to stable the last chance to review and
fix without much pain?