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 8629242616; Fri, 22 Sep 2023 11:43:41 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 470804029C; Fri, 22 Sep 2023 11:43:41 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id A227E40150 for ; Fri, 22 Sep 2023 11:43:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1695375819; 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=J/8gREwgLKDRyt7KI4tD3u1lXC3aw51hAdsBYmbSH5bChPcwWL9BOoRICOJD+mRjN2WCFx dVTWHLxDEJ5bLDsBt7Agxui8DL6BU37Fknq6e14tv51MYH0Qx8j8WR510Ova4wtvS7xJ2j 3NQxyKjDlvWvM7/ZeYyMU9YOKesP8QQ= Received: from mail-lj1-f197.google.com (mail-lj1-f197.google.com [209.85.208.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-520-Lq0xZnEANQWvEHqJGqOh3Q-1; Fri, 22 Sep 2023 05:43:37 -0400 X-MC-Unique: Lq0xZnEANQWvEHqJGqOh3Q-1 Received: by mail-lj1-f197.google.com with SMTP id 38308e7fff4ca-2bfe9ed93easo18138401fa.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=XHpkf9SjBMlq+j+l5iZkfH1AVPFeZ1OLR4CN8ruD+DiZiwwl3ZucHvnxUv6ao55ex5 lRPen1yQaRIayKzmxrDUPZXURF5MEZK0NPiJGnn2IZfdU1YLedax0Rh3uzDiGCY2K0hm o+sTM5jtcep3ZD6y5XErsqKXyuQbOALCTdN5+EdHZkbyP1RBqcqXNRAPXwiuOqx+mY6F uQXgZReQZ5F84B52Va20YoD40bb55RO5ykW1+hGUbuP4/zYCpF1k+ixmW8hzRGRSn2vX VlJ+Yxl1J8E6/iBlt683tFNy2dXUv0jql5E+IHr/qIIwyaTiosW/DXUtFgtII7NH5Y2K 6IYg== X-Gm-Message-State: AOJu0YwnPQlNTMUDjhgmH9LCXmxRZtUixwc56FlR3H8Zok/OjsHH1goy YUq8SEHePKzrdgGRtVW368x47RlkRsJjDA3+ZhTpGhLvZZOqVv0oGf1cEYpUQPXpUSWmLlK8AJm 5xhFpe1iJFLXKcmCNyGk= X-Received: by 2002:a05:651c:201a:b0:2c0:a0d:1f0a with SMTP id s26-20020a05651c201a00b002c00a0d1f0amr816403ljo.18.1695375816218; 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: 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 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