RE: [PATCH v6 1/8] net/rnp: add skeleton

[11]

Hi Ferruh,

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

Regards Wenbo   

> -Original Message-
> From: Ferruh Yigit 
> Sent: 2023年9月5日 23:35
> To: Wenbo Cao ; Thomas Monjalon
> 
> 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 
> 
> <...>
> 
> > diff --git a/doc/guides/nics/rnp.rst b/doc/guides/nics/rnp.rst new
> > file mode 100644 index 00..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
> > +`_.
> > +
> > +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.

RE: [PATCH v6 6/8] net/rnp add port info resource init

[11]

Hi Ferruh,

> -Original Message-
> From: Ferruh Yigit 
> Sent: 2023年9月6日 0:56
> To: Wenbo Cao 
> Cc: dev@dpdk.org; tho...@monjalon.net; andrew.rybche...@oktetlabs.ru;
> yao...@mucse.com
> Subject: Re: [PATCH v6 6/8] net/rnp add port info resource init
> 
> On 9/1/2023 3:30 AM, Wenbo Cao wrote:
> > Add Api For FW Mac Info, Port Resoucre info init Code For Different
> > Shape Of Nic
> >
> > Signed-off-by: Wenbo Cao 
> 
> <...>
> 
> > @@ -47,11 +104,53 @@ rnp_init_port_resource(struct rnp_eth_adapter
> *adapter,
> >uint8_t p_id)
> >  {
> > struct rnp_eth_port *port = RNP_DEV_TO_PORT(dev);
> > +   struct rte_pci_device *pci_dev = adapter->pdev;
> > +   struct rnp_hw *hw = &adapter->hw;
> >
> > +   port->adapt = adapter;
> > +   port->s_mode = adapter->s_mode;
> > +   port->port_stopped = 1;
> > +   port->hw = hw;
> > port->eth_dev = dev;
> > -   adapter->ports[p_id] = port;
> > +
> > +   dev->device = &pci_dev->device;
> > +   rte_eth_copy_pci_info(dev, pci_dev);
> > dev->dev_ops = &rnp_eth_dev_ops;
> > -   RTE_SET_USED(name);
> > +   dev->rx_queue_count   = rnp_dev_rx_queue_count;
> > +   dev->rx_descriptor_status = rnp_dev_rx_descriptor_status;
> > +   dev->tx_descriptor_status = rnp_dev_tx_descriptor_status;
> > +   dev->rx_pkt_burst = rnp_recv_pkts;
> > +   dev->tx_pkt_burst = rnp_xmit_pkts;
> > +   dev->tx_pkt_prepare = rnp_prep_pkts;
> > +
> > +   rnp_setup_port_attr(port, dev, adapter->num_ports, p_id);
> > +   rnp_init_filter_setup(port, adapter->num_ports);
> > +   rnp_get_mac_addr(dev, port->mac_addr);
> > +   dev->data->mac_addrs = rte_zmalloc(name, sizeof(struct
> rte_ether_addr) *
> > +   port->attr.max_mac_addrs, 0);
> > +   if (!dev->data->mac_addrs) {
> > +   RNP_PMD_DRV_LOG(ERR, "Memory allocation "
> > +   "for MAC failed! Exiting.\n");
> > +   return -ENOMEM;
> > +   }
> > +   /* Allocate memory for storing hash filter MAC addresses */
> > +   dev->data->hash_mac_addrs = rte_zmalloc(name,
> > +   RTE_ETHER_ADDR_LEN * port-
> >attr.max_uc_mac_hash, 0);
> > +   if (dev->data->hash_mac_addrs == NULL) {
> > +   RNP_PMD_INIT_LOG(ERR, "Failed to allocate %d bytes "
> > +   "needed to store MAC addresses",
> > +   RTE_ETHER_ADDR_LEN * port-
> >attr.max_uc_mac_hash);
> > +   return -ENOMEM;
> 
> Should free 'dev->data->mac_addrs' here, or even better can be to implement
> 'rnp_dev_close()' to free device resources.
> 
> 
> > +   dev->data->mac_addrs = rte_zmalloc(name, sizeof(struct
Yes, for the failed branch, need to free the last alloc success argument 
mac_addrs
> > +   }
> > +
> > +   rnp_set_default_mac(dev, port->mac_addr);
> 
> I guess the 'port->mac_addr' got from device via 'rnp_get_mac_addr()'
> above, but if 'rnp_get_mac_addr()' fails what will be the value. Should there 
> be
> check and set a random mac if required?
> 
Yes, you are right :) ,  it the rnp_get_mac_addr failed, this may have fireware 
issue thing about 
Communicate.This need to be check and warning.
> > +   rte_ether_addr_copy((const struct rte_ether_addr *)port->mac_addr,
> > +   dev->data->mac_addrs);
> > +   /* MTU */
> > +   dev->data->mtu = RTE_ETHER_MAX_LEN -
> > +   RTE_ETHER_HDR_LEN - RTE_ETHER_CRC_LEN;
> > +   adapter->ports[p_id] = port;
> > +   rte_eth_dev_probing_finish(dev);
> >
> 
> rte_eth_dev_probing_finish() is not required, as
> 'rte_eth_dev_pci_generic_probe()' calls it if dev_init() returns success.
> 
> <...>
> 
For N10  chip is just have two pcie-bdf, the one pcie-bdf may have multiple 
port(max 4)
'rte_eth_dev_pci_generic_probe' probe the pcie-pdf port(master port port 0)
the other port alloc by 'rnp_alloc_eth_port', not set 
'rte_eth_dev_probing_finish()'
so the 1,2,3 port will set 'rte_eth_dev_probing_finish()'.
> > +static int32_t rnp_get_mac_addr_pf(struct rnp_eth_port *port,
> > +  uint8_t lane,
> > +  uint8_t *macaddr)
> > +{
> > +   struct rnp_hw *hw = RNP_DEV_TO_HW(port->eth_dev);
> > +
> > +   return rnp_fw_get_macaddr(port->eth_dev, hw->pf_vf_num, macaddr,
> > +lane); }
> > +
> 
> These are mac_ops functions, normally the reason to have mac_ops is to support
> different HW that behaves slightly different and this difference managed by
> different function pointers per device. Is this your usecase?
> 
This is because for one pcie-bdf one port and one pcie-bdf multiple port usecase
For hareware design limit, we max can support eight port but just have two 
pcie-bdf.
We must use two set of api to resolve one pcie-bdf one port and
one pcie-bdf multiple port for the port Control independence feature. 
Such as vlan-filter, mac unicast/Multicast filter, promise, Multicast promise, 
Broadcast promise.
So that some API is common used for one-port-pcie-bdf and  
multiple-port-one-pcie-bdf :(.
And some mac-api must change when known the nic is mu

RE: [PATCH v6 7/8] net/rnp add devargs runtime parsing functions

[11]

> -Original Message-
> From: Ferruh Yigit 
> Sent: 2023年9月5日 23:47
> To: Wenbo Cao 
> Cc: dev@dpdk.org; tho...@monjalon.net; andrew.rybche...@oktetlabs.ru;
> yao...@mucse.com
> Subject: Re: [PATCH v6 7/8] net/rnp add devargs runtime parsing functions
> 
> On 9/1/2023 3:30 AM, Wenbo Cao wrote:
> > add various runtime devargs command line options supported by this
> > driver.
> >
> > Signed-off-by: Wenbo Cao 
> 
> <...>
> 
> >
> > +#define RNP_HW_MAC_LOOPBACK_ARG  "hw_loopback"
> > +#define RNP_FW_UPDATE"fw_update"
> > +#define RNP_RX_FUNC_SELECT   "rx_func_sec"
> > +#define RNP_TX_FUNC_SELECT   "tx_func_sec"
> > +#define RNP_FW_4X10G_10G_1G_DET  "fw_4x10g_10g_1g_auto_det"
> > +#define RNP_FW_FORCE_SPEED_1G"fw_force_1g_speed"
> > +
> 
> Please document these runtime arguments in the device document.
> 
> Also please add 'RTE_PMD_REGISTER_PARAM_STRING()' macros to document
> argument for pmdinfogen, please see samples in existing code.
> 
> <...>
> 
OK, I will check the samples.
> > +
> > +static int
> > +rnp_parse_io_select_func(const char *key, const char *value, void
> > +*extra_args) {
> > +   uint8_t select = RNP_IO_FUNC_USE_NONE;
> > +
> > +   RTE_SET_USED(key);
> > +
> > +   if (strcmp(value, "vec") == 0)
> > +   select = RNP_IO_FUNC_USE_VEC;
> > +   else if (strcmp(value, "simple") == 0)
> > +   select = RNP_IO_FUNC_USE_SIMPLE;
> > +   else if (strcmp(value, "common") == 0)
> > +   select = RNP_IO_FUNC_USE_COMMON;
> > +
> 
> There is already an generic eal argument that lets you select between vector 
> and
> scalar datapath implementation:
> --force-max-simd-bitwidth=
> 
> <...>
> 
> --force-max-simd-bitwidth=
This option I have noticed before. Thanks a lot.
I will check the generic eal argume code, and reedit the interrelated code
> > +static int rnp_post_handle(struct rnp_eth_adapter *adapter) {
> > +   bool on = false;
> > +
> > +   if (!adapter->eth_dev)
> > +   return -ENOMEM;
> > +   if (adapter->do_fw_update && adapter->fw_path) {
> > +   rnp_fw_update(adapter);
> > +   adapter->do_fw_update = 0;
> 
> This patch also enables FW upgrade, can you please detail this in the commit 
> log?
> Or even you can consider to split this part into separate patch.
> 
> 
> 
For this, I will split it to another commit.

RE: [PATCH v6 5/8] net/rnp add reset code for Chip Init process

[11]

Hi  Ferruh,

Please see the below comment.

Regards Wenbo.
> -Original Message-
> From: Ferruh Yigit 
> Sent: 2023年9月5日 23:46
> To: Wenbo Cao 
> Cc: dev@dpdk.org; tho...@monjalon.net; andrew.rybche...@oktetlabs.ru;
> yao...@mucse.com
> Subject: Re: [PATCH v6 5/8] net/rnp add reset code for Chip Init process
> 
> On 9/1/2023 3:30 AM, Wenbo Cao wrote:
> > we must get the shape info of nic from Firmware for
> 
> What is "shape info"?
> 
For the nic 4/8 port mode or one-pcie-one port, media type fiber or copper, 
10G/1G
"shape info" words may be confused.
> > reset. so the related codes is first get firmware info and then reset
> > the chip
> >
> 
> Is there a specific reason to have "Chip Init" start with uppercase, if not 
> please
> make all lowercase, also ':' after domain, like "net/rnp:'.
"Chip Init" is don't have any special meaning, will change the to lowercase.

RE: [PATCH v6 4/8] net/rnp: add mbx basic api feature

[11]

Hi Ferruh,

Please see the below comment :)

Regards Wenbo

> -Original Message-
> From: Ferruh Yigit 
> Sent: 2023年9月5日 23:45
> To: Wenbo Cao 
> Cc: dev@dpdk.org; tho...@monjalon.net; andrew.rybche...@oktetlabs.ru;
> yao...@mucse.com; Stephen Hemminger 
> Subject: Re: [PATCH v6 4/8] net/rnp: add mbx basic api feature
> 
> On 9/1/2023 3:30 AM, Wenbo Cao wrote:
> > mbx base code is for communicate with the firmware
> >
> 
> I assume mbx is mailbox, can you please use full name in the patch title and
> commit log.
> 
Yes, mbx is mailbox.
I will change the commit log 
> How the parties get notified about new messages, is the interrupt support
> enabled or polling, can you please elabore the support in the commit log?
> 
> > Signed-off-by: Wenbo Cao 
> > Suggested-by: Stephen Hemminger 
> > ---
> >  drivers/net/rnp/base/rnp_api.c  |  23 ++
> >  drivers/net/rnp/base/rnp_api.h  |   7 +
> >  drivers/net/rnp/base/rnp_cfg.h  |   7 +
> >  drivers/net/rnp/base/rnp_dma_regs.h |  73 
> > drivers/net/rnp/base/rnp_eth_regs.h | 124 +++
> >  drivers/net/rnp/base/rnp_hw.h   | 112 +-
> 
> Why there is no meson file in base folder?
> 
For base folder also need meson.build ?
I have add the base/.c in the rnp/meson.build.
Do I need to split it to the base/meson.build ?
> >  drivers/net/rnp/meson.build |   1 +
> >  drivers/net/rnp/rnp.h   |  35 ++
> >  drivers/net/rnp/rnp_ethdev.c|  70 +++-
> >  drivers/net/rnp/rnp_logs.h  |   9 +
> >  drivers/net/rnp/rnp_mbx.c   | 522 
> >  drivers/net/rnp/rnp_mbx.h   | 139 
> >  drivers/net/rnp/rnp_mbx_fw.c| 271 +++
> >  drivers/net/rnp/rnp_mbx_fw.h|  22 ++
> 
> Should 'rnp_mbx*' files also go under base folder? I can see they use some 
> 'u8'
> like typedef, making me think they are shared between other platforms, if so 
> base
> folder suits better.
> 
Yes, the mbx.c or rnp_mbx_fw.c  is share code, need change to the base folder.
> >  14 files changed, 1412 insertions(+), 3 deletions(-)  create mode
> > 100644 drivers/net/rnp/base/rnp_api.c  create mode 100644
> > drivers/net/rnp/base/rnp_api.h  create mode 100644
> > drivers/net/rnp/base/rnp_cfg.h  create mode 100644
> > drivers/net/rnp/base/rnp_dma_regs.h
> >  create mode 100644 drivers/net/rnp/base/rnp_eth_regs.h
> >  create mode 100644 drivers/net/rnp/rnp_mbx.c  create mode 100644
> > drivers/net/rnp/rnp_mbx.h  create mode 100644
> > drivers/net/rnp/rnp_mbx_fw.c  create mode 100644
> > drivers/net/rnp/rnp_mbx_fw.h
> >
> > diff --git a/drivers/net/rnp/base/rnp_api.c
> > b/drivers/net/rnp/base/rnp_api.c new file mode 100644 index
> > 00..550da6217d
> > --- /dev/null
> > +++ b/drivers/net/rnp/base/rnp_api.c
> > @@ -0,0 +1,23 @@
> > +#include "rnp.h"
> > +#include "rnp_api.h"
> > +
> > +int
> > +rnp_init_hw(struct rte_eth_dev *dev)
> > +{
> >
> 
> Base code is mostly for works as HAL and you don't need to pass "struct
> rte_eth_dev" in this level, but mostly adapte (struct rnp_eth_adapter) or hw
> (struct rnp_hw) should be sufficient.
> 
Because of one-pcie-bdf have multiple-port, the hw only manage by the adapter 
struct
But the adapter struct and hw struct don't have port info(0,1,2,3).
For this problem I can change 'rte_eth_dev'  to struct rnp_eth_port'
> I assume you are passing "struct rte_eth_dev" because "struct rnp_mac_api" is
> stored in 'process_private', this part I am not clear.
> 
> Why need 'mac_ops' pointers for secondary process?
> Primary process should be doing all hw initialization, otherwise both primary 
> and
> secondar(y|ies) trying to configure the MAC can cause unexpected results.
> 
For secondary process support to set, I find refer driver don't have limit for 
'dev->dev_ops' set in SECONDARY mode.
 .promiscuous_enable
 .promiscuous_disable
 .allmulticast_enable
 .allmulticast_disable
 .fw_version_get
> Seconday process is only for datapath, which can access to the queues and do
> packet processing.
> 
For secondary process support to set, I find refer driver don't have limit for 
'dev->dev_ops' set in SECONDARY mode.
User can set api , if 'dev->dev_ops' set don’t  limit.
> Needing "mac_ops" in the secondary can be bad design desicion, can you please
> double check it?
> 
> <...>
> 
I refer to some exist driver, it is not special limit for SECONDARY process for 
'dev->dev_ops' set.
So when I test some code fond that some api will be cause crash such as 
'get_module_eeprom'
And I find this is because of function point api, the secondary process use 
primary function point api address.
The address for secondary is can't reach. So I try to move the mac_ops, mbx_ops 
to the process_prive to
resolved this problem. Primary and secondary will have it own  function point 
api address.
> > diff --git a/drivers/net/rnp/rnp.h b/drivers/net/rnp/rnp.h index
> > cab1b8e85d..6e12885877 100644
> > --- a/drivers/net/rnp/rnp.h
> > +++ b/drivers/net/rnp/rnp.h
> > @@ -3,6 +3,7 @

RE: [PATCH v6 2/8] net/rnp: add ethdev probe and remove

[11]

> -Original Message-
> From: Ferruh Yigit 
> Sent: 2023年9月5日 23:36
> To: Wenbo Cao ; Anatoly Burakov
> 
> Cc: dev@dpdk.org; tho...@monjalon.net; andrew.rybche...@oktetlabs.ru;
> yao...@mucse.com
> Subject: Re: [PATCH v6 2/8] net/rnp: add ethdev probe and remove
> 
> On 9/1/2023 3:30 AM, Wenbo Cao wrote:
> > Add basic PCIe ethdev probe and remove.
> >
> > Signed-off-by: Wenbo Cao 
> > ---
> >  drivers/net/rnp/rnp.h| 13 ++
> >  drivers/net/rnp/rnp_ethdev.c | 83
> > 
> >  2 files changed, 96 insertions(+)
> >  create mode 100644 drivers/net/rnp/rnp.h
> >
> > diff --git a/drivers/net/rnp/rnp.h b/drivers/net/rnp/rnp.h new file
> > mode 100644 index 00..76d281cc0a
> > --- /dev/null
> > +++ b/drivers/net/rnp/rnp.h
> > @@ -0,0 +1,13 @@
> > +/* SPDX-License-Identifier: BSD-3-Clause
> > + * Copyright(C) 2023 Mucse IC Design Ltd.
> > + */
> > +#ifndef __RNP_H__
> > +#define __RNP_H__
> > +
> > +#define PCI_VENDOR_ID_MUCSE(0x8848)
> > +#define RNP_DEV_ID_N10G(0x1000)
> > +
> > +struct rnp_eth_port {
> > +} __rte_cache_aligned;
> > +
> 
> Is the struct needs to be cache aligned?
> 
This struct may use frequently so I want  it to fast to load.
> > +#endif /* __RNP_H__ */
> > diff --git a/drivers/net/rnp/rnp_ethdev.c
> > b/drivers/net/rnp/rnp_ethdev.c index 9ce3c0b497..390f2e7743 100644
> > --- a/drivers/net/rnp/rnp_ethdev.c
> > +++ b/drivers/net/rnp/rnp_ethdev.c
> > @@ -1,3 +1,86 @@
> >  /* SPDX-License-Identifier: BSD-3-Clause
> >   * Copyright(C) 2023 Mucse IC Design Ltd.
> >   */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "rnp.h"
> > +
> > +static int
> > +rnp_eth_dev_init(struct rte_eth_dev *eth_dev) {
> > +   RTE_SET_USED(eth_dev);
> > +
> > +   return -ENODEV;
> > +}
> > +
> > +static int
> > +rnp_eth_dev_uninit(struct rte_eth_dev *eth_dev) {
> > +   RTE_SET_USED(eth_dev);
> > +
> > +   return -ENODEV;
> > +}
> > +
> > +static int
> > +rnp_pci_remove(struct rte_pci_device *pci_dev) {
> > +   struct rte_eth_dev *eth_dev;
> > +   int rc;
> > +
> > +   eth_dev = rte_eth_dev_allocated(pci_dev->device.name);
> > +
> > +   if (eth_dev) {
> > +   /* Cleanup eth dev */
> > +   rc = rte_eth_dev_pci_generic_remove(pci_dev,
> > +   rnp_eth_dev_uninit);
> > +   if (rc)
> > +   return rc;
> > +   }
> > +   /* Nothing to be done for secondary processes */
> > +   if (rte_eal_process_type() != RTE_PROC_PRIMARY)
> > +   return 0;
> > +
> 
> Primary also don't do anything after this stage, I suggest adding this code 
> when
> primary & secondary diverges.
> 
Ok, I get it.
> > +   return 0;
> > +}
> > +
> > +static int
> > +rnp_pci_probe(struct rte_pci_driver *pci_drv, struct rte_pci_device
> > +*pci_dev) {
> > +   int rc;
> > +
> > +   RTE_SET_USED(pci_drv);
> > +
> > +   rc = rte_eth_dev_pci_generic_probe(pci_dev, sizeof(struct
> rnp_eth_port),
> > +  rnp_eth_dev_init);
> > +
> > +   /* On error on secondary, recheck if port exists in primary or
> > +* in mid of detach state.
> > +*/
> > +   if (rte_eal_process_type() != RTE_PROC_PRIMARY && rc)
> > +   if (!rte_eth_dev_allocated(pci_dev->device.name))
> > +   return 0;
> 
> Why this additional secondary check is required?
> 'rte_eth_dev_pci_generic_probe()' should be dealing with primary/secondary
> process case.
> 
Because of multiple port mode single pcie-bdf the other port
Alloc use xx:xx.0_0, xx:xx.0_1, xx:xx.0_2, xx:xx.0_0,  use rnp_alloc_eth_port 
api.

RE: [PATCH v6 3/8] net/rnp: add device init and uninit

[11]

Hi Ferruh,

Thanks your kindly review, please see the below comment.

Regards Wenbo

> -Original Message-
> From: Ferruh Yigit 
> Sent: 2023年9月5日 23:44
> To: Wenbo Cao ; Anatoly Burakov
> 
> Cc: dev@dpdk.org; tho...@monjalon.net; andrew.rybche...@oktetlabs.ru;
> yao...@mucse.com
> Subject: Re: [PATCH v6 3/8] net/rnp: add device init and uninit
> 
> On 9/1/2023 3:30 AM, Wenbo Cao wrote:
> > Add basic init and uninit function
> >
> > Signed-off-by: Wenbo Cao 
> > ---
> >  drivers/net/rnp/base/rnp_hw.h |  19 
> >  drivers/net/rnp/meson.build   |   1 +
> >  drivers/net/rnp/rnp.h |  25 +
> >  drivers/net/rnp/rnp_ethdev.c  | 196 +-
> >  drivers/net/rnp/rnp_logs.h|  34 ++
> >  drivers/net/rnp/rnp_osdep.h   |  30 ++
> >  6 files changed, 300 insertions(+), 5 deletions(-)  create mode
> > 100644 drivers/net/rnp/base/rnp_hw.h  create mode 100644
> > drivers/net/rnp/rnp_logs.h  create mode 100644
> > drivers/net/rnp/rnp_osdep.h
> >
> 
> 'rnp_osdep.h' not used at all in the patch, can you move it where it is used?
> 
I got it.
> > diff --git a/drivers/net/rnp/base/rnp_hw.h
> > b/drivers/net/rnp/base/rnp_hw.h new file mode 100644 index
> > 00..d80d23f4b4
> > --- /dev/null
> > +++ b/drivers/net/rnp/base/rnp_hw.h
> > @@ -0,0 +1,19 @@
> > +/* SPDX-License-Identifier: BSD-3-Clause
> > + * Copyright(C) 2023 Mucse IC Design Ltd.
> > + */
> > +#ifndef __RNP_HW_H__
> > +#define __RNP_HW_H__
> > +
> > +struct rnp_eth_adapter;
> > +struct rnp_hw {
> > +   struct rnp_eth_adapter *back;
> > +   void *iobar0;
> > +   uint32_t iobar0_len;
> > +   void *iobar4;
> > +   uint32_t iobar4_len;
> > +
> > +   uint16_t device_id;
> > +   uint16_t vendor_id;
> > +} __rte_cache_aligned;
> > +
> 
> All structs seems alligned to the cache, although it may not hurt, it is 
> better to
> align ones that is necessary for performance.
> 
> <...>
> 
For this I need to select a often used struct value?
> > +
> > +static struct rte_eth_dev *
> > +rnp_alloc_eth_port(struct rte_pci_device *primary_pci, char *name)
> 
> Why variable name is 'primary_pci', are there different pci device types?
> 
Because of the chip is just have two pcie-bdf, the can have max eight port,
So rte_eth_dev_pci_generic_probe alloc the first port, the other port is a fake 
string
Add for x:x.0_1, x:x.0_2, x:x.0_3, so the 'primary_pci' is to mark the real 
pci_addr
> > +{
> > +   struct rnp_eth_port *port;
> > +   struct rte_eth_dev *eth_dev;
> > +
> > +   eth_dev = rte_eth_dev_allocate(name);
> > +   if (!eth_dev) {
> > +   RNP_PMD_DRV_LOG(ERR, "Could not allocate "
> > +   "eth_dev for %s\n", name);
> 
> Please don't split the log message, instead can do:
> RNP_PMD_DRV_LOG(ERR,
>   "Could not allocate eth_dev for %s\n",
>   name);
> 
> Same for all log messages.
> 
Ok, I got it.
> > +   return NULL;
> > +   }
> > +   port = rte_zmalloc_socket(name,
> > +   sizeof(*port),
> > +   RTE_CACHE_LINE_SIZE,
> > +   primary_pci->device.numa_node);
> > +   if (!port) {
> > +   RNP_PMD_DRV_LOG(ERR, "Could not allocate "
> > +   "rnp_eth_port for %s\n", name);
> > +   return NULL;
> 
> Should 'eth_dev' released here?
> 
Yes , this need to free resource.
> > +   }
> > +   eth_dev->data->dev_private = port;
> > +   eth_dev->process_private = calloc(1, sizeof(struct rnp_share_ops));
> > +   if (!eth_dev->process_private) {
> > +   RNP_PMD_DRV_LOG(ERR, "Could not calloc "
> > +   "for Process_priv\n");
> > +   goto fail_calloc;
> > +   }
> > +   return eth_dev;
> > +fail_calloc:
> > +   rte_free(port);
> > +   rte_eth_dev_release_port(eth_dev);
> > +
> > +   return NULL;
> > +}
> > +
> > +static int
> > +rnp_eth_dev_init(struct rte_eth_dev *dev) {
> > +   struct rte_pci_device *pci_dev = RTE_ETH_DEV_TO_PCI(dev);
> > +   struct rnp_eth_adapter *adapter = NULL;
> > +   char name[RTE_ETH_NAME_MAX_LEN] = " ";
> > +   struct rnp_eth_port *port = NULL;
> > +   struct rte_eth_dev *eth_dev;
> > +   struct rnp_hw *hw = NULL;
> > +   int32_t p_id;
> > +   int ret;
> > +
> > +   PMD_INIT_FUNC_TRACE();
> > +
> > +   if (rte_eal_process_type() != RTE_PROC_PRIMARY)
> > +   return 0;
> > +   memset(name, 0, sizeof(name));
> > +   snprintf(name, sizeof(name), "rnp_adapter_%d", dev->data->port_id);
> > +   adapter = rte_zmalloc(name, sizeof(struct rnp_eth_adapter), 0);
> > +   if (!adapter) {
> > +   RNP_PMD_DRV_LOG(ERR, "zmalloc for adapter failed\n");
> > +   return -ENOMEM;
> > +   }
> > +   hw = &adapter->hw;
> > +   adapter->pdev = pci_dev;
> > +   adapter->eth_dev = dev;
> > +   adapter->num_ports = 1;
> 
> This is hardcoded value, so no need the loop below but perhaps it is for 
> future.
> 
I will change the commit sequence ,first achieve mailbox api get hw-info.
So adapter->num_ports info will get from firmware.
> > +   hw->back 

RE: [[PATCH v1] 4/8] net/rnp: add mbx basic api feature

[11]

Hi Stephen,

Thanks for your comment, as your advice that I need to define the virtual
function pointers
As the below type ?
const struct rnp_mbx_api {
..
}
If It will protect the virtual function address ,won't be remove by mistake?

Regards Wenbo
-Original Message-
From: Stephen Hemminger  
Sent: 2023年8月1日 23:26
To: Wenbo Cao 
Cc: dev@dpdk.org
Subject: Re: [[PATCH v1] 4/8] net/rnp: add mbx basic api feature

On Tue,  1 Aug 2023 07:22:07 +
Wenbo Cao  wrote:

> +struct rnp_mbx_api {
> + void (*init_mbx)(struct rnp_hw *hw);
> + int32_t (*read)(struct rnp_hw *hw,
> + uint32_t *msg,
> + uint16_t size,
> + enum MBX_ID);
> + int32_t (*write)(struct rnp_hw *hw,
> + uint32_t *msg,
> + uint16_t size,
> + enum MBX_ID);
> + int32_t (*read_posted)(struct rte_eth_dev *dev,
> + uint32_t *msg,
> + uint16_t size,
> + enum MBX_ID);
> + int32_t (*write_posted)(struct rte_eth_dev *dev,
> + uint32_t *msg,
> + uint16_t size,
> + enum MBX_ID);
> + int32_t (*check_for_msg)(struct rnp_hw *hw, enum MBX_ID);
> + int32_t (*check_for_ack)(struct rnp_hw *hw, enum MBX_ID);
> + int32_t (*check_for_rst)(struct rnp_hw *hw, enum MBX_ID);
> + int32_t (*configure)(struct rnp_hw *hw, int nr_vec, bool enable); };

Since this data structure only has virtual function pointers; many types of
bugs can be avoided if it can be made const.
If it const, then compiler can put the initialized table in r/o text
section.

RE: [[PATCH v1] 3/8] net/rnp: add device init and uninit

[11]

Hi Stephen,

Why have two labels for same place, to later patches insert code here?
For this question the new code in rnp_init_port_resource
Will zmalloc dev->data->mac_addrs  and  dev->data->hash_mac_addrs
So I wish to free the zmalloc mem when init port resource failed


Regards wenbo

-Original Message-
From: Stephen Hemminger  
Sent: 2023年8月1日 23:21
To: Wenbo Cao 
Cc: Anatoly Burakov ; dev@dpdk.org
Subject: Re: [[PATCH v1] 3/8] net/rnp: add device init and uninit

On Tue,  1 Aug 2023 06:43:41 +
Wenbo Cao  wrote:

> + return 0;
> +eth_alloc_error:
> +init_failed:

Why have two labels for same place, to later patches insert code here?

RE: [[PATCH v1] 0/8] *** SUBJECT HERE ***

[11]

Your git commit headings are messed up with extra [].
Yes, this is my problem :) 
David has been mentioned before , I'm re edit the cover-letter now.
Thanks a lot.

Regards wenbo
-Original Message-
From: Stephen Hemminger  
Sent: 2023年8月2日 10:31
To: Wenbo Cao 
Cc: dev@dpdk.org
Subject: Re: [[PATCH v1] 0/8] *** SUBJECT HERE ***

On Tue,  1 Aug 2023 07:21:29 +
Wenbo Cao  wrote:

> *** BLURB HERE ***
> 
> Wenbo Cao (8):
>   net/rnp: add skeleton
>   net/rnp: add ethdev probe and remove
>   net/rnp: add device init and uninit
>   net/rnp: add mbx basic api feature
>   net/rnp add reset code for Chip Init process
>   net/rnp add port info resource init
>   net/rnp add devargs runtime parsing functions
>   net/rnp handle device interrupts
> 
>  MAINTAINERS |   6 +
>  doc/guides/nics/features/rnp.ini|   8 +
>  doc/guides/nics/index.rst   |   1 +
>  doc/guides/nics/rnp.rst |  43 ++
>  drivers/net/meson.build |   1 +
>  drivers/net/rnp/base/rnp_api.c  |  71 +++
>  drivers/net/rnp/base/rnp_api.h  |  17 +
>  drivers/net/rnp/base/rnp_cfg.h  |   7 +
>  drivers/net/rnp/base/rnp_dma_regs.h |  73 +++  
> drivers/net/rnp/base/rnp_eth_regs.h | 124 +
>  drivers/net/rnp/base/rnp_hw.h   | 193 +++
>  drivers/net/rnp/base/rnp_mac_regs.h | 279 ++
>  drivers/net/rnp/meson.build |  18 +
>  drivers/net/rnp/rnp.h   | 217 
>  drivers/net/rnp/rnp_ethdev.c| 823 
>  drivers/net/rnp/rnp_logs.h  |  43 ++
>  drivers/net/rnp/rnp_mbx.c   | 522 ++
>  drivers/net/rnp/rnp_mbx.h   | 139 +
>  drivers/net/rnp/rnp_mbx_fw.c| 781 ++
>  drivers/net/rnp/rnp_mbx_fw.h| 401 ++
>  drivers/net/rnp/rnp_osdep.h |  30 +
>  drivers/net/rnp/rnp_rxtx.c  |  83 +++
>  drivers/net/rnp/rnp_rxtx.h  |  14 +
>  23 files changed, 3894 insertions(+)
>  create mode 100644 doc/guides/nics/features/rnp.ini  create mode 
> 100644 doc/guides/nics/rnp.rst  create mode 100644 
> drivers/net/rnp/base/rnp_api.c  create mode 100644 
> drivers/net/rnp/base/rnp_api.h  create mode 100644 
> drivers/net/rnp/base/rnp_cfg.h  create mode 100644 
> drivers/net/rnp/base/rnp_dma_regs.h
>  create mode 100644 drivers/net/rnp/base/rnp_eth_regs.h
>  create mode 100644 drivers/net/rnp/base/rnp_hw.h  create mode 100644 
> drivers/net/rnp/base/rnp_mac_regs.h
>  create mode 100644 drivers/net/rnp/meson.build  create mode 100644 
> drivers/net/rnp/rnp.h  create mode 100644 drivers/net/rnp/rnp_ethdev.c  
> create mode 100644 drivers/net/rnp/rnp_logs.h  create mode 100644 
> drivers/net/rnp/rnp_mbx.c  create mode 100644 
> drivers/net/rnp/rnp_mbx.h  create mode 100644 
> drivers/net/rnp/rnp_mbx_fw.c  create mode 100644 
> drivers/net/rnp/rnp_mbx_fw.h  create mode 100644 
> drivers/net/rnp/rnp_osdep.h  create mode 100644 
> drivers/net/rnp/rnp_rxtx.c  create mode 100644 
> drivers/net/rnp/rnp_rxtx.h

Your git commit headings are messed up with extra [].

RE: [PATCH v2 2/8] net/rnp: add ethdev probe and remove

[11]

Hello Stephen,

Thanks for your comment.
For vfio-pci mode we can support it, but when multiple rerun dpdk-app,
In rte_eal_init the logical of vfio will reset pcie.
The firmware will be core-dump for read pcie Configuration Space, when the
pcie is in reset state.
This bug is resolving and testing, so that this code just support igb_uio.
Until the test has been finished, I will add vfio-pci ability.
Do I need add this ability of vfio in this patch ?

Regards Wenbo

-Original Message-
From: Stephen Hemminger  
Sent: 2023年8月3日 0:07
To: Wenbo Cao 
Cc: Anatoly Burakov ; dev@dpdk.org;
ferruh.yi...@intel.com; andrew.rybche...@oktetlabs.ru
Subject: Re: [PATCH v2 2/8] net/rnp: add ethdev probe and remove

On Wed,  2 Aug 2023 08:11:00 +
Wenbo Cao  wrote:

> +RTE_PMD_REGISTER_PCI(net_rnp, rte_rnp_pmd); 
> +RTE_PMD_REGISTER_PCI_TABLE(net_rnp, pci_id_rnp_map); 
> +RTE_PMD_REGISTER_KMOD_DEP(net_txgbe, "igb_uio | uio_pci_generic");

Will this driver work with VFIO? Vfio is preferred over igb_uio.

RE: [PATCH v2 4/8] net/rnp: add mbx basic api feature

[11]

Hello, Stephen
Fort this struct is used for communicate with firmware or
Pf communicate with vf.
It is used for sync the communicative event.
It isn't used for performance sampling.
For u32(uint32_t) is because of the hardware register is 32bit read/write.
So this counter size is enouth.
>+struct rnp_mbx_stats {
>...
>+}

Regards Wenbo
-Original Message-
From: Stephen Hemminger  
Sent: 2023年8月3日 0:12
To: Wenbo Cao 
Cc: dev@dpdk.org; ferruh.yi...@intel.com; andrew.rybche...@oktetlabs.ru
Subject: Re: [PATCH v2 4/8] net/rnp: add mbx basic api feature

On Wed,  2 Aug 2023 08:11:02 +
Wenbo Cao  wrote:

> +struct rnp_mbx_stats {
> + u32 msgs_tx;
> + u32 msgs_rx;
> +
> + u32 acks;
> + u32 reqs;
> + u32 rsts;
> +};

Easy to cause wraparound of 32 bits in these stats.
Why use u32 and not uint32_t or uint64_t.

> +struct rnp_mbx_info {
> + struct rnp_mbx_api ops;
> + uint32_t usec_delay;/* retry interval delay time */
> + uint32_t timeout;   /* retry ops timeout limit */
> + uint16_t size;  /* data buffer size*/
> + uint16_t vf_num;/* Virtual Function num */
> + uint16_t pf_num;/* Physical Function num */
> + uint16_t sriov_st;  /* Sriov state */
> + bool irq_enabled;
> + union {
> + struct {
> + unsigned short pf_req;
> + unsigned short pf_ack;
> + };
> + struct {
> + unsigned short cpu_req;
> + unsigned short cpu_ack;
> + };
> + };
> + unsigned short vf_req[64];
> + unsigned short vf_ack[64];
> +
> + struct rnp_mbx_stats stats;
> +
> + rte_atomic16_t state;
> +} __rte_cache_aligned;

You may want to reorder this data structure to reduce cache misses.
The last element is almost certainly on another cache line.
Also, if you want faster statistics should consider per core, per queue or
per VF.

RE: [PATCH v2 3/8] net/rnp: add device init and uninit

[11]

Thanks a lot, this problem that I have never been thought about it.

Regards Wenbo.
-Original Message-
From: Stephen Hemminger  
Sent: 2023年8月3日 0:08
To: Wenbo Cao 
Cc: Anatoly Burakov ; dev@dpdk.org;
ferruh.yi...@intel.com; andrew.rybche...@oktetlabs.ru
Subject: Re: [PATCH v2 3/8] net/rnp: add device init and uninit

On Wed,  2 Aug 2023 08:11:01 +
Wenbo Cao  wrote:

> +struct rnp_hw {
> + void *back;
> + char *iobar0;
> + uint32_t iobar0_len;
> + char *iobar4;
> + uint32_t iobar4_len;

If possible, don't use untyped pointer for link list (back).
The iobar's should probably be void * or better yet map to data structure.

Casts are often a source of bugs in C code.

RE: [PATCH v5 1/8] net/rnp: add skeleton

[11]

Hi Thomas,

Thanks for your useful advice, previously only focused on code format
and Ignored document format.

Regards Wenbo   

> -Original Message-
> From: Thomas Monjalon 
> Sent: 2023年8月15日 19:11
> To: Wenbo Cao 
> Cc: dev@dpdk.org; ferruh.yi...@amd.com; andrew.rybche...@oktetlabs.ru;
> yao...@mucse.com
> Subject: Re: [PATCH v5 1/8] net/rnp: add skeleton
> 
> Hi,
> 
> Wenbo Cao:
> > --- /dev/null
> > +++ b/doc/guides/nics/rnp.rst
> > @@ -0,0 +1,43 @@
> > +..  SPDX-License-Identifier: BSD-3-Clause
> > +Copyright(c) 2023 Mucse IC Design Ltd.
> > +
> > +RNP Poll Mode driver
> > +==
> 
> Please keep underlining the same size as the text above.
Thanks for your kindly comment,  the format  of document  I must lake of
this knowledge
> 
> > +
> > +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 RNP SoCs
> > +
> > +
> > +- N10
> > +
> > +Driver compilation and testing
> > +--
> > +
> > +Refer to the document :ref:`compiling and testing a PMD for a NIC
> > +` for details.
> 
> It was a mistake to originally introduce the anchor "pmd_build_and_test".
> You should achieve the same result with the shorter
> syntax :doc:`build_and_test`
> 
> > +
> > +#. Running testpmd:
> > +
> > +   Follow instructions available in the document
> > +   :ref:`compiling and testing a PMD for a NIC `
> > +   to run testpmd.
> 
> Do we really need that referencing the same document as above?
For this block,  there's really no need to add this.
Previous ideas I want to add new content as the subsequent code is
submitted.
Do I need to add full features and NIC Description at the first code commit
?
> 
> > +
> > +Limitations or Known issues
> > +
> > +Build with ICC is not supported yet.
> > +CRC stripping
> > +~~
> > +The RNP SoC family NICs strip the CRC for every packets coming into
> > +the host interface irrespective of the offload configuration.
> > +When You Want To Disable CRC_OFFLOAD The Feature Will Influence The
> > +RxCksum Offload VLAN Strip ~~~ For VLAN Strip RNP Just
> > +Support CVLAN(0x8100) Type If The Vlan Type Is SVLAN(0X88a8) VLAN
> > +Filter Or Strip Will Not Effert For This Packet It Will Bypass To The
Host.
> 
> Please check the doc contribution guide.
> You should add spaces before and after titles.
Yes this is my fault, :) , I have read the document  and  known that
Add 2 blank lines before each section header.
Add 1 blank line after each section header.
> 
> 

RE: [PATCH v6 1/8] net/rnp: add skeleton

[11]

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.yi...@amd.com 
> Sent: 2024年3月29日 19:28
> To: Wenbo Cao ; Thomas Monjalon
> 
> 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 
> >
> 
> Hi Wenbo,
> 
> What is the status of the 'rnp' driver, v7 was expected but not received, will
> upstreaming continue for v24.03?

RE: [PATCH v8 00/28] [v8]drivers/net Add Support mucse N10 Pmd Driver

[11]

Hi Stephen,

Thanks for your guideine, I will fixed these soon.

Regards Wenbo

> -Original Message-
> From: Stephen Hemminger 
> Sent: 2025年2月11日 3:04
> To: Wenbo Cao 
> Cc: tho...@monjalon.net; dev@dpdk.org; ferruh.yi...@amd.com;
> andrew.rybche...@oktetlabs.ru; yao...@mucse.com
> Subject: Re: [PATCH v8 00/28] [v8]drivers/net Add Support mucse N10 Pmd
> Driver
> 
> Driver review checklist for mucse PMD
> 
> Mark items with:
> ✔ passed
> ✘ Failed
> 
> Basic hygiene
> ✘ Look at CI results in patchwork; notify submitter if any failures
> ✔ Merge cleanly with git am; look for missing newline at EOF etc
> ✘ Run checkpatches; warnings are ok, but look more carefully.
> ✘ Run check-git-log; often get some minor warnings that are ok
> ✔ Run check-symbol-maps.sh
> ✔ Run check-doc-vs-code
> ✔ Run check-spdk-tag
> 
> Builds
> ✘ Normal Gcc build; make sure driver is built!
> ✘ Use latest experimental Gcc 15 to catch new warnings
> ✘ Clang build using current version (clang-19)
> ✘ Doc build
> 
> Rest of checklist skipped, not worth running with these kind of failures

RE: [PATCH v9 00/28] [v9]drivers/net Add Support mucse N10 Pmd Driver

[11]

Hi Stephen，

For rsic-v,windows freebsd plaform, I need to limit compile meson file what we 
not support ?

Regards Wenbo

> -Original Message-
> From: Stephen Hemminger 
> Sent: 2025年2月11日 22:57
> To: Wenbo Cao 
> Cc: tho...@monjalon.net; dev@dpdk.org; ferruh.yi...@amd.com;
> andrew.rybche...@oktetlabs.ru; yao...@mucse.com
> Subject: Re: [PATCH v9 00/28] [v9]drivers/net Add Support mucse N10 Pmd
> Driver
> 
> On Tue, 11 Feb 2025 16:49:50 +0800
> Wenbo Cao  wrote:
> 
> > For This patchset just to support the basic chip init work and user
> > can just found the eth_dev, but can't control more.
> > For Now just support 2*10g nic,the chip can support
> > 2*10g,4*10g,4*1g,8*1g,8*10g.
> > The Feature rx side can support rx-cksum-offload,rss,vlan-filter
> > flow_clow,uncast_filter,mcast_filter,1588,Jumbo-frame
> > The Feature tx side can support tx-cksum-offload,tso,vxlan-tso flow
> > director base on ntuple pattern of tcp/udp/ip/ eth_hdr->type for sriov
> > is also support.
> >
> > Because of the chip design defect, for multiple-port mode one pci-bdf
> > will have multiple-port (max can have four ports) so this code must be
> > care of one bdf init multiple-port.
> >
> > v9:
> >   * fixed commit log format check by devtools.
> >   * fixed code compile issue.
> >
> > v8:
> >   * fixed codespell issue.
> >   * fixed MAINTAINERS file
> >
> > v7:
> >   * add support nic basic feature such as rss vlan strip/filter,
> >   * mtu-change recv/send scater-recv/mutltiple-send.
> >   * fixed code rationality, advised by Ferruh Yigit.
> > v6:
> >   * fixed the doc(rst) format problem advise by Thomas Monjalon
> >
> > v5:
> >   * fixed the symbol name require by the style documentation
> >
> > v4:
> >   * one patch has been forgot to upload :(
> >
> > v3:
> >   * fixed http://dpdk.org/patch/129830 FreeBSD 13 compile Issue
> >   * change iobar type to void suggest by Stephen Hemminger
> >   * add KMOD_DEP support for vfio-pci
> >   * change run-cmd argument parse check for invalid extra_args
> >
> > v2:
> >   * fixed MAINTAIN maillist fullname format
> >   * fixed driver/net/meson the order issue of new driver to driver list
> >   * improve virtual point function usage suggest by Stephen Hemminger
> >
> > Wenbo Cao (28):
> >   net/rnp: add skeleton
> >   net/rnp: add ethdev probe and remove
> >   net/rnp: add log
> >   net/rnp: support mailbox basic operate
> >   net/rnp: add device init and uninit
> >   net/rnp: add get device information operation
> >   net/rnp: add support MAC promisc mode
> >   net/rnp: add queue setup and release operations
> >   net/rnp: add queue stop and start operations
> >   net/rnp: add support device start stop operations
> >   net/rnp: add RSS support operations
> >   net/rnp: add support link update operations
> >   net/rnp: add support link setup operations
> >   net/rnp: add Rx burst simple support
> >   net/rnp: add Tx burst simple support
> >   net/rnp: add MTU set operation
> >   net/rnp: add Rx scatter segment version
> >   net/rnp: add Tx multiple segment version
> >   net/rnp: add support basic stats operation
> >   net/rnp: add support xstats operation
> >   net/rnp: add unicast MAC filter operation
> >   net/rnp: add supported packet types
> >   net/rnp: add support Rx checksum offload
> >   net/rnp: add support Tx TSO offload
> >   net/rnp: support VLAN offloads
> >   net/rnp: add support VLAN filters operations
> >   net/rnp: add queue info operation
> >   net/rnp: support Rx/Tx burst mode info
> >
> >  .mailmap|1 +
> >  MAINTAINERS |6 +
> >  doc/guides/nics/features/rnp.ini|   33 +
> >  doc/guides/nics/index.rst   |1 +
> >  doc/guides/nics/rnp.rst |  101 ++
> >  drivers/net/meson.build |1 +
> >  drivers/net/rnp/base/meson.build|   28 +
> >  drivers/net/rnp/base/rnp_bdq_if.c   |  398 ++
> >  drivers/net/rnp/base/rnp_bdq_if.h   |  154 +++
> >  drivers/net/rnp/base/rnp_bitrev.h   |   64 +
> >  drivers/net/rnp/base/rnp_common.c   |  103 ++
> >  drivers/net/rnp/base/rnp_common.h   |   17 +
> >  drivers/net/rnp/base/rnp_crc32.c|   37 +
> >  drivers/net/rnp/base/rnp_crc32.h|   10 +
> >  drivers/net/rnp/base/rnp_dma_regs.h |   68 +
> >  drivers/net/rnp/base/rnp_eth_regs.h |   90 ++
> >  drivers/net/rnp/base/rnp_fw_cmd.c   |  162 +++
> >  drivers/net/r

RE: [PATCH v9 12/28] net/rnp: add support link update operations

[11]

Hi Stephen,

Thanks for your explain abort the memcpy,  on Fedora41  I had I understood
why
rte_memcpy will cause compile fault. I will be carefull to use memcpy,
when a address of src or dst is not alignment.

Regards Wenbo

> -Original Message-
> From: Stephen Hemminger 
> Sent: 2025年2月12日 23:38
> To: 11 
> Cc: tho...@monjalon.net; dev@dpdk.org; ferruh.yi...@amd.com;
> andrew.rybche...@oktetlabs.ru; yao...@mucse.com
> Subject: Re: [PATCH v9 12/28] net/rnp: add support link update operations
> 
> On Wed, 12 Feb 2025 11:21:49 +0800
> "11"  wrote:
> 
> > Hi Stephen,
> > For memcpy what ever base code or other code all used memcpy not
> > rte_memcpy ?
> > Even the memory is malloc from rte_malloc/zmalloc ?
> >
> > Regards Wenbo.
> 
> 
> The documentation doesn't make it clear but rte_memcpy is the same as
> memcpy.
> It only exists because for some cases (like older versions of Gcc and
differences in
> alignment assumptions) when running micro benchmarks rte_memcpy was
> faster.
> 
> All new code should only use memcpy() unless there is a benchmark test
that
> shows a noticable difference. The reason is that tools like Coverity, Gcc,
Clang,
> and PVS studio all treat memcpy specially and can do checks for access
outside of
> range.

RE: [PATCH v6 0/8] [v6]drivers/net Add Support mucse N10 Pmd Driver

[11]

Hi Thomas,

 I will continue to work on it on this quarter,
a more detail servial patchs will be summit  after the Spring Festival.

Regards Wenbo

> -Original Message-
> From: Thomas Monjalon 
> Sent: 2025年1月17日 0:50
> To: yao...@mucse.com; Wenbo Cao 
> Cc: dev@dpdk.org; ferruh.yi...@amd.com; andrew.rybche...@oktetlabs.ru;
> step...@networkplumber.org
> Subject: Re: [PATCH v6 0/8] [v6]drivers/net Add Support mucse N10 Pmd Driver
> 
> Hello,
> 
> Is there any plan to resume this work?
> 
> 
> 01/09/2023 04:30, Wenbo Cao:
> > For This patchset just to support the basic chip init work and user
> > can just found the eth_dev, but can't control more.
> > For Now just support 2*10g nic,the chip can support
> > 2*10g,4*10g,4*1g,8*1g,8*10g.
> > The Feature rx side can support rx-cksum-offload,rss,vlan-filter
> > flow_clow,uncast_filter,mcast_filter,1588,Jumbo-frame
> > The Feature tx side can supprt tx-cksum-offload,tso,vxlan-tso flow
> > director base on ntuple pattern of tcp/udp/ip/ eth_hdr->type for sriov
> > is also support.
> >
> > Because of the chip desgin defect, for multiple-port mode one pci-bdf
> > will have multiple-port (max can have four ports) so this code must be
> > care of one bdf init multiple-port.
> 
> 
> 
> 

RE: [PATCH v9 04/28] net/rnp: support mailbox basic operate

[11]

Hi Stephen,

This flag add will ignore some warning error ?
> +error_cflags = ['-Wno-unused-value',
> +'-Wno-unused-but-set-variable',
> +'-Wno-unused-parameter',
> +]

Regards Wenbo

> -Original Message-----
> From: Stephen Hemminger 
> Sent: 2025年2月11日 23:24
> To: Wenbo Cao 
> Cc: tho...@monjalon.net; dev@dpdk.org; ferruh.yi...@amd.com;
> andrew.rybche...@oktetlabs.ru; yao...@mucse.com
> Subject: Re: [PATCH v9 04/28] net/rnp: support mailbox basic operate
> 
> On Tue, 11 Feb 2025 16:49:54 +0800
> Wenbo Cao  wrote:
> 
> > diff --git a/drivers/net/rnp/base/meson.build
> > b/drivers/net/rnp/base/meson.build
> > new file mode 100644
> > index 00..9ea88c3bff
> > --- /dev/null
> > +++ b/drivers/net/rnp/base/meson.build
> > @@ -0,0 +1,22 @@
> > +# SPDX-License-Identifier: BSD-3-Clause # Copyright(C) 2023 Mucse IC
> > +Design Ltd.
> > +
> > +sources = [
> > +'rnp_mbx.c',
> > +]
> > +
> > +error_cflags = ['-Wno-unused-value',
> > +'-Wno-unused-but-set-variable',
> > +'-Wno-unused-parameter',
> > +]
> 
> Put the first item on new line, meson is like python and similar style
applies.
> It is disappointing that base code is so messy that you have to disable
warnings.
> 
> > +c_args = cflags
> > +foreach flag: error_cflags
> > +if cc.has_argument(flag)
> > +c_args += flag
> > +endif
> > +endforeach

RE: [PATCH v9 08/28] net/rnp: add queue setup and release operations

[11]

Hi Stephe,

The spinlock of rxq_reset_lock, and txq_reset than I need it to make sure
one time just one user can call
queue_stop operate a queue reset, hardware only support reset queue head to
zero only one user operate.
When queue_stop 0 and queue_stop 1 operate at  the same time, the hardware
queue reset will be fault.
Even port0 and port1 of  one pf, operate queue reset will be also fault.
For rx_burst and tx_burst that I don't used the spinlock

Regards Wenbo

> -Original Message-
> From: Stephen Hemminger 
> Sent: 2025年2月12日 0:02
> To: Wenbo Cao 
> Cc: tho...@monjalon.net; dev@dpdk.org; ferruh.yi...@amd.com;
> andrew.rybche...@oktetlabs.ru; yao...@mucse.com
> Subject: Re: [PATCH v9 08/28] net/rnp: add queue setup and release
operations
> 
> On Tue, 11 Feb 2025 16:49:58 +0800
> Wenbo Cao  wrote:
> 
> > diff --git a/drivers/net/rnp/base/rnp_hw.h
> > b/drivers/net/rnp/base/rnp_hw.h index da2c1d3b0e..ea4e1b8d83 100644
> > --- a/drivers/net/rnp/base/rnp_hw.h
> > +++ b/drivers/net/rnp/base/rnp_hw.h
> > @@ -120,6 +120,9 @@ struct rnp_hw {
> > bool lane_is_sgmii[RNP_MAX_PORT_OF_PF];
> > struct rnp_mbx_info mbx;
> > struct rnp_fw_info fw_info;
> > +
> > +   spinlock_t rxq_reset_lock; /* reset op isn't thread safe */
> > +   spinlock_t txq_reset_lock; /* reset op isn't thread safe */
> >  };
> >
> 
> In DPDK control operations do not need to be thread safe.
> Many other drivers do not allow start/stop in one thread while tx/rx are
> happening etc.
> This is because rx/tx should not have overhead of any locks.
> The cost of one spinlock at 10G will drop performance a lot

RE: [PATCH v9 12/28] net/rnp: add support link update operations

[11]

Hi Stephen,
For memcpy what ever base code or other code all used memcpy not rte_memcpy
?
Even the memory is malloc from rte_malloc/zmalloc ?

Regards Wenbo.

> -Original Message-
> From: Stephen Hemminger 
> Sent: 2025年2月11日 23:35
> To: Wenbo Cao 
> Cc: tho...@monjalon.net; dev@dpdk.org; ferruh.yi...@amd.com;
> andrew.rybche...@oktetlabs.ru; yao...@mucse.com
> Subject: Re: [PATCH v9 12/28] net/rnp: add support link update operations
> 
> On Tue, 11 Feb 2025 16:50:02 +0800
> Wenbo Cao  wrote:
> 
> > static int
> > +rnp_mbx_fw_reply_handler(struct rnp_eth_adapter *adapter,
> > +struct rnp_mbx_fw_cmd_reply *reply) {
> > +   struct rnp_mbx_req_cookie *cookie;
> > +
> > +   RTE_SET_USED(adapter);
> > +   /* dbg_here; */
> > +   cookie = reply->cookie;
> > +   if (!cookie || cookie->magic != RNP_COOKIE_MAGIC) {
> > +   RNP_PMD_ERR("[%s] invalid cookie:%p opcode: "
> > +   "0x%x v0:0x%x",
> > +   __func__,
> > +   cookie,
> > +   reply->opcode,
> > +   *((int *)reply));
> 
> Don't break messages across lines in source. It makes it harder to search.
> You don't need __func__, it is already being added by the macro.
> 
> > +   return -EIO;
> > +   }
> > +   if (cookie->priv_len > 0)
> > +   rte_memcpy(cookie->priv, reply->data, cookie->priv_len);
> 
> Use memcpy instead of rte_memcpy in all new code.
> 
> > +
> > +   cookie->done = 1;
> > +   if (reply->flags & RNP_FLAGS_ERR)
> > +   cookie->errcode = reply->error_code;
> > +   else
> > +   cookie->errcode = 0;
> > +
> > +   return 0;
> > +}

RE: [PATCH v13 00/28] [v13]drivers/net Add Support mucse N10 Pmd Driver

[11]

Hi Stephen,

For the release thing, that be ok.

But for Debian 12 with MUSDK it be failed, do I need to fixed it ,
The ability when I used it that I had been memset it. But the compile-tool
is warning it,
 hw->phy_port_ids[idx] = ability.port_ids[idx];

Branch: master
CommitID:968f7b6d7b6a7e60e6e551db430c4eecaccbbfd2

151613-151639 --> testing issues

Upstream job id: Generic-DPDK-Compile-Meson#362983

Test environment and result as below:

+++
|  Environment   | dpdk_meson_compile |
+++
| RHEL9 (ARM)| PASS   |
+++
| Ubuntu 20.04 ARM GCC Cross Compile | PASS   |
+++
| Ubuntu 20.04 ARM SVE   | PASS   |
+++
| Debian 12 with MUSDK   | FAIL   |
+++
| Fedora 40 (ARM Clang)  | PASS   |
+++
| Fedora 41 (ARM Clang)  | PASS   |
+++
| Fedora 41 (ARM)| PASS   |
+++
| Fedora 40 (ARM)| PASS   |
+++
| Ubuntu 20.04 (ARM) | PASS   |
+++
| Ubuntu 22.04 (ARM) | PASS   |
+++
| Ubuntu 24.04 (ARM) | PASS   |
+++
| CentOS Stream 9 (ARM)  | PASS   |
+++
| CentOS Stream 10 (ARM) | PASS   |
+++
| Debian 11 (Buster) (ARM)   | PASS   |
+++
| Ubuntu 20.04 ARM Clang Cross Compile   | PASS   |
+++
| Ubuntu 20.04 aarch32 GCC Cross Compile | PASS   |
+++
| Debian 12 (arm)| PASS   |
+++

 20 line log output for Debian 12 with MUSDK (dpdk_meson_compile): 
[888/1284] Linking static target drivers/libtmp_rte_net_r8169.a [889/1284]
Generating rte_net_r8169.pmd.c with a custom command [890/1284] Compiling C
object drivers/librte_net_r8169.a.p/meson-generated_.._rte_net_r8169.pmd.c.o
[891/1284] Linking static target drivers/librte_net_r8169.a [892/1284]
Compiling C object
drivers/librte_net_r8169.so.25.1.p/meson-generated_.._rte_net_r8169.pmd.c.o
[893/1284] Linking target drivers/librte_net_r8169.so.25.1 [894/1284]
Compiling C object drivers/net/rnp/base/librnp_base.a.p/rnp_mbx.c.o
[895/1284] Compiling C object
drivers/net/rnp/base/librnp_base.a.p/rnp_fw_cmd.c.o
[896/1284] Compiling C object
drivers/net/rnp/base/librnp_base.a.p/rnp_mbx_fw.c.o
FAILED: drivers/net/rnp/base/librnp_base.a.p/rnp_mbx_fw.c.o
ccache aarch64-linux-gnu-gcc -Idrivers/net/rnp/base/librnp_base.a.p
-Idrivers/net/rnp/base -I../drivers/net/rnp/base -I. -I.. -Iconfig
-I../config -Ilib/eal/include -I../lib/eal/include -Ilib/eal/linux/include
-I../lib/eal/linux/include -Ilib/eal/arm/include -I../lib/eal/arm/include
-I../kernel/linux -Ilib/eal/common -I../lib/eal/common -Ilib/eal
-I../lib/eal -Ilib/kvargs -I../lib/kvargs -Ilib/log -I../lib/log
-Ilib/metrics -I../lib/metrics -Ilib/telemetry -I../lib/telemetry -Ilib/net
-I../lib/net -Ilib/mbuf -I../lib/mbuf -Ilib/mempool -I../lib/mempool
-Ilib/ring -I../lib/ring -Ilib/ethdev -I../lib/ethdev -Ilib/meter
-I../lib/meter -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall
-Winvalid-pch -Wextra -Werror -std=c11 -O3 -include rte_config.h -Wvla
-Wcast-qual -Wdeprecated -Wformat -Wformat-nonliteral -Wformat-security
-Wmissing-declarations -Wmissing-prototypes -Wnested-externs
-Wold-style-definition -Wpointer-arith -Wsign-compare -Wstrict-prototypes
-Wundef -Wwrite-st  rings -Wno-packed-not-aligned
-Wno-missing-field-initializers -D_GNU_SOURCE -fPIC -mcpu=cortex-a72
-DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API -Wno-format-truncation
-Wno-address-of-packed-member -DRTE_LIBRTE_IXGBE_BYPASS -Wno-unused-value
-Wno-unused-but-set-variable -Wno-unused-parameter -MD -MQ
drivers/net/rnp/base/librnp_ba

RE: [PATCH v15 09/29] net/rnp: add queue stop and start operations

[11]

Hi Stephen,

I had been not added it to const struct eth_dev_ops  for
.rx/tx_queue_stop/stop :(
Thanks for your check

Regrads Wenbo
> -Original Message-
> From: Stephen Hemminger 
> Sent: 2025年2月26日 0:09
> To: Wenbo Cao 
> Cc: tho...@monjalon.net; dev@dpdk.org; yao...@mucse.com
> Subject: Re: [PATCH v15 09/29] net/rnp: add queue stop and start
operations
> 
> On Tue, 25 Feb 2025 16:41:06 +0800
> Wenbo Cao  wrote:
> 
> > diff --git a/doc/guides/nics/rnp.rst b/doc/guides/nics/rnp.rst index
> > 99b96e9b8e..c3547c38b6 100644
> > --- a/doc/guides/nics/rnp.rst
> > +++ b/doc/guides/nics/rnp.rst
> > @@ -71,6 +71,10 @@ Listed below are the rte_eth functions supported:
> >  * ``rte_eth_dev_close``
> >  * ``rte_eth_dev_stop``
> >  * ``rte_eth_dev_infos_get``
> > +* ``rte_eth_dev_rx_queue_start``
> > +* ``rte_eth_dev_rx_queue_stop``
> > +* ``rte_eth_dev_tx_queue_start``
> > +* ``rte_eth_dev_tx_queue_stop``
> >  * ``rte_eth_promiscuous_disable``
> >  * ``rte_eth_promiscuous_enable``
> >  * ``rte_eth_allmulticast_enable``
> 
> There is no callback in this driver for rx/tx queue start/stop.
> Did you test this with test-pmd?
> 
> If application calls rte_eth_dev_rx_queue_start()
> 
> int
> rte_eth_dev_rx_queue_start(uint16_t port_id, uint16_t rx_queue_id) { ...
>   if (*dev->dev_ops->rx_queue_start == NULL)
>   return -ENOTSUP;
> 
> The eth_dev_ops in rnp_ethdev.c does not contain rx_queue_start!
> 
> /* Features supported by this driver */
> static const struct eth_dev_ops rnp_eth_dev_ops = {
>   .dev_configure= rnp_dev_configure,
>   .dev_close= rnp_dev_close,
>   .dev_start= rnp_dev_start,
>   .dev_stop = rnp_dev_stop,
>   .dev_infos_get= rnp_dev_infos_get,
> 
>   /* PROMISC */
>   .promiscuous_enable   = rnp_promiscuous_enable,
>   .promiscuous_disable  = rnp_promiscuous_disable,
>   .allmulticast_enable  = rnp_allmulticast_enable,
>   .allmulticast_disable = rnp_allmulticast_disable,
>   .mtu_set  = rnp_mtu_set,
>   .rx_queue_setup   = rnp_rx_queue_setup,
>   .rx_queue_release = rnp_dev_rx_queue_release,
>   .tx_queue_setup   = rnp_tx_queue_setup,
>   .tx_queue_release = rnp_dev_tx_queue_release,
>   .rxq_info_get = rnp_rx_queue_info_get,
>   .txq_info_get = rnp_tx_queue_info_get,
>   .rx_burst_mode_get= rnp_rx_burst_mode_get,
>   .tx_burst_mode_get= rnp_tx_burst_mode_get,
>   /* rss impl */
>   .reta_update  = rnp_dev_rss_reta_update,
>   .reta_query   = rnp_dev_rss_reta_query,
>   .rss_hash_update  = rnp_dev_rss_hash_update,
>   .rss_hash_conf_get= rnp_dev_rss_hash_conf_get,
>   /* stats */
>   .stats_get= rnp_dev_stats_get,
>   .stats_reset  = rnp_dev_stats_reset,
>   .xstats_get   = rnp_dev_xstats_get,
>   .xstats_reset = rnp_dev_xstats_reset,
>   .xstats_get_names = rnp_dev_xstats_get_names,
>   /* link impl */
>   .link_update  = rnp_dev_link_update,
>   .dev_set_link_up  = rnp_dev_set_link_up,
>   .dev_set_link_down= rnp_dev_set_link_down,
>   /* mac address filter */
>   .mac_addr_set = rnp_dev_mac_addr_set,
>   .mac_addr_add = rnp_dev_mac_addr_add,
>   .mac_addr_remove  = rnp_dev_mac_addr_remove,
>   .set_mc_addr_list = rnp_dev_set_mc_addr_list,
>   /* vlan offload */
>   .vlan_offload_set = rnp_vlan_offload_set,
>   .vlan_strip_queue_set = rnp_vlan_strip_queue_set,
>   .vlan_filter_set  = rnp_vlan_filter_set,
>   .dev_supported_ptypes_get = rnp_dev_supported_ptypes_get,
> };

RE: [PATCH v16 00/28] [v16]drivers/net Add Support mucse N10 Pmd Driver

[11]

gt;   net/rnp: add support Tx TSO offload
> >   net/rnp: support VLAN offloads
> >   net/rnp: add support VLAN filters operations
> >   net/rnp: add queue info operation
> >   net/rnp: support Rx/Tx burst mode info
> >   net/rnp: add multicast MAC filter operation
> >
> >  .mailmap   |1 +
> >  MAINTAINERS|6 +
> >  doc/guides/nics/features/rnp.ini   |   34 +
> >  doc/guides/nics/img/mucse_nic_port.svg | 4023 
> >  doc/guides/nics/index.rst  |1 +
> >  doc/guides/nics/rnp.rst|  130 +
> >  doc/guides/rel_notes/release_25_03.rst |5 +
> >  drivers/net/meson.build|1 +
> >  drivers/net/rnp/base/meson.build   |   18 +
> >  drivers/net/rnp/base/rnp_bdq_if.c  |  398 +++
> >  drivers/net/rnp/base/rnp_bdq_if.h  |  154 +
> >  drivers/net/rnp/base/rnp_bitrev.h  |   64 +
> >  drivers/net/rnp/base/rnp_common.c  |  103 +
> >  drivers/net/rnp/base/rnp_common.h  |   17 +
> >  drivers/net/rnp/base/rnp_crc32.c   |   53 +
> >  drivers/net/rnp/base/rnp_crc32.h   |   11 +
> >  drivers/net/rnp/base/rnp_dma_regs.h|   68 +
> >  drivers/net/rnp/base/rnp_eth_regs.h|   94 +
> >  drivers/net/rnp/base/rnp_fw_cmd.c  |  162 +
> >  drivers/net/rnp/base/rnp_fw_cmd.h  |  357 +++
> >  drivers/net/rnp/base/rnp_hw.h  |  141 +
> >  drivers/net/rnp/base/rnp_mac.c |  480 +++
> >  drivers/net/rnp/base/rnp_mac.h |   36 +
> >  drivers/net/rnp/base/rnp_mac_regs.h|  210 ++
> >  drivers/net/rnp/base/rnp_mbx.c |  507 +++
> >  drivers/net/rnp/base/rnp_mbx.h |   59 +
> >  drivers/net/rnp/base/rnp_mbx_fw.c  |  495 +++
> >  drivers/net/rnp/base/rnp_mbx_fw.h  |   24 +
> >  drivers/net/rnp/base/rnp_osdep.h   |  176 ++
> >  drivers/net/rnp/meson.build|   27 +
> >  drivers/net/rnp/rnp.h  |  262 ++
> >  drivers/net/rnp/rnp_ethdev.c   | 1868 +++
> >  drivers/net/rnp/rnp_link.c |  436 +++
> >  drivers/net/rnp/rnp_link.h |   52 +
> >  drivers/net/rnp/rnp_logs.h |   36 +
> >  drivers/net/rnp/rnp_rss.c  |  367 +++
> >  drivers/net/rnp/rnp_rss.h  |   44 +
> >  drivers/net/rnp/rnp_rxtx.c | 1822 +++
> >  drivers/net/rnp/rnp_rxtx.h |  162 +
> >  39 files changed, 12904 insertions(+)  create mode 100644
> > doc/guides/nics/features/rnp.ini  create mode 100644
> > doc/guides/nics/img/mucse_nic_port.svg
> >  create mode 100644 doc/guides/nics/rnp.rst  create mode 100644
> > drivers/net/rnp/base/meson.build  create mode 100644
> > drivers/net/rnp/base/rnp_bdq_if.c  create mode 100644
> > drivers/net/rnp/base/rnp_bdq_if.h  create mode 100644
> > drivers/net/rnp/base/rnp_bitrev.h  create mode 100644
> > drivers/net/rnp/base/rnp_common.c  create mode 100644
> > drivers/net/rnp/base/rnp_common.h  create mode 100644
> > drivers/net/rnp/base/rnp_crc32.c  create mode 100644
> > drivers/net/rnp/base/rnp_crc32.h  create mode 100644
> > drivers/net/rnp/base/rnp_dma_regs.h
> >  create mode 100644 drivers/net/rnp/base/rnp_eth_regs.h
> >  create mode 100644 drivers/net/rnp/base/rnp_fw_cmd.c  create mode
> > 100644 drivers/net/rnp/base/rnp_fw_cmd.h  create mode 100644
> > drivers/net/rnp/base/rnp_hw.h  create mode 100644
> > drivers/net/rnp/base/rnp_mac.c  create mode 100644
> > drivers/net/rnp/base/rnp_mac.h  create mode 100644
> > drivers/net/rnp/base/rnp_mac_regs.h
> >  create mode 100644 drivers/net/rnp/base/rnp_mbx.c  create mode 100644
> > drivers/net/rnp/base/rnp_mbx.h  create mode 100644
> > drivers/net/rnp/base/rnp_mbx_fw.c  create mode 100644
> > drivers/net/rnp/base/rnp_mbx_fw.h  create mode 100644
> > drivers/net/rnp/base/rnp_osdep.h  create mode 100644
> > drivers/net/rnp/meson.build  create mode 100644 drivers/net/rnp/rnp.h
> > create mode 100644 drivers/net/rnp/rnp_ethdev.c  create mode 100644
> > drivers/net/rnp/rnp_link.c  create mode 100644
> > drivers/net/rnp/rnp_link.h  create mode 100644
> > drivers/net/rnp/rnp_logs.h  create mode 100644
> > drivers/net/rnp/rnp_rss.c  create mode 100644
> > drivers/net/rnp/rnp_rss.h  create mode 100644
> > drivers/net/rnp/rnp_rxtx.c  create mode 100644
> > drivers/net/rnp/rnp_rxtx.h
> >
> 
> Added this patch series to next-net with a couple of small changes.
>   1. Moved the release note to 25.07
>   2. Replaced rte_memcpy() of process private data in rnp_ethdev.c with
memcpy