From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id BB7644609E;
Thu, 16 Jan 2025 10:15:44 +0100 (CET)
Received: from mails.dpdk.org (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id 55BED4025F;
Thu, 16 Jan 2025 10:15:44 +0100 (CET)
Received: from fout-b4-smtp.messagingengine.com
(fout-b4-smtp.messagingengine.com [202.12.124.147])
by mails.dpdk.org (Postfix) with ESMTP id 20FD540156
for <dev@dpdk.org>; Thu, 16 Jan 2025 10:15:43 +0100 (CET)
Received: from phl-compute-01.internal (phl-compute-01.phl.internal
[10.202.2.41])
by mailfout.stl.internal (Postfix) with ESMTP id 5DDBD11401A8;
Thu, 16 Jan 2025 04:15:42 -0500 (EST)
Received: from phl-mailfrontend-02 ([10.202.2.163])
by phl-compute-01.internal (MEProxy); Thu, 16 Jan 2025 04:15:42 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h=
cc:cc:content-transfer-encoding:content-type:content-type:date
:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
:references:reply-to:subject:subject:to:to; s=fm2; t=1737018942;
x=1737105342; bh=1Yww1BLRdyQ2pOHPDxGPpiQY6mLETAHGpmxw5tFk7EU=; b=
eWpNMmUmjg9vWUp0RPaFGeLtTHQxsWrCACerRl3MDhadmGSmLsapKBTWGx4wZ+81
iJkJOQSjz0pz2HhVM428v3xojag0hkuB+RzzkRMjWikz0FyRTgy/GoVaSxUTb8Ng
v3GUuUWPmQktPPPVaaqPXB87KZ/l1Jy/SdLIDKqp/9CSPpTm8BHE2GTJTLEU1hcP
3TWuPSTjG5hinGuOLj35vybXq16fyG4ItAk3ERQF/SHOHD6rRGhGdWWPjmiJxEK9
Kl+lNDh4IqLt4mTWKbqH5hhDnXP0UPpJgrKQePKHqLrTbMd3WdA9XvJk5/ziOo9S
jSZNKpmMa4qjlmsnxsYZAg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc:cc:content-transfer-encoding
:content-type:content-type:date:date:feedback-id:feedback-id
:from:from:in-reply-to:in-reply-to:message-id:mime-version
:references:reply-to:subject:subject:to:to:x-me-proxy
:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1737018942; x=
1737105342; bh=1Yww1BLRdyQ2pOHPDxGPpiQY6mLETAHGpmxw5tFk7EU=; b=f
bJcY7haJlPnRXwtX8WTDkYbEHjegMp9z+6OjYH7KsVOwYKzvOqsc2B8T8Wv2wCwe
TOJ+6m6mC73WjKzuNQNdaj5wrhS0qbraHCIw9CNkmBNprsVwJ0Qt586C/98nU4uL
ODYfTzVB4d9urQ1hvoJjtuK8F7WNbq7UFshhtumSp1GtaW/Suef5aBPmQ/CnKT8X
ZHfikwdis9LYLdgCLKgBaqI3Khs3Qiqxem+dJVb0r3AqemLRQIQR1+4ACoj/uPUy
WoGFuo/Wn8ivEYmQ1h9fz4r4U+5iNxUmwL3zwjs384LbU3muP99OEYKrPtYdPwiW
DmbHogUBJrnUgkY60nTUg==
X-ME-Sender: <xms:Pc6IZ4dTk8OmdfpDHVsyVdwrUpSkxGzkZXQmDIPMxvnZs-WlEad3bg>
<xme:Pc6IZ6P2L_2oTPYg-_5OnZBbahzwwQy6-YKizmbxPS1eefnn1yJnrD0-lADc04et0
SUuHmyoMi2zyFQ7xA>
X-ME-Received: <xmr:Pc6IZ5jNppSydW2lqYiaAMG0TtduRd-HNEA-BT8KrKa75KDHU9hBcletzDyef05jqt0ZDZXySlX9qzY08vzeBnCe7Q>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrudeiuddgtdduucetufdoteggodetrfdotf
fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
htshculddquddttddmnecujfgurhephffvvefufffkjghfggfgtgesthhqredttddtjeen
ucfhrhhomhepvfhhohhmrghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrg
hlohhnrdhnvghtqeenucggtffrrghtthgvrhhnpeegtddtleejjeegffekkeektdejvedt
heevtdekiedvueeuvdeiuddvleevjeeujeenucevlhhushhtvghrufhiiigvpedtnecurf
grrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtpdhn
sggprhgtphhtthhopeegpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehlihhhuh
hishhonhhgsehhuhgrfigvihdrtghomhdprhgtphhtthhopeguvghvseguphgukhdrohhr
ghdprhgtphhtthhopehsthgvphhhvghnsehnvghtfihorhhkphhluhhmsggvrhdrohhrgh
dprhgtphhtthhopehlihhuhihonhhglhhonhhgsehhuhgrfigvihdrtghomh
X-ME-Proxy: <xmx:Pc6IZ9-Fv8QZelX9qUPjf-TlZXoTi2hiy-C-DfQ0jMmUiMRat8jZaQ>
<xmx:Pc6IZ0seqt_ftheXXhGyljPdF5Hu8bWmDeJtZ0FjLCu88V9Rqr6k_Q>
<xmx:Pc6IZ0HksIpLcdl6MGGO2HCapP5lGC2QZlb3u_Oh8RyTSn_9KmKXdA>
<xmx:Pc6IZzMn7TbnN8nJTnRm7TlARHVt3XdA6d5wb9n4C0ZobzXTstNyKw>
<xmx:Ps6IZ2JJOwzfYcQZpi5cjDmaZa5BuKLjgrqe03QdF0Z1X3vblFN5cydi>
Feedback-ID: i47234305:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
16 Jan 2025 04:15:41 -0500 (EST)
From: Thomas Monjalon <thomas@monjalon.net>
To: "lihuisong (C)" <lihuisong@huawei.com>
Cc: dev@dpdk.org, stephen@networkplumber.org, liuyonglong@huawei.com
Subject: Re: [PATCH v1 1/2] ethdev: clarify do not something in the new event
Date: Thu, 16 Jan 2025 10:15:38 +0100
Message-ID: <3006817.VdNmn5OnKV@thomas>
In-Reply-To: <363b8b06-652b-26e2-fc7e-30e22c916181@huawei.com>
References: <20250115034110.15245-1-lihuisong@huawei.com>
<2135427.KlZ2vcFHjT@thomas>
<363b8b06-652b-26e2-fc7e-30e22c916181@huawei.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
16/01/2025 07:16, lihuisong (C):
>=20
> =E5=9C=A8 2025/1/15 19:31, Thomas Monjalon =E5=86=99=E9=81=93:
> > 15/01/2025 04:41, Huisong Li:
> >> If application verify the validity of the port id or configure this po=
rt in
> >> the new event callback, application may happen to the port id is inval=
id.
> >>
> >> Actually, when application receive a new event from one port, the port=
is
> >> not fully probed and is just in allocated state. Application doesn't n=
eed
> >> to verify the validity of the port id because it is definitely valid.
> >> What's more, application shouldn't do something like configuring this =
port
> >> or querying some information of this port by ethdev ops.
> >>
> >> Signed-off-by: Huisong Li <lihuisong@huawei.com>
> >> ---
> >> lib/ethdev/rte_ethdev.h | 9 ++++++++-
> >> 1 file changed, 8 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
> >> index 1f71cad244..e2021f0f12 100644
> >> --- a/lib/ethdev/rte_ethdev.h
> >> +++ b/lib/ethdev/rte_ethdev.h
> >> @@ -4128,7 +4128,14 @@ enum rte_eth_event_type {
> >> RTE_ETH_EVENT_VF_MBOX, /**< message from the VF received by PF */
> >> RTE_ETH_EVENT_MACSEC, /**< MACsec offload related event */
> >> RTE_ETH_EVENT_INTR_RMV, /**< device removal event */
> >> - RTE_ETH_EVENT_NEW, /**< port is probed */
> >> + /** Port is probed and application's event callback will be called.
> > We are not going to say that the callback is called for each event :)
> >
> >> + * In this moment, the port is not fully probed and is just in alloc=
ated
> >> + * state. When application receive this event, application doesn't n=
eed
> > It is not a real state.
> >
> >> + * to verify the validity of the port id because it is definitely va=
lid.
> >> + * What's more, application shouldn't do something like configuring =
this
> >> + * port or querying some information of this port by ethdev ops.
> >> + */
> > Let me try shorter:
> > "
> > The port is being probed, i.e. allocated and not yet available.
> > It is too early to check validity, infos, or configuring the port.
> > "
> "
> The port is being probed, i.e. allocated and not yet available.
> It is too early to check validity, query infos, or configure the port.
> But the socket id and owner id related to this port can be considered as=
=20
> valid.
> "
> How about use above comments?
The last sentence should be in patch 2.
And I am not sure about saying they are valid.
It is more accurate to say that the functions for socket id and owner id ar=
e available.