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 88758432BD; Mon, 6 Nov 2023 22:37:34 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4DABE402BA; Mon, 6 Nov 2023 22:37:34 +0100 (CET) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by mails.dpdk.org (Postfix) with ESMTP id D1264402B6; Mon, 6 Nov 2023 22:37:32 +0100 (CET) Received: from frapeml100006.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4SPPk82RYbz6K5sY; Tue, 7 Nov 2023 05:34:08 +0800 (CST) Received: from frapeml500007.china.huawei.com (7.182.85.172) by frapeml100006.china.huawei.com (7.182.85.201) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Mon, 6 Nov 2023 22:37:31 +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; Mon, 6 Nov 2023 22:37:31 +0100 From: Konstantin Ananyev To: Bruce Richardson CC: "dev@dpdk.org" , "techboard@dpdk.org" , Euan Bourke Subject: RE: Updating examples which use coremask parameters Thread-Topic: Updating examples which use coremask parameters Thread-Index: AQHaDZ0C5zZwZGGgB0ylrySSGvnh7rBoX7IQ///yEQCABYPK4A== Date: Mon, 6 Nov 2023 21:37:31 +0000 Message-ID: <8d2ceeb3b16b4467ac98942d8067d736@huawei.com> References: <152ecf4d5e4a4b78a9bf91ab78234532@huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.81.189.69] 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 > > > > > > looking to start a discussion and get some input here. > > > > > > There are a number of our examples in DPDK which still track core usa= ge via > > > 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 iss= ue are > > > "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 = cores, > > > for worker cores and optionally for scheduler cores. > > > > > > 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 th= e > > > user, since dealing with long bitmasks is very awkward and unwieldy. = Better > > > instead to convert all examples using coremasks to using core lists > > > instead. > > > > > > First step should be to take our EAL corelist processing code and ref= actor > > > it into a function that can be made public, so that it can be used by= all > > > apps for parsing core lists. Simple enough! > > > > > > The next part I'm looking for input on is - how do we switch the apps= from > > > coremasks to core lists? Some options: > > > > > > 1. Add in new commandline parameters for each app to work with core l= ists. > > > This is what we did in the past with EAL, by adding -l as a replace= ment > > > for -c. The advantage is that we maintain backward compatibility, b= ut the > > > downside is that it becomes hard to find new suitable letter option= s for > > > the core lists. Taking eventdev_pipeline again, we would need "new" > > > options for "-r", "-t", "-w" and "-s" parameters. Using the capital= ized > > > versions of these would be a simple alternative, but "-W" is alread= y used > > > as an app parameter so we can't do that. > > > > > > 2. Just break backward compatibility and switch the apps to taking > > > core lists instead of masks. Advantage is that it gives us the clea= nest > > > solution, but the downside is that and testing done using these exa= mples, > > > or any users who may have run them in the past, get different behav= iour. > > > > > > As it is for examples, I also don't see any issue with converting to co= re-list. > > Said that, I suppose we still want to keep EAL '-c' (coremask) paramete= r, right? > > If so, then it might be plausible to consider making the code that hand= les it > > to work with really-long ones (up to 1K, or whatever is our current CPU= _SET limit). >=20 > I believe the EAL coremask parsing already supports >64 lcores, and works > with arbitrary lengths up to RTE_MAX_LCORE, so I think we are ok here. It > parses the coremask char-by-char (backwards) as a string, rather than > trying to convert it using atoi-type functions[1]. Great, thanks for clarifying. I suppose next question here - would it make sense to convert that code in= to some public API, so we can have one function for core-mask parsing that will be used for bo= th EAL and user apps?=20 =20 >=20 > /Bruce >=20 > [1] http://git.dpdk.org/dpdk/tree/lib/eal/common/eal_common_options.c#n77= 7