linux-kernel - Re: [net-next PATCH v5 05/10] octeontx2-af: Add packet path between representor and VF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 18 Jun 2024 09:38:39 +0100
From: Simon Horman <horms@...nel.org>
To: Geetha sowjanya <gakula@...vell.com>
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org, kuba@...nel.org,
	davem@...emloft.net, pabeni@...hat.com, edumazet@...gle.com,
	sgoutham@...vell.com, sbhatta@...vell.com, hkelam@...vell.com
Subject: Re: [net-next PATCH v5 05/10] octeontx2-af: Add packet path between
 representor and VF

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@...vell.com>

...

> diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_rep.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_rep.c

...

> +void rvu_rep_update_rules(struct rvu *rvu, u16 pcifunc, bool ena)
> +{
> +	struct rvu_switch *rswitch = &rvu->rswitch;
> +	struct npc_mcam *mcam = &rvu->hw->mcam;
> +	u32 max = rswitch->used_entries;
> +	int blkaddr;
> +	u16 entry;
> +
> +	if (!rswitch->used_entries)
> +		return;
> +
> +	blkaddr = rvu_get_blkaddr(rvu, BLKTYPE_NPC, 0);
> +
> +	if (blkaddr < 0)
> +		return;
> +
> +	rvu_switch_enable_lbk_link(rvu, pcifunc, ena);
> +	mutex_lock(&mcam->lock);
> +	for (entry = 0; entry < max; entry++) {
> +		if (rswitch->entry2pcifunc[entry] == pcifunc)
> +			npc_enable_mcam_entry(rvu, mcam, blkaddr, entry, ena);
> +	}
> +	mutex_unlock(&mcam->lock);
> +}
> +
> +int rvu_rep_pf_init(struct rvu *rvu)
> +{
> +	u16 pcifunc = rvu->rep_pcifunc;
> +	struct rvu_pfvf *pfvf = rvu_get_pfvf(rvu, pcifunc);

nit: It would be nice to maintain reverse xmas tree order - longest line to
     shortest - for local variable declarations in this file.

     Here, I think that could be (completely untested!):

	u16 pcifunc = rvu->rep_pcifunc;
	struct rvu_pfvf *pfvf;

	pfvf = rvu_get_pfvf(rvu, pcifunc);

     Edward Cree's tool is useful here:
     https://github.com/ecree-solarflare/xmastree

> +
> +	set_bit(NIXLF_INITIALIZED, &pfvf->flags);
> +	rvu_switch_enable_lbk_link(rvu, pcifunc, true);
> +	rvu_rep_rx_vlan_cfg(rvu, pcifunc);
> +	return 0;
> +}

...