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 88B5043D70;
	Fri, 29 Mar 2024 15:46:06 +0100 (CET)
Received: from mails.dpdk.org (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id 47AE14014F;
	Fri, 29 Mar 2024 15:46:05 +0100 (CET)
Received: from smtpbgsg2.qq.com (smtpbgsg2.qq.com [54.254.200.128])
 by mails.dpdk.org (Postfix) with ESMTP id 7F07640042
 for <dev@dpdk.org>; Fri, 29 Mar 2024 15:46:01 +0100 (CET)
X-QQ-mid: bizesmtp82t1711723548tnqlib8d
X-QQ-Originating-IP: ln2ujP9s1sRPbsN3IuEiit2ahwZgwdRLkvdBVSyB3vk=
Received: from LAPTOP96V0OHHN ( [183.81.182.182])
 by bizesmtp.qq.com (ESMTP) with 
 id ; Fri, 29 Mar 2024 22:45:46 +0800 (CST)
X-QQ-SSF: 00400000000000D0F000000A0000000
X-QQ-FEAT: wjbXTkPusOt+L63iAzV8KIypbRXBY6R+scDOZDGQsLT6UrEqGzQnv5yhQsF2S
 mJjllPKH9hysT6C+4o6umn0bx9SB6yyNUz4kXYuPCl3rMfQKUpCe2H/O9yvrkZjp7NgfFey
 v7M5rxRxa2HMOw89DRG2NAib9Eg48/uEKAO2xH+8zcrS5gKwagxevUdGprZyps8sy7+2fnn
 rKB4VIP0TUA8Jj77EoqJzkHK1gwwa0p2BSe11MwJXmO0l5YOBrQ7ZU4RcI/yaltHL4HwpP9
 XY4IDfZaN59vzugNFJPzQpJiIQ1orCWwPuM2xHjZcgKSGh5vVt64Ka4bLPBMNjsTduEhYqc
 T1owl7MLSPtCcUxlvW9srQhLtyz2jRT8fPgjKV7uqydAoHHFakhuxjtCgZ/IQ==
X-QQ-GoodBg: 2
X-BIZMAIL-ID: 4218171389466776871
From: "11" <caowenbo@mucse.com>
To: <Ferruh.Yigit@amd.com>,
	"'Thomas Monjalon'" <thomas@monjalon.net>
Cc: <dev@dpdk.org>,
	<andrew.rybchenko@oktetlabs.ru>,
	<yaojun@mucse.com>
References: <20230901023050.40893-1-caowenbo@mucse.com>
 <20230901023050.40893-2-caowenbo@mucse.com>
 <ae04d735-0d7f-4491-b553-5a38a7d9a423@amd.com>
In-Reply-To: <ae04d735-0d7f-4491-b553-5a38a7d9a423@amd.com>
Subject: RE: [PATCH v6 1/8] net/rnp: add skeleton
Date: Fri, 29 Mar 2024 22:45:47 +0800
Message-ID: <E7F2E45E8B195430+005e01da81e7$ca357360$5ea05a20$@mucse.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQI30P9XUj3aWZJ7n+uYhLh06w3v0AG22SC0AXfz/8iweq+fkA==
Content-Language: zh-cn
X-QQ-SENDSIZE: 520
Feedback-ID: bizesmtp:mucse.com:qybglogicsvrgz:qybglogicsvrgz5a-0
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

Hi Ferruh,

Thanks for your  reminder, I'm sorry for that I had been work on =
anothing before.
Recendly, I have been reworked on this work. It will miss on release of =
v24.03.

For another thing, I'm always confused for the secondary process call =
like hw->mac_ops this function pointer.
is this method can work normally on secondary process ?
For example,ixgbe on secondary process call ixgbe_get_module_eeprom I =
fond that it  will cause process core-dump.
because of secondary process use primary process function-point address.
Is dpdk plaform  allowed user call the eth_dev_ops on secondary process?
I don't find any limit and don't know wether or not to protect this =
function call work normally.
My driver eth_dev_ops achieve will used some function-pointer, so I'm =
confued about this.
Wish your kind guidance.
=EF=BB=BF
Regadrs Wenbo


> -----Original Message-----
> From: Ferruh.Yigit@amd.com <Ferruh.Yigit@amd.com>
> Sent: 2024=E5=B9=B43=E6=9C=8829=E6=97=A5 19:28
> To: Wenbo Cao <caowenbo@mucse.com>; Thomas Monjalon
> <thomas@monjalon.net>
> Cc: dev@dpdk.org; andrew.rybchenko@oktetlabs.ru; yaojun@mucse.com
> Subject: Re: [PATCH v6 1/8] net/rnp: add skeleton
>=20
> On 9/1/2023 3:30 AM, Wenbo Cao wrote:
> > Add Basic PMD library and doc build infrastructure Update =
maintainers
> > file to claim responsibility.
> >
> > Signed-off-by: Wenbo Cao <caowenbo@mucse.com>
> >
>=20
> Hi Wenbo,
>=20
> What is the status of the 'rnp' driver, v7 was expected but not =
received, will
> upstreaming continue for v24.03?