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.yi...@amd.com <ferruh.yi...@amd.com>
>> Sent: 2024年3月29日 19:28
>> To: Wenbo Cao <caowe...@mucse.com>; Thomas Monjalon
>> <tho...@monjalon.net>
>> Cc: dev@dpdk.org; andrew.rybche...@oktetlabs.ru; yao...@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 <caowe...@mucse.com>
>>>
>>
>> Hi Wenbo,
>>
>> What is the status of the 'rnp' driver, v7 was expected but not received,
>> will
>> upstreaming continue for v24.03?
>
>
