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 D2AD2425E9; Mon, 25 Sep 2023 11:46:17 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 18483402CC; Mon, 25 Sep 2023 11:46:17 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mails.dpdk.org (Postfix) with ESMTP id 8E2C0402B7 for ; Mon, 25 Sep 2023 11:46:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1695635175; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zR7edSNkFneNvlv3NX91jiF64l2T4GQu6K7B9VL72FY=; b=Kna5oeiBLSEweZMOKoSbq1DVRIXsgcmY9SPSOJ+/VClrjREH60bQ4wyA66mS3MKTPlhf5e VeeP56UnGgE1FpikbszzFmm6lIbtMPKl6bYvJWaYWBD0o7NERoQ6mKN+5oDWhY8FZ5UfOL VdiYQREXvRguF5lLjTxBiXdmINLCFig= Received: from mail-lf1-f71.google.com (mail-lf1-f71.google.com [209.85.167.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-67-GgaFoEECPTi__33yWwzgGw-1; Mon, 25 Sep 2023 05:46:13 -0400 X-MC-Unique: GgaFoEECPTi__33yWwzgGw-1 Received: by mail-lf1-f71.google.com with SMTP id 2adb3069b0e04-5043eb2c436so6417682e87.3 for ; Mon, 25 Sep 2023 02:46:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695635172; x=1696239972; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=zR7edSNkFneNvlv3NX91jiF64l2T4GQu6K7B9VL72FY=; b=alYndhrDQQ/UZcf8I1cwlkDDsTQKhn9XGAx7FfDXMdzvq/2mOi4DO+ZYED0SBpOqHq KE+rYWCwby7pbueDKQK3hdj8fXgHbQYnWKGGEt5kXUDEYM7qY8p1beUg+wfJYjLHw/dC eqvzBH97KSbmD2MlwZglX5J/t9uIwFIqecrzhyVga/7nakD4wITorEnmvsr2LzH/O6kt YioX2Hs1mwUjHHP8CNBk9il1Pr1wyUemA7lgbpilWZCzVccbrWpTDDXNzeQrxUCCkc+H r7hPV+7BBYQZnJaGusZkEKJA8PBfHlLCAyNBxBO5eKhIQQwNakB3PRVHT8ZlSMu5aS7y hltA== X-Gm-Message-State: AOJu0Ywt+RdjnUYVupwUebGInnJeaheSBtY61vu4sMNMMiB47+yMQ/yC OUJmVUjQfF7W0MiwE8Xl+9Rel/Qi8w1bkcZ218lOBQgzZQZJ+yzAGcOZQSf0C2yEX1kniPW4LMZ cWu8/s37UHjzHf+5zh9o= X-Received: by 2002:ac2:4db0:0:b0:503:33ab:8126 with SMTP id h16-20020ac24db0000000b0050333ab8126mr5080781lfe.17.1695635172172; Mon, 25 Sep 2023 02:46:12 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGYuNTJi+Wh/lC7gCTz8LwY8/j/enLxJSBDW+43jWUmWQ4ESO2JM/dX1yJlxiGIUHHyQkfHVdOjQN1FsVV72xg= X-Received: by 2002:ac2:4db0:0:b0:503:33ab:8126 with SMTP id h16-20020ac24db0000000b0050333ab8126mr5080771lfe.17.1695635171881; Mon, 25 Sep 2023 02:46:11 -0700 (PDT) MIME-Version: 1.0 References: <20230922093722.2057688-1-david.marchand@redhat.com> <20230922093722.2057688-2-david.marchand@redhat.com> In-Reply-To: From: David Marchand Date: Mon, 25 Sep 2023 11:46:00 +0200 Message-ID: Subject: Re: [PATCH 1/2] eal: introduce x86 processor identification To: Bruce Richardson Cc: dev@dpdk.org, ferruh.yigit@amd.com, thomas@monjalon.net, konstantin.v.ananyev@yandex.ru, ruifeng.wang@arm.com, zhoumin@loongson.cn, drc@linux.vnet.ibm.com, kda@semihalf.com, roretzla@linux.microsoft.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 On Fri, Sep 22, 2023 at 12:40=E2=80=AFPM Bruce Richardson wrote: > > On Fri, Sep 22, 2023 at 11:37:20AM +0200, David Marchand wrote: > > In some really specific cases, it may be needed to get a detailed > > information on the processor running a DPDK application for drivers to > > achieve better performance, or for matters that concern only them. > > > > Those information are highly arch-specific and require a specific API. > > > > Introduce a set of functions to get brand, family and model of a x86 > > processor. > > Those functions do not make sense on other arches and a > > driver must first check rte_cpu_is_x86() before anything else. > > > > Signed-off-by: David Marchand > > --- > > Couple of thoughts, having had a few minutes to process this. > > * Rather than rte_cpu_is_x86() API, we could go a general API called > rte_cpu_arch() which returns either a string, or an enum value. Within > that, rather than #ifdefs, the actual return value could just be a defi= ne > placed by meson in the rte_build_config.h file. The list of families > according to meson are [1] - we'd just need to merge the 32 and 64-bit > variants into one in the meson file. Your proposal (in next mail) lgtm. > > * Similarly rather than having is_intel or is_amd functions, we could > generalize to a "manufacturer" API, which could be applicable for other > architectures too. Like a rte_cpu_x86_manufacturer() ? which returns an enum too I suppose. --=20 David Marchand