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 87D9742616 for ; Fri, 22 Sep 2023 11:43:42 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7BB4040395; Fri, 22 Sep 2023 11:43:42 +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 7A690402CB for ; Fri, 22 Sep 2023 11:43:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1695375821; 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=b/wzkhPNoBrKt7mzml3cOG5T2EGJJg3qdbVha3DziPw=; b=aA5HgDdGNVNVvNH82H0LwzxCudOH4aL6cGWS9DQBfmoSLiaCwN+V1cgMExdVZ/awuNXBWm qZjfh73hTB+ouhqEs+a7Iq69N52Nu+/8j09sQYOFAmwUOf7Z3xNwRVRUHl2G7a4OHZx7zh kvLhZzaVO/rIPXW7CDXh0AyUcaI7Kj8= Received: from mail-lj1-f198.google.com (mail-lj1-f198.google.com [209.85.208.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-127-Y70piJkfNJekJW0r0bW_wg-1; Fri, 22 Sep 2023 05:43:37 -0400 X-MC-Unique: Y70piJkfNJekJW0r0bW_wg-1 Received: by mail-lj1-f198.google.com with SMTP id 38308e7fff4ca-2bffb48a78cso25255191fa.0 for ; Fri, 22 Sep 2023 02:43:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695375816; x=1695980616; 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=b/wzkhPNoBrKt7mzml3cOG5T2EGJJg3qdbVha3DziPw=; b=P5iotQEljH1RSecdvC8CgV/pqMfN2oJ7vZUJnS3KMSt5JLu5ry7+wbm5J/l8YW3g8Y 8dffxJgrdjj4Z0qtSJSShrMsI5c33nm09Ee5rvIquOhE51KRA9QFdy3BenBjBqlmyi5p vJz2sPLGvFYceQZ+TV8+W4xFyFrbFJbVYbJsrQxpUQPYc/Rb0RZisN3i4KEaxUZB+jao JnqDF0AOIuxfAvwMQhJJn4O7ran9Y7prdlolMn7eMTlpp9TzkIqSpAgzaCL0ngQ1hyaw DXdzTDEl2CoWwxvgkUGIUg1DqSkSMdbIvoehQXoRCyqlD/EgIdxgXmZDwlQGEat90XfM RLMA== X-Gm-Message-State: AOJu0YwVFOOfS9VMvCqGh/dRDpNFXH0btOf9U5urIf9W/2b/by5jhzi8 Po+OedzhZjo6E7nrdbVi2rRH8jpCX3oT6xe0iyqN0mvKnzoLmNHHMtrLZihtwVkG35wJepr0RGR 8Y4Q3G+HfSWun7HTHtBrPoGM= X-Received: by 2002:a05:651c:201a:b0:2c0:a0d:1f0a with SMTP id s26-20020a05651c201a00b002c00a0d1f0amr816410ljo.18.1695375816221; Fri, 22 Sep 2023 02:43:36 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHzDOyxiEUdKeHbsWK8VVNqbO7GwR4pj2C4QtzXb2CqBaFJwUnj0UArYBL2VDxanoCMY59//LuOigdRRDfCYQQ= X-Received: by 2002:a05:651c:201a:b0:2c0:a0d:1f0a with SMTP id s26-20020a05651c201a00b002c00a0d1f0amr816390ljo.18.1695375815902; Fri, 22 Sep 2023 02:43:35 -0700 (PDT) MIME-Version: 1.0 References: <20230831123131.4787-1-selwin.sebastian@amd.com> <1e1f06fd-c004-4612-90ba-c6322df27941@amd.com> <4bab144e-f37d-4266-a2ff-afa91f0dad6f@amd.com> In-Reply-To: <4bab144e-f37d-4266-a2ff-afa91f0dad6f@amd.com> From: David Marchand Date: Fri, 22 Sep 2023 11:43:23 +0200 Message-ID: Subject: Re: [PATCH v1] net/axgbe: use CPUID to identify cpu To: Ferruh Yigit Cc: Selwin Sebastian , stable@dpdk.org, dev@dpdk.org, Bruce Richardson , Tyler Retzlaff , =?UTF-8?Q?Morten_Br=C3=B8rup?= , Honnappa Nagarahalli , Jerin Jacob Kollanukkaran , David Christensen , Min Zhou , Stanislaw Kardach X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org On Fri, Sep 15, 2023 at 4:35=E2=80=AFPM Ferruh Yigit = wrote: > > On 9/15/2023 2:02 PM, David Marchand wrote: > > On Fri, Sep 15, 2023 at 12:54=E2=80=AFPM Ferruh Yigit wrote: > >> > >> On 8/31/2023 1:31 PM, Selwin Sebastian wrote: > >>> Using root complex to identify cpu will not work for vm passthrough. > >>> CPUID is used to get family and modelid to identify cpu > >>> > >>> Fixes: b0db927b5eba ("net/axgbe: use PCI root complex device to disti= nguish device") > >>> Cc: stable@dpdk.org > >>> > >>> Signed-off-by: Selwin Sebastian > >>> --- > >>> drivers/net/axgbe/axgbe_ethdev.c | 102 ++++++++++++++++++-----------= -- > >>> 1 file changed, 59 insertions(+), 43 deletions(-) > >>> > >>> diff --git a/drivers/net/axgbe/axgbe_ethdev.c b/drivers/net/axgbe/axg= be_ethdev.c > >>> index 48714eebe6..59f5d713d0 100644 > >>> --- a/drivers/net/axgbe/axgbe_ethdev.c > >>> +++ b/drivers/net/axgbe/axgbe_ethdev.c > >>> @@ -12,6 +12,8 @@ > >>> > >>> #include "eal_filesystem.h" > >>> > >>> +#include > >>> + > >>> > >> > >> This patch cause build errors for some non x86 architecture, because o= f > >> 'cpuid.h'. > >> > >> There is already a 'rte_cpuid.h' file that includes 'cpuid.h' and it i= s > >> x86 only file. > >> > >> @Selwin, does it makes sense to implement the feature you are trying t= o > >> get in eal/x86 level and use that API in the driver? > > > > This driver was expected to compile on all arches. > > The meson.build seems to show an intention of compiling/working on non > > x86 arch... > > > > On the other hand (and if I understand correctly the runtime check), > > it was never expected to work with anything but a AMD PCI root > > complex. > > > > > >> > >> > >> For those eal/x86 APIs, they will be missing in other architectures, > >> > >> @David which one is better, to implement APIs for other architectures > >> but those just return error, or restrict driver build to x86? > > > > We gain compilation coverage, but if the vendor itself refuses runtime > > on anything but its platform... I don't think we should bother with > > this. > > Did I miss something? > > > > It is embedded device, so it will only run on x86. > > Current meson config doesn't restrict it to x86 (existing x86 check is > only for vectorization code), but we can restrict if we want to. > > > One option is to restrict driver to x86 arch, and have the local > '__cpuid()', > > other option is move __cpuid() support to eal x86 specific area, so that > other components also can benefit from it as well as the driver, similar > to the getting CPU flags code, cpuid() is to get some information from > CPU, so it is a generic thing, not specific to driver. > > > I think second option is better, but that requires managing this for > other archs, my question was related to it. Ok, this patch wants to make sure the CPU vendor is AMD and adjust its internal configuration based on this AMD processor family. And as you mentionned, there is a (ugly asm) piece of code too in mlx5 that required identifying a Intel processor family. I am unclear whether defining a cross arch API for identifying cpu model details is doable but I suppose it won't be a quick thing to define. I came up with a rather simple API, posted it and Cc'd other arch maintaine= rs. https://patchwork.dpdk.org/project/dpdk/list/?series=3D29605&state=3D%2A&ar= chive=3Dboth Comments welcome (but not too many, please ;-)). --=20 David Marchand