[v6,1/8] net/rnp: add skeleton

  Add Basic PMD library and doc build infrastructure
Update maintainers file to claim responsibility.

Signed-off-by: Wenbo Cao <caowenbo@mucse.com>
---
 MAINTAINERS                      |  6 +++++
 doc/guides/nics/features/rnp.ini |  8 +++++++
 doc/guides/nics/index.rst        |  1 +
 doc/guides/nics/rnp.rst          | 38 ++++++++++++++++++++++++++++++++
 drivers/net/meson.build          |  1 +
 drivers/net/rnp/meson.build      | 11 +++++++++
 drivers/net/rnp/rnp_ethdev.c     |  3 +++
 7 files changed, 68 insertions(+)
 create mode 100644 doc/guides/nics/features/rnp.ini
 create mode 100644 doc/guides/nics/rnp.rst
 create mode 100644 drivers/net/rnp/meson.build
 create mode 100644 drivers/net/rnp/rnp_ethdev.c
  

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>

<...>

> diff --git a/doc/guides/nics/rnp.rst b/doc/guides/nics/rnp.rst
> new file mode 100644
> index 0000000000..0eb8f2d415
> --- /dev/null
> +++ b/doc/guides/nics/rnp.rst
> @@ -0,0 +1,38 @@
> +..  SPADIX-License-Identifier: BSD-3-Clause

s/SPADIX/SPDX/

> +    Copyright(c) 2023 Mucse IC Design Ltd.
> +
> +RNP Poll Mode driver
> +====================
> +
> +The RNP ETHDEV PMD (**librte_net_rnp**) provides poll mode ethdev
> +driver support for the inbuilt network device found in the **Mucse RNP**
> +
> +Prerequisites
> +-------------
> +More information can be found at `Mucse, Official Website
> +<https://mucse.com/productDetail>`_.
> +
> +Supported Chipsets and NICs
> +---------------------------
> +
> +- MUCSE Ethernet Controller N10 Series for 10GbE or 40GbE (Dual-port)
> +

Can you provide a link for the product, and if there is an English
version it can reach to more people?

> +Limitations or Known issues
> +---------------------------
> +
> +Build with ICC is not supported yet.
>

I know this is documented in other PMDs too, but at this stage ICC is
supported with best effort, and I am not sure if anybody testing with
it, so I think it is OK to drop this as limitation.


> +BSD are not supported yet.
>

FreeBSD is not supported.
Also Windows seems not supported, you may document that too.

> +
> +CRC stripping
> +~~~~~~~~~~~~~
> +
> +The RNP Soc family Nic strip the CRC for every packets coming into the

s/Soc/SoC/
s/Nic/NIC/

> +host interface irrespective of the offload configuration.
> +When you want to disable CRC_OFFLOAD the operate will influence the rxCksum offload.
>

I didn't understand the second sentences, from first one I understand
'RTE_ETH_RX_OFFLOAD_KEEP_CRC' is not supported by the PMD, but can you
please clarify more?


> +
> +VLAN Strip/Filter
> +~~~~~~~~~~~~~~~~~
> +
> +For VLAN strip/filter, RNP just support vlan is CVLAN(0x8100).If the outvlan type is SVLAN(0X88a8)

s/vlan/VLAN/
Please put space, " ", after '.' in documentation. Same comment for all
document.

> +VLAN filter or strip will not effort for this packet.It will bypass filter to the host default queue,
> +whatever the other filter rule is.
>

VLAN strip/filter doesn't work for double-tag (QinQ), it only works for
single VLAN tag, is this correct? If so can you please update above
sentences to clarify this?
  

Hi Ferruh,

Thanks for your kindly review, please see the below comment.

Regards Wenbo	

> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@amd.com>
> Sent: 2023年9月5日 23:35
> 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>
> 
> <...>
> 
> > diff --git a/doc/guides/nics/rnp.rst b/doc/guides/nics/rnp.rst new
> > file mode 100644 index 0000000000..0eb8f2d415
> > --- /dev/null
> > +++ b/doc/guides/nics/rnp.rst
> > @@ -0,0 +1,38 @@
> > +..  SPADIX-License-Identifier: BSD-3-Clause
> 
> s/SPADIX/SPDX/
I get it.
> 
> > +    Copyright(c) 2023 Mucse IC Design Ltd.
> > +
> > +RNP Poll Mode driver
> > +====================
> > +
> > +The RNP ETHDEV PMD (**librte_net_rnp**) provides poll mode ethdev
> > +driver support for the inbuilt network device found in the **Mucse
> > +RNP**
> > +
> > +Prerequisites
> > +-------------
> > +More information can be found at `Mucse, Official Website
> > +<https://mucse.com/productDetail>`_.
> > +
> > +Supported Chipsets and NICs
> > +---------------------------
> > +
> > +- MUCSE Ethernet Controller N10 Series for 10GbE or 40GbE (Dual-port)
> > +
> 
> Can you provide a link for the product, and if there is an English version it can
> reach to more people?
> 
For English version, it will be coming  soon in a month about.
we will provide a html link of pdf for the time.
> > +Limitations or Known issues
> > +---------------------------
> > +
> > +Build with ICC is not supported yet.
> >
> 
> I know this is documented in other PMDs too, but at this stage ICC is supported
> with best effort, and I am not sure if anybody testing with it, so I think it is OK to
> drop this as limitation.
> 
> 
We have never test the code use icc-compile-tool, just use gcc-compile-tool,
I'm going to try to test it with icc :)
> > +BSD are not supported yet.
> >
> 
> FreeBSD is not supported.
> Also Windows seems not supported, you may document that too.
> 
> > +
> > +CRC stripping
> > +~~~~~~~~~~~~~
> > +
> > +The RNP Soc family Nic strip the CRC for every packets coming into
> > +the
> 
> s/Soc/SoC/
> s/Nic/NIC/
> 
For this spell issue, is there exist tool I can use to check it ?
Thanks a lot.
> > +host interface irrespective of the offload configuration.
> > +When you want to disable CRC_OFFLOAD the operate will influence the
> rxCksum offload.
> >
> 
> I didn't understand the second sentences, from first one I understand
> 'RTE_ETH_RX_OFFLOAD_KEEP_CRC' is not supported by the PMD, but can you
> please clarify more?
> 
> 
disable CRC_OFFLOAD will trigger SOC bug,
which causing bad-cksum bit in rx description always be 1 ,even package has no cksum  error.
> > +
> > +VLAN Strip/Filter
> > +~~~~~~~~~~~~~~~~~
> > +
> > +For VLAN strip/filter, RNP just support vlan is CVLAN(0x8100).If the
> > +outvlan type is SVLAN(0X88a8)
> 
> s/vlan/VLAN/
> Please put space, " ", after '.' in documentation. Same comment for all document.
> 
I forgot the format before.
> > +VLAN filter or strip will not effort for this packet.It will bypass
> > +filter to the host default queue, whatever the other filter rule is.
> >
> 
> VLAN strip/filter doesn't work for double-tag (QinQ), it only works for single VLAN
> tag, is this correct? If so can you please update above sentences to clarify this?
> 
For VLAN strip/filter, if the VLAN type have (0x88a8), the feature of hardware isn't effect.
  

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?
  

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.

Regadrs Wenbo


> -----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?
  

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?
> 
>