DPDK patches and discussions
 help / color / mirror / Atom feed
From: "11" <caowenbo@mucse.com>
To: "'Ferruh Yigit'" <ferruh.yigit@amd.com>
Cc: <dev@dpdk.org>, <thomas@monjalon.net>,
	<andrew.rybchenko@oktetlabs.ru>, <yaojun@mucse.com>,
	"'Stephen Hemminger'" <stephen@networkplumber.org>
Subject: RE: [PATCH v6 4/8] net/rnp: add mbx basic api feature
Date: Wed, 6 Sep 2023 18:32:07 +0800	[thread overview]
Message-ID: <643DA378097977FE+013601d9e0ad$6387d2b0$2a977810$@mucse.com> (raw)
In-Reply-To: <4ab252f9-56d1-b9c1-1dd2-50ad1d97f4b7@amd.com>

Hi Ferruh,

Please see the below comment :)

Regards Wenbo

> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@amd.com>
> Sent: 2023年9月5日 23:45
> To: Wenbo Cao <caowenbo@mucse.com>
> Cc: dev@dpdk.org; thomas@monjalon.net; andrew.rybchenko@oktetlabs.ru;
> yaojun@mucse.com; Stephen Hemminger <stephen@networkplumber.org>
> 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 <caowenbo@mucse.com>
> > Suggested-by: Stephen Hemminger <stephen@networkplumber.org>
> > ---
> >  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
> > 0000000000..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 @@
> >   */
> >  #ifndef __RNP_H__
> >  #define __RNP_H__
> > +#include <rte_log.h>
> >
> >  #include "base/rnp_hw.h"
> >
> > @@ -14,14 +15,17 @@
> >
> >  struct rnp_eth_port {
> >  	struct rnp_eth_adapter *adapt;
> > +	struct rnp_hw *hw;
> 
> adapter already has the 'hw', is there a specific reason not to access it via 'port-
> >adapt->hw'
> 
> >  	struct rte_eth_dev *eth_dev;
> >  } __rte_cache_aligned;
> >
> >  struct rnp_share_ops {
> > +	const struct rnp_mbx_api *mbx_api;
> >  } __rte_cache_aligned;
> >
> >  struct rnp_eth_adapter {
> >  	struct rnp_hw hw;
> > +	uint16_t max_vfs;
> >  	struct rte_pci_device *pdev;
> >  	struct rte_eth_dev *eth_dev; /* primary eth_dev */
> >  	struct rnp_eth_port *ports[RNP_MAX_PORT_OF_PF]; @@ -34,5 +38,36
> @@
> > struct rnp_eth_adapter {
> >  	(((struct rnp_eth_port *)((eth_dev)->data->dev_private)))
> >  #define RNP_DEV_TO_ADAPTER(eth_dev) \
> >  	((struct rnp_eth_adapter *)(RNP_DEV_TO_PORT(eth_dev)->adapt))
> > +#define RNP_DEV_TO_HW(eth_dev) \
> > +	(&((struct rnp_eth_adapter
> > +*)(RNP_DEV_TO_PORT((eth_dev))->adapt))->hw)
> > +#define RNP_DEV_PP_PRIV_TO_MBX_OPS(dev) \
> > +	(((struct rnp_share_ops *)(dev)->process_private)->mbx_api)
> > +#define RNP_DEV_TO_MBX_OPS(dev)	RNP_DEV_PP_PRIV_TO_MBX_OPS(dev)
> >
> > +static inline void rnp_reg_offset_init(struct rnp_hw *hw) {
> > +	uint16_t i;
> > +
> > +	if (hw->device_id == RNP_DEV_ID_N10G && hw->mbx.pf_num) {
> > +		hw->iobar4 = (void *)((uint8_t *)hw->iobar4 + 0x100000);
> > +		hw->msix_base = (void *)((uint8_t *)hw->iobar4 + 0xa4000);
> > +		hw->msix_base = (void *)((uint8_t *)hw->msix_base + 0x200);
> > +	} else {
> > +		hw->msix_base = (void *)((uint8_t *)hw->iobar4 + 0xa4000);
> > +	}
> > +	/* === dma status/config====== */
> > +	hw->link_sync = (void *)((uint8_t *)hw->iobar4 + 0x000c);
> > +	hw->dma_axi_en = (void *)((uint8_t *)hw->iobar4 + 0x0010);
> > +	hw->dma_axi_st = (void *)((uint8_t *)hw->iobar4 + 0x0014);
> > +
> > +	if (hw->mbx.pf_num)
> > +		hw->msix_base = (void *)((uint8_t *)0x200);
> > +	/* === queue registers === */
> > +	hw->dma_base = (void *)((uint8_t *)hw->iobar4 + 0x08000);
> > +	hw->veb_base = (void *)((uint8_t *)hw->iobar4 + 0x0);
> > +	hw->eth_base = (void *)((uint8_t *)hw->iobar4 + 0x10000);
> 
> There are lots of hardcoded values in this function, can you make them macros?
> 
Yes, I can change it to macros.
> > +	/* mac */
> > +	for (i = 0; i < RNP_MAX_HW_PORT_PERR_PF; i++)
> > +		hw->mac_base[i] = (void *)((uint8_t *)hw->iobar4 + 0x60000 +
> > +0x10000 * i); }
> >  #endif /* __RNP_H__ */
> > diff --git a/drivers/net/rnp/rnp_ethdev.c
> > b/drivers/net/rnp/rnp_ethdev.c index ae737643a7..a2dc27548a 100644
> > --- a/drivers/net/rnp/rnp_ethdev.c
> > +++ b/drivers/net/rnp/rnp_ethdev.c
> > @@ -8,6 +8,7 @@
> >  #include <ethdev_driver.h>
> >
> >  #include "rnp.h"
> > +#include "rnp_mbx.h"
> >  #include "rnp_logs.h"
> >
> >  static int
> > @@ -89,6 +90,58 @@ rnp_alloc_eth_port(struct rte_pci_device *primary_pci,
> char *name)
> >  	return NULL;
> >  }
> >
> > +static void rnp_get_nic_attr(struct rnp_eth_adapter *adapter) {
> > +	RTE_SET_USED(adapter);
> > +}
> > +
> > +static int
> > +rnp_process_resource_init(struct rte_eth_dev *eth_dev) {
> > +	struct rnp_share_ops *share_priv;
> > +
> > +	/* allocate process_private memory this must can't
> > +	 * belone to the dpdk mem resource manager
> > +	 * such as from rte_malloc or rte_dma_zone..
> > +	 */
> > +	/* use the process_prive point to resolve secondary process
> > +	 * use point-func. This point is per process will be safe to cover.
> > +	 * This will cause secondary process core-dump because of IPC
> > +	 * Secondary will call primary process point func virt-address
> > +	 * secondary process don't alloc user/pmd to alloc or free
> > +	 * the memory of dpdk-mem resource it will cause hugepage
> > +	 * mem exception
> > +	 * be careful for secondary Process to use the share-mem of
> > +	 * point correlation
> > +	 */
> 
> As commented above, I am not sure why you need this, it should be sufficient to
> have mac_ops in primary proccess.
> 
This is because of supporting 
 .promiscuous_enable
 .promiscuous_disable
 .allmulticast_enable
 .allmulticast_disable
 .fw_version_get
In the secondary process
> > +	share_priv = calloc(1, sizeof(*share_priv));
> > +	if (!share_priv) {
> > +		PMD_DRV_LOG(ERR, "calloc share_priv failed");
> > +		return -ENOMEM;
> > +	}
> > +	memset(share_priv, 0, sizeof(*share_priv));
> > +	eth_dev->process_private = share_priv;
> > +
> > +	return 0;
> > +}
> > +
> > +static void
> > +rnp_common_ops_init(struct rnp_eth_adapter *adapter) {
> > +	struct rnp_share_ops *share_priv;
> > +
> > +	share_priv = adapter->share_priv;
> > +	share_priv->mbx_api = &rnp_mbx_pf_ops; }
> > +
> > +static int
> > +rnp_special_ops_init(struct rte_eth_dev *eth_dev) {
> > +	RTE_SET_USED(eth_dev);
> > +
> > +	return 0;
> > +}
> > +
> >  static int
> >  rnp_eth_dev_init(struct rte_eth_dev *dev)  { @@ -124,6 +177,20 @@
> > rnp_eth_dev_init(struct rte_eth_dev *dev)
> >  	hw->device_id = pci_dev->id.device_id;
> >  	hw->vendor_id = pci_dev->id.vendor_id;
> >  	hw->device_id = pci_dev->id.device_id;
> > +	adapter->max_vfs = pci_dev->max_vfs;
> > +	ret = rnp_process_resource_init(dev);
> > +	if (ret) {
> > +		PMD_DRV_LOG(ERR, "share prive resource init failed");
> > +		return ret;
> > +	}
> > +	adapter->share_priv = dev->process_private;
> 
> Isn't 'adapter' shared betwen primary and secondary ('port' is dev_private and
> 'port->adapt' is 'adapter'), so updating "adapter->share_priv" defeats the
> purpose of process_private, no?
> 
Yes just process private.
dev->process_private; this dev is alloc by 'rte_eth_dev_pci_generic_probe'
So we must record the first port dev->process_private,
when the secondary port of the same PF, alloc by rnp_alloc_eth_port 
we can use lase record info 'adapter->share_priv' turn to
'dev->process_private' (alloc by rnp_alloc_eth_port).
> > +	rnp_common_ops_init(adapter);
> > +	rnp_get_nic_attr(adapter);
> > +	/* We need Use Device Id To Change The Resource Mode */
> > +	rnp_special_ops_init(dev);
> >
> 
> You can add this when it is needed, so in same patch we can see where it is
> called and how it is implemented, right now it is not possible that what 'special'
> init does.
> 
> 
Yes,  it is used to for multiple-port mode and one pcie-bdf select api.
For now, I can remove the code for one pcie-bdf-one-port mode.
> > +	port->adapt = adapter;
> > +	port->hw = hw;
> 
> At this stage port is NULL, probably above needs to go to other patch that sets
> 'port'.
> 
Port(dev_private) is get from the first port (bdf) alloc by rte_eth_dev_pci_generic_probe
> > +	rnp_init_mbx_ops_pf(hw);
> >  	for (p_id = 0; p_id < adapter->num_ports; p_id++) {
> >  		/* port 0 resource has been allocated When Probe */
> >  		if (!p_id) {
> > @@ -158,11 +225,10 @@ rnp_eth_dev_init(struct rte_eth_dev *dev)
> >  			continue;
> >  		if (port->eth_dev) {
> >  			rnp_dev_close(port->eth_dev);
> > -			rte_eth_dev_release_port(port->eth_dev);
> >  			if (port->eth_dev->process_private)
> >  				free(port->eth_dev->process_private);
> > +			rte_eth_dev_release_port(port->eth_dev);
> >  		}
> > -		rte_free(port);
> >  	}
> >  	rte_free(adapter);
> >
> > diff --git a/drivers/net/rnp/rnp_logs.h b/drivers/net/rnp/rnp_logs.h
> > index 1b3ee33745..f1648aabb5 100644
> > --- a/drivers/net/rnp/rnp_logs.h
> > +++ b/drivers/net/rnp/rnp_logs.h
> > @@ -13,6 +13,15 @@ extern int rnp_drv_logtype;  #define
> > RNP_PMD_DRV_LOG(level, fmt, args...) \
> >  	rte_log(RTE_LOG_##level, rnp_drv_logtype, \
> >  		"%s() " fmt, __func__, ##args)
> > +#define PMD_DRV_LOG_RAW(level, fmt, args...) \
> > +	rte_log(RTE_LOG_ ## level, rnp_drv_logtype, "%s(): " fmt, \
> > +			__func__, ## args)
> > +#define PMD_DRV_LOG(level, fmt, args...) \
> > +	PMD_DRV_LOG_RAW(level, fmt "\n", ## args)
> > +
> > +#define RNP_PMD_LOG(level, fmt, args...) \
> > +	rte_log(RTE_LOG_##level, rnp_drv_logtype, \
> > +			"rnp_net: (%d) " fmt, __LINE__, ##args)
> 
> With these there are three different macros used to log in 'rnp_drv_logtype' type:
> 
> RNP_PMD_LOG
> PMD_DRV_LOG
> RNP_PMD_DRV_LOG
> 
> 'RNP_PMD_DRV_LOG' and 'PMD_DRV_LOG' looks exact same, do you need all
> these macros, why not stick to one?
> 
> PMD_DRV_LOG
This need to  remove it.
> If more than one required, can you please comment what is used for what, and
> perhaps rename macros in a way that it is clear which one to use where (as I
> assume one is specific to base files).
> 
> <...>
> 
Thanks a lot, I will add comment for the macros before it.
> > +/**
> > + *  rnp_write_mbx_pf - Places a message in the mailbox
> > + *  @hw: pointer to the HW structure
> > + *  @msg: The message buffer
> > + *  @size: Length of buffer
> > + *  @mbx_id: the VF index
> > + *
> > + *  returns SUCCESS if it successfully copied message into the buffer
> > +**/ static int32_t rnp_write_mbx_pf(struct rnp_hw *hw, u32 *msg,
> > +				u16 size, enum MBX_ID mbx_id)
> > +{
> > +	u32 DATA_REG = (mbx_id == MBX_CM3CPU) ?
> > +		CPU_PF_SHM_DATA : PF_VF_SHM_DATA(mbx_id);
> > +	u32 CTRL_REG = (mbx_id == MBX_CM3CPU) ?
> > +		PF2CPU_MBOX_CTRL : PF2VF_MBOX_CTRL(mbx_id);
> > +	int32_t ret_val = 0;
> > +	u32 stat __rte_unused;
> > +	u16 i;
> > +
> > +	if (size > RNP_VFMAILBOX_SIZE) {
> > +		RNP_PMD_LOG(ERR, "%s: size:%d should <%d\n", __func__,
> > +				size, RNP_VFMAILBOX_SIZE);
> > +		return -EINVAL;
> > +	}
> > +
> > +	/* lock the mailbox to prevent pf/vf/cpu race condition */
> > +	ret_val = rnp_obtain_mbx_lock_pf(hw, mbx_id);
> > +	if (ret_val) {
> > +		RNP_PMD_LOG(WARNING, "PF[%d] Can't Get Mbx-Lock Try
> Again\n",
> > +				hw->function);
> > +		return ret_val;
> > +	}
> > +
> > +	/* copy the caller specified message to the mailbox memory buffer */
> > +	for (i = 0; i < size; i++) {
> > +#ifdef MBX_WR_DEBUG
> > +		mbx_pwr32(hw, DATA_REG + i * 4, msg[i]); #else
> > +		mbx_wr32(hw, DATA_REG + i * 4, msg[i]); #endif
> 
> Who sets this define, if not used please remove it.
> 
This need to remove 😊.



  reply	other threads:[~2023-09-06 10:32 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
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 [this message]
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='643DA378097977FE+013601d9e0ad$6387d2b0$2a977810$@mucse.com' \
    --to=caowenbo@mucse.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@amd.com \
    --cc=stephen@networkplumber.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).