All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.