From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id C997A43279; Fri, 3 Nov 2023 11:11:10 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A542640284; Fri, 3 Nov 2023 11:11:10 +0100 (CET) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by mails.dpdk.org (Postfix) with ESMTP id AA6284027F; Fri, 3 Nov 2023 11:11:09 +0100 (CET) Received: from frapeml500007.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4SMGhP5Mblz6K7D6; Fri, 3 Nov 2023 18:10:13 +0800 (CST) Received: from frapeml500007.china.huawei.com (7.182.85.172) by frapeml500007.china.huawei.com (7.182.85.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Fri, 3 Nov 2023 11:11:08 +0100 Received: from frapeml500007.china.huawei.com ([7.182.85.172]) by frapeml500007.china.huawei.com ([7.182.85.172]) with mapi id 15.01.2507.031; Fri, 3 Nov 2023 11:11:08 +0100 From: Konstantin Ananyev To: Bruce Richardson , "dev@dpdk.org" , "techboard@dpdk.org" CC: Euan Bourke Subject: RE: Updating examples which use coremask parameters Thread-Topic: Updating examples which use coremask parameters Thread-Index: AQHaDZ0C5zZwZGGgB0ylrySSGvnh7rBoX7IQ Date: Fri, 3 Nov 2023 10:11:08 +0000 Message-ID: <152ecf4d5e4a4b78a9bf91ab78234532@huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.48.154.242] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org > Hi all, >=20 > looking to start a discussion and get some input here. >=20 > There are a number of our examples in DPDK which still track core usage v= ia > a 64-bit bitmask, and, as such, cannot run on cores between 64 and > RTE_MAX_LCORE. Two examples I have recently come across with this issue a= re > "eventdev_pipeline" and "qos_sched", but I am sure there are others. The > former is a good example (or bad example depending on your viewpoint) of > this as it takes multiple coremask parameters - for RX cores, for TX core= s, > for worker cores and optionally for scheduler cores. >=20 > Now, the simple solution to this is to just expand the 64-bit bitmask to > 128 bit or more, but I think that is just making things harder for the > user, since dealing with long bitmasks is very awkward and unwieldy. Bett= er > instead to convert all examples using coremasks to using core lists > instead. >=20 > First step should be to take our EAL corelist processing code and refacto= r > it into a function that can be made public, so that it can be used by all > apps for parsing core lists. Simple enough! >=20 > The next part I'm looking for input on is - how do we switch the apps fro= m > coremasks to core lists? Some options: >=20 > 1. Add in new commandline parameters for each app to work with core lists= . > This is what we did in the past with EAL, by adding -l as a replacement > for -c. The advantage is that we maintain backward compatibility, but t= he > downside is that it becomes hard to find new suitable letter options fo= r > the core lists. Taking eventdev_pipeline again, we would need "new" > options for "-r", "-t", "-w" and "-s" parameters. Using the capitalized > versions of these would be a simple alternative, but "-W" is already us= ed > as an app parameter so we can't do that. >=20 > 2. Just break backward compatibility and switch the apps to taking > core lists instead of masks. Advantage is that it gives us the cleanest > solution, but the downside is that and testing done using these example= s, > or any users who may have run them in the past, get different behaviour= . As it is for examples, I also don't see any issue with converting to core-l= ist. Said that, I suppose we still want to keep EAL '-c' (coremask) parameter, r= ight? If so, then it might be plausible to consider making the code that handles = it to work with really-long ones (up to 1K, or whatever is our current CPU_SET= limit). Then if we'll have such function as a public one, users can still probably = continue to use core-mask/core-list at their best convenience. =20 >=20 > 3. An interesting further alternative is to allow apps to take both > coremasks and corelists and use heuristics to determine which is which. > For example, anything starting with "0x" is a mask, anything containing > "-" or "," is a list. There would be ambiguous values such as e.g. 2, > which could be either, but we can always find ways to disambiguate thes= e, > e.g. allow trailing commas in lists, so that "0x2" is the coremask, and= "2," > is the corelist. [Could be other alternatives]. This largely keeps back= ward > compatibility and also allows use of corelists. >=20 > 4. something else?? >=20 > Thoughts and feedback, please? We'd like to upstream some fixes for the > examples in 2024 and would rather get agreement on the approach now than > head down a wrong approach. Personally, I'd rather avoid #1, and #3 is > neat, but perhaps being overly smart/complicated? >=20 > Regards, > /Bruce