netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: Geetha sowjanya <gakula@marvell.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	kuba@kernel.org, davem@davemloft.net, pabeni@redhat.com,
	edumazet@google.com, sgoutham@marvell.com, sbhatta@marvell.com,
	hkelam@marvell.com
Subject: Re: [net-next PATCH v5 05/10] octeontx2-af: Add packet path between representor and VF
Date: Mon, 17 Jun 2024 21:19:37 +0100	[thread overview]
Message-ID: <20240617201937.GB8447@kernel.org> (raw)
In-Reply-To: <20240611162213.22213-6-gakula@marvell.com>

On Tue, Jun 11, 2024 at 09:52:08PM +0530, Geetha sowjanya wrote:
> Current HW, do not support in-built switch which will forward pkts
> between representee and representor. When representor is put under
> a bridge and pkts needs to be sent to representee, then pkts from
> representor are sent on a HW internal loopback channel, which again
> will be punted to ingress pkt parser. Now the rules that this patch
> installs are the MCAM filters/rules which will match against these
> pkts and forward them to representee.
> The rules that this patch installs are for basic
> representor <=> representee path similar to Tun/TAP between VM and
> Host.
> 
> Signed-off-by: Geetha sowjanya <gakula@marvell.com>

Hi Geetha,

Some minor feedback from my side.

...

> diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_rep.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_rep.c
> index cf13c5f0a3c5..e137bb9383a2 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_rep.c
> +++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_rep.c
> @@ -13,6 +13,252 @@
>  #include "rvu.h"
>  #include "rvu_reg.h"
>  
> +static int rvu_rep_get_vlan_id(struct rvu *rvu, u16 pcifunc)
> +{
> +	int id;
> +
> +	for (id = 0; id < rvu->rep_cnt; id++)
> +		if (rvu->rep2pfvf_map[id] == pcifunc)
> +			return id;
> +	return -ENODEV;
> +}

rvu_rep_get_vlan_id() can return an error,
but it is not checked by callers. Should it be?
If not, perhaps rvu_rep_get_vlan_id can return a u16?

> +
> +static int rvu_rep_tx_vlan_cfg(struct rvu *rvu,  u16 pcifunc,
> +			       u16 vlan_tci, int *vidx)
> +{
> +	struct nix_vtag_config_rsp rsp = {};
> +	struct nix_vtag_config req = {};
> +	u64 etype = ETH_P_8021Q;
> +	int err;
> +
> +	/* Insert vlan tag */
> +	req.hdr.pcifunc = pcifunc;
> +	req.vtag_size = VTAGSIZE_T4;
> +	req.cfg_type = 0; /* tx vlan cfg */
> +	req.tx.cfg_vtag0 = true;
> +	req.tx.vtag0 = etype << 48 | ntohs(vlan_tci);

This does not seem correct. vlan_tci is host byte-order,
but ntohs expects a big-endian value as it's argument.

Flagged by Sparse.

> +
> +	err = rvu_mbox_handler_nix_vtag_cfg(rvu, &req, &rsp);
> +	if (err) {
> +		dev_err(rvu->dev, "Tx vlan config failed\n");
> +		return err;
> +	}
> +	*vidx = rsp.vtag0_idx;
> +	return 0;
> +}

...

> +static int rvu_rep_install_rx_rule(struct rvu *rvu, u16 pcifunc,
> +				   u16 entry, bool rte)
> +{
> +	struct npc_install_flow_req req = {};
> +	struct npc_install_flow_rsp rsp = {};
> +	struct rvu_pfvf *pfvf;
> +	u16 vlan_tci, rep_id;
> +
> +	pfvf = rvu_get_pfvf(rvu, pcifunc);
> +
> +	/* To stree the traffic from Representee to Representor */

nit: steer

> +	rep_id = (u16)rvu_rep_get_vlan_id(rvu, pcifunc);

This cast seems unnecessary, or at least inconsistent
with the other call to rvu_rep_get_vlan_id.

> +	if (rte) {
> +		vlan_tci = rep_id | 0x1ull << 8;

ull seems a bit excessive as these are otherwise 16bit values.
And in any case, perhaps BIT(8) can be used here.

> +		req.vf = rvu->rep_pcifunc;
> +		req.op = NIX_RX_ACTIONOP_UCAST;
> +		req.index = rep_id;
> +	} else {
> +		vlan_tci = rep_id;
> +		req.vf = pcifunc;
> +		req.op = NIX_RX_ACTION_DEFAULT;
> +	}
> +
> +	rvu_rep_rx_vlan_cfg(rvu, req.vf);
> +	req.entry = entry;
> +	req.hdr.pcifunc = 0; /* AF is requester */
> +	req.features = BIT_ULL(NPC_OUTER_VID) | BIT_ULL(NPC_VLAN_ETYPE_CTAG);
> +	req.vtag0_valid = true;
> +	req.vtag0_type = NIX_AF_LFX_RX_VTAG_TYPE0;
> +	req.packet.vlan_etype = (__be16)ETH_P_8021Q;
> +	req.mask.vlan_etype = (__be16)ETH_P_8021Q;
> +	req.packet.vlan_tci = (__be16)vlan_tci;
> +	req.mask.vlan_tci = (__be16)0xffff;

0xffff is isomorphic, so this point isn't particularly relevant,
but the 3 casts above that don't look right: these are host-byte
order values, they shouldn't be cast as big-endian..

Also flagged by Sparse.

> +
> +	req.channel = RVU_SWITCH_LBK_CHAN;
> +	req.chan_mask = 0xffff;
> +	req.intf = pfvf->nix_rx_intf;
> +
> +	return rvu_mbox_handler_npc_install_flow(rvu, &req, &rsp);
> +}
> +
> +static int rvu_rep_install_tx_rule(struct rvu *rvu, u16 pcifunc, u16 entry,
> +				   bool rte)
> +{
> +	struct npc_install_flow_req req = {};
> +	struct npc_install_flow_rsp rsp = {};
> +	struct rvu_pfvf *pfvf;
> +	int vidx, err;
> +	u16 vlan_tci;
> +	u8 lbkid;
> +
> +	pfvf = rvu_get_pfvf(rvu, pcifunc);
> +	vlan_tci = rvu_rep_get_vlan_id(rvu, pcifunc);
> +	if (rte)
> +		vlan_tci |= 0x1ull << 8;

BIT(8) seems appropriate here too.

> +
> +	err = rvu_rep_tx_vlan_cfg(rvu, pcifunc, vlan_tci, &vidx);
> +	if (err)
> +		return err;
> +
> +	lbkid = pfvf->nix_blkaddr == BLKADDR_NIX0 ? 0 : 1;
> +	req.hdr.pcifunc = 0; /* AF is requester */
> +	if (rte) {
> +		req.vf = pcifunc;
> +	} else {
> +		req.vf = rvu->rep_pcifunc;
> +		req.packet.sq_id = vlan_tci;
> +		req.mask.sq_id = 0xffff;
> +	}
> +
> +	req.entry = entry;
> +	req.intf = pfvf->nix_tx_intf;
> +	req.op = NIX_TX_ACTIONOP_UCAST_CHAN;
> +	req.index = (lbkid << 8) | RVU_SWITCH_LBK_CHAN;
> +	req.set_cntr = 1;
> +	req.vtag0_def = vidx;
> +	req.vtag0_op = 1;
> +	return rvu_mbox_handler_npc_install_flow(rvu, &req, &rsp);
> +}

...

> diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/rep.c b/drivers/net/ethernet/marvell/octeontx2/nic/rep.c
> index 3cb8dc820fdd..e276a354d9e4 100644

...

> @@ -230,7 +248,7 @@ int rvu_rep_create(struct otx2_nic *priv, struct netlink_ext_ack *extack)
>  	return err;
>  }
>  
> -static int rvu_rep_rsrc_free(struct otx2_nic *priv)
> +static void rvu_rep_rsrc_free(struct otx2_nic *priv)
>  {
>  	struct otx2_qset *qset = &priv->qset;
>  	int wrk;
> @@ -241,13 +259,12 @@ static int rvu_rep_rsrc_free(struct otx2_nic *priv)
>  
>  	otx2_free_hw_resources(priv);
>  	otx2_free_queue_mem(qset);
> -	return 0;
>  }
>  
>  static int rvu_rep_rsrc_init(struct otx2_nic *priv)
>  {
>  	struct otx2_qset *qset = &priv->qset;
> -	int err = 0;
> +	int err;
>  
>  	err = otx2_alloc_queue_mem(priv);
>  	if (err)

The last two hunks don't seem strictly related to the rest of this patch.
Perhaps they belong squashed into earlier patches of this series?

  reply	other threads:[~2024-06-17 20:19 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-11 16:22 [net-next PATCH v5 00/10] Introduce RVU representors Geetha sowjanya
2024-06-11 16:22 ` [net-next PATCH v5 01/10] octeontx2-pf: Refactoring RVU driver Geetha sowjanya
2024-06-15 11:15   ` Markus Elfring
2024-06-18  9:03     ` [EXTERNAL] " Geethasowjanya Akula
2024-06-18  7:40   ` Simon Horman
2024-06-24  9:56     ` Geethasowjanya Akula
2024-06-11 16:22 ` [net-next PATCH v5 02/10] octeontx2-pf: RVU representor driver Geetha sowjanya
2024-06-14  2:02   ` Jakub Kicinski
2024-06-18  9:08     ` [EXTERNAL] " Geethasowjanya Akula
2024-06-15 15:11   ` Markus Elfring
2024-06-17 19:49     ` Simon Horman
2024-06-25 11:58     ` [EXTERNAL] " Geethasowjanya Akula
2024-06-11 16:22 ` [net-next PATCH v5 03/10] octeontx2-pf: Create representor netdev Geetha sowjanya
2024-06-18  8:25   ` Simon Horman
2024-06-24  8:49     ` Geethasowjanya Akula
2024-06-11 16:22 ` [net-next PATCH v5 04/10] octeontx2-pf: Add basic net_device_ops Geetha sowjanya
2024-06-11 16:22 ` [net-next PATCH v5 05/10] octeontx2-af: Add packet path between representor and VF Geetha sowjanya
2024-06-17 20:19   ` Simon Horman [this message]
2024-06-18  8:38   ` Simon Horman
2024-06-19 12:16     ` [EXTERNAL] " Geethasowjanya Akula
2024-06-11 16:22 ` [net-next PATCH v5 06/10] octeontx2-pf: Get VF stats via representor Geetha sowjanya
2024-06-20 12:54   ` Simon Horman
2024-06-20 12:56   ` Simon Horman
2024-06-11 16:22 ` [net-next PATCH v5 07/10] octeontx2-pf: Add support to sync link state between representor and VFs Geetha sowjanya
2024-06-20 12:56   ` Simon Horman
2024-06-11 16:22 ` [net-next PATCH v4 08/10] octeontx2-pf: Configure VF mtu via representor Geetha sowjanya
2024-06-20 12:56   ` Simon Horman
2024-06-11 16:22 ` [net-next PATCH v5 09/10] octeontx2-pf: Add representors for sdp MAC Geetha sowjanya
2024-06-18  8:55   ` Simon Horman
2024-06-11 16:22 ` [net-next PATCH v5 10/10] octeontx2-pf: Add devlink port support Geetha sowjanya
2024-06-20 12:57   ` Simon Horman

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=20240617201937.GB8447@kernel.org \
    --to=horms@kernel.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=gakula@marvell.com \
    --cc=hkelam@marvell.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=sbhatta@marvell.com \
    --cc=sgoutham@marvell.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).