From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <stable-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id A7F9BA00C4
for <public@inbox.dpdk.org>; Thu, 14 Jul 2022 15:46:27 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id 9412842BA3;
Thu, 14 Jul 2022 15:46:27 +0200 (CEST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com
[66.111.4.28]) by mails.dpdk.org (Postfix) with ESMTP id 3B35442B6D;
Thu, 14 Jul 2022 15:46:25 +0200 (CEST)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.46])
by mailout.nyi.internal (Postfix) with ESMTP id D7E3C5C00B7;
Thu, 14 Jul 2022 09:46:24 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
by compute2.internal (MEProxy); Thu, 14 Jul 2022 09:46:24 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h=
cc:cc:content-transfer-encoding:content-type:date:date:from:from
:in-reply-to:in-reply-to:message-id:mime-version:references
:reply-to:sender:subject:subject:to:to; s=fm3; t=1657806384; x=
1657892784; bh=Bjbl1xceAFu6US9YJ4Hy26+OzO6zArOLgAVAY0AgjPM=; b=W
U3IKMXjrRZ6YjI4rCDxmt/ZIg5jVctv6P0BTuVVNkoXjPxlOlZQgu4wd+a9TtzLx
h8V5FaAualrUS3vy3kWvlaOVu3xdmKg/Z6IQRyJ8eXvy3E+XefDSJaDP352MgPE/
UmS+spdcWiuk9JXDst0Q/W7vu6uDu6Y0bS1UqNNHQ76aQu0i24+qsAdEi0C1aqwY
oE2cpilUZXV6rAMjl3YIalKr1I4tfPQJbPzH1ai+5feAGQPhU7xVW0+8X0eeYt5O
cjbazQBE6RK8rU0nmwErjYesko1ohNJw7mlP46qFHSBEghY1elbIeZ2nMJOsPOON
I77wg/uMrzXieP8DwzBPw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc:cc:content-transfer-encoding
:content-type:date:date:feedback-id:feedback-id:from:from
:in-reply-to:in-reply-to:message-id:mime-version:references
:reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy
:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1657806384; x=
1657892784; bh=Bjbl1xceAFu6US9YJ4Hy26+OzO6zArOLgAVAY0AgjPM=; b=0
W2tI+l0qwbys8INj6f0VyUHBcS8/bdBVobSZB4Zbjxu1tahFg2z7apduCs+2uV99
L2XY3g/lvVqGwQ1nnHV22dKOOusdDw78gwtLKOydMY7Xly/34zdKvwg3ZlKE0Ixw
PSj95v4LAWEvIrdeLR+u/1i+rtPKirRW89Kv9iMdUSIZGhu9tyTNTlkoNSUD67Si
NezD1KLRE2KATZrgIphcJMeUbqrfbmKbCwrQ24B8Tq4wY46mbJmfEqQwdTBxJhl6
wg6yLDzv6QvotcK1B1sHI/MIK3E7I6LS+mLBBz1xtB67iiIS1agiK+D/aq4o5YQ3
9ud+XsgL/T8/53HYFlPwg==
X-ME-Sender: <xms:MB7QYsI992ZScJ9JSQjy-HZ8aysalI5jmUMJdqeNfkN-lk23HI1-tg>
<xme:MB7QYsKzj2s2VyETbnWPt0xLM0Mr39UQ4tgN8Ucn6bvCBnqw8HejSUvcwj6VOhPhF
bnIOq4uFu1dS7SIGA>
X-ME-Received: <xmr:MB7QYsst6NG5-JUduURQW3TXEM_JCXCPo2_kgg8zGENtggkgzCWeND5dDzonNm6dpFNN7MSAFGhckC41vzCVSpPM5A>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudejledgieelucetufdoteggodetrfdotf
fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm
rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc
ggtffrrghtthgvrhhnpedtjeeiieefhedtfffgvdelteeufeefheeujefgueetfedttdei
kefgkeduhedtgfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh
hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght
X-ME-Proxy: <xmx:MB7QYpZNB3-k6d4Qllb2cK8tixjMsAbFk_mzEIDg6qyOHiLnJuYiOQ>
<xmx:MB7QYjaRXHxmD7X77-sQxivMRJzmCH45YBoPho-nocCWkzCKxUvJ7g>
<xmx:MB7QYlD0jlAmy0NIeGRLmMEyZRr7zwWLAgjD7EbxSOL0PmF6M22ikA>
<xmx:MB7QYuwq1wE6QTxx2NBoHoWudhxEY-fPRlemcOR68JeHLnLCkSHWvw>
Feedback-ID: i47234305:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
14 Jul 2022 09:46:23 -0400 (EDT)
From: Thomas Monjalon <thomas@monjalon.net>
To: Olivier Matz <olivier.matz@6wind.com>,
Houssem Bouhlel <houssem.bouhlel@6wind.com>,
David Marchand <david.marchand@redhat.com>
Cc: stable@dpdk.org, dev <dev@dpdk.org>, "Burakov,
Anatoly" <anatoly.burakov@intel.com>,
Bruce Richardson <bruce.richardson@intel.com>
Subject: Re: [dpdk-stable] [PATCH] bus/pci: fix selection of default device
NUMA node
Date: Thu, 14 Jul 2022 15:46:22 +0200
Message-ID: <3095495.e9paKfgaYA@thomas>
In-Reply-To: <CAJFAV8y16+XMUx4ZMasH6tdqRcAKM+OPB0dPNxWkq0UGuUNBOg@mail.gmail.com>
References: <20211026090610.10823-1-houssem.bouhlel@6wind.com>
<YXu0hT8VmzYrOvv4@platinum>
<CAJFAV8y16+XMUx4ZMasH6tdqRcAKM+OPB0dPNxWkq0UGuUNBOg@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-BeenThere: stable@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: patches for DPDK stable branches <stable.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/stable>,
<mailto:stable-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/stable/>
List-Post: <mailto:stable@dpdk.org>
List-Help: <mailto:stable-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/stable>,
<mailto:stable-request@dpdk.org?subject=subscribe>
Errors-To: stable-bounces@dpdk.org
03/11/2021 21:36, David Marchand:
> On Fri, Oct 29, 2021 at 10:45 AM Olivier Matz <olivier.matz@6wind.com> wrote:
> >
> > +CC David
> >
> > On Tue, Oct 26, 2021 at 11:17:08AM +0200, Olivier Matz wrote:
> > > On Tue, Oct 26, 2021 at 11:06:10AM +0200, Houssem Bouhlel wrote:
> > > > There can be dev binding issue when no hugepages
> > > > are allocated for socket 0.
> > > > To avoid this, set device numa node value based on
> > > > the first lcore instead of 0.
> > > >
> > > > Fixes: 831dba47bd36 ("bus/vmbus: add Hyper-V virtual bus support")
> > >
> > > Sorry, the Fixes line is wrong. This is the correct one:
> > > Fixes: 8a04cb612589 ("pci: set default numa node for broken systems")
> > >
> > > > Cc: stable@dpdk.org
> > > >
> > > > Signed-off-by: Houssem Bouhlel <houssem.bouhlel@6wind.com>
> > > > Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
> > > > ---
> > > > drivers/bus/pci/pci_common.c | 4 +++-
> > > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/bus/pci/pci_common.c b/drivers/bus/pci/pci_common.c
> > > > index f8fff2c98ebf..c70ab2373c79 100644
> > > > --- a/drivers/bus/pci/pci_common.c
> > > > +++ b/drivers/bus/pci/pci_common.c
> > > > @@ -166,6 +166,7 @@ rte_pci_probe_one_driver(struct rte_pci_driver *dr,
> > > > struct rte_pci_device *dev)
> > > > {
> > > > int ret;
> > > > + unsigned int socket_id;
> > > > bool already_probed;
> > > > struct rte_pci_addr *loc;
> > > >
> > > > @@ -194,7 +195,8 @@ rte_pci_probe_one_driver(struct rte_pci_driver *dr,
> > > > if (rte_socket_count() > 1)
> > > > RTE_LOG(INFO, EAL, "Device %s is not NUMA-aware, defaulting socket to 0\n",
> > > > dev->name);
> > >
> > > One more comment (sorry, I should have done it before you send the mail):
> > > We should move this log below, and use the socket_id instead of 0.
> > >
> > > > - dev->device.numa_node = 0;
> > > > + socket_id = rte_lcore_to_socket_id(rte_get_next_lcore(-1, 0, 0));
> > > > + dev->device.numa_node = socket_id;
> >
> > After some offline discussions with David, some additional comments:
> >
> > - a similar change may be needed in other bus drivers
Yes we need to be consistent.
You need to check what is done in all OSes as well.
Example of a place to look at:
3c6e58102510 ("bus/pci: fix unknown NUMA node value on Windows")
> > - instead of setting the numa node to an existing socket, it can make
> > more sense to keep its value to unknown (-1). This would however be a
> > behavior change for pci bus, which returns 0 since 2015 for unknown
> > cases. See:
> > 81f8d2317df2 ("eal/linux: fix socket value for undetermined numa node")
> > 8a04cb612589 ("pci: set default numa node for broken systems")
> >
> > I'll tend to be in favor of using -1. Any other opinion?
> > Should we announce a behavior change in this case?
>
> Good summary.
> I copied some more people.
>
> I am for -1 too (as a way to indicate "I don't know what this PCI
> device affinity is").
-1 is SOCKET_ID_ANY
I suppose it is OK to use SOCKET_ID_ANY when we have no other info.