From: Ferruh Yigit <ferruh.yigit@amd.com>
To: 11 <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
Date: Tue, 2 Apr 2024 11:15:34 +0100 [thread overview]
Message-ID: <2e47e325-d552-4b91-a98e-d4c0cddcaf36@amd.com> (raw)
In-Reply-To: <E7F2E45E8B195430+005e01da81e7$ca357360$5ea05a20$@mucse.com>
On 3/29/2024 2:45 PM, 11 wrote:
> 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.
>
Hi Wenbo,
"struct rte_eth_dev" is per process, not shared, so both primary and and
secondary has a copy of it.
And during driver initialization, 'eth_dev->dev_ops' is set, so both
primary and secondary processes has correct function pointers.
("struct rte_eth_dev_data" is shared, so any pointer withing that struct
should be in a shared memory between primary and secondaries.)
And there is no restriction for secondary process call 'eth_dev_ops' but
this call needs to be synchronized by application, since there is no
locking around those functions.
Common usecase is primary process runs the control path, uses
'eth_dev_ops' calls, and secondaries only does the datapath on specific
set of queues.
If you are referring to 'mac_ops', that is another layer of abstraction
some drivers use, but those should be tied to ethdev control path
functions eventually, so same rule for using ethdev control path applies
to them.
>
>
>> -----Original Message-----
>> From: Ferruh.Yigit@amd.com <Ferruh.Yigit@amd.com>
>> Sent: 2024年3月29日 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
>>
>> 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>
>>>
>>
>> Hi Wenbo,
>>
>> What is the status of the 'rnp' driver, v7 was expected but not received, will
>> upstreaming continue for v24.03?
>
>
next prev parent reply other threads:[~2024-04-02 10:15 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-01 2:30 [PATCH v6 0/8] [v6]drivers/net Add Support mucse N10 Pmd Driver Wenbo Cao
2023-09-01 2:30 ` [PATCH v6 1/8] net/rnp: add skeleton Wenbo Cao
2023-09-05 15:35 ` Ferruh Yigit
2023-09-06 8:15 ` 11
2024-03-29 11:28 ` Ferruh Yigit
2024-03-29 14:45 ` 11
2024-04-02 10:15 ` Ferruh Yigit [this message]
2023-09-01 2:30 ` [PATCH v6 2/8] net/rnp: add ethdev probe and remove Wenbo Cao
2023-09-05 15:36 ` Ferruh Yigit
2023-09-06 10:42 ` 11
2023-09-01 2:30 ` [PATCH v6 3/8] net/rnp: add device init and uninit Wenbo Cao
2023-09-05 15:44 ` Ferruh Yigit
2023-09-06 11:03 ` 11
2023-09-01 2:30 ` [PATCH v6 4/8] net/rnp: add mbx basic api feature Wenbo Cao
2023-09-05 15:45 ` Ferruh Yigit
2023-09-06 10:32 ` 11
2023-09-01 2:30 ` [PATCH v6 5/8] net/rnp add reset code for Chip Init process Wenbo Cao
2023-09-05 15:46 ` Ferruh Yigit
2023-09-06 9:23 ` 11
2023-09-01 2:30 ` [PATCH v6 6/8] net/rnp add port info resource init Wenbo Cao
2023-09-05 16:56 ` Ferruh Yigit
2023-09-06 9:07 ` 11
2023-09-01 2:30 ` [PATCH v6 7/8] net/rnp add devargs runtime parsing functions Wenbo Cao
2023-09-05 15:46 ` Ferruh Yigit
2023-09-06 9:13 ` 11
2023-09-01 2:30 ` [PATCH v6 8/8] net/rnp handle device interrupts Wenbo Cao
2023-09-05 15:34 ` [PATCH v6 0/8] [v6]drivers/net Add Support mucse N10 Pmd Driver Ferruh Yigit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2e47e325-d552-4b91-a98e-d4c0cddcaf36@amd.com \
--to=ferruh.yigit@amd.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=caowenbo@mucse.com \
--cc=dev@dpdk.org \
--cc=thomas@monjalon.net \
--cc=yaojun@mucse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).