mbox series

[net-next,0/3] octeontx2-af: Introduce DMAC based switching

Message ID 1626685174-4766-1-git-send-email-sbhatta@marvell.com
Headers show
Series octeontx2-af: Introduce DMAC based switching | expand

Message

Subbaraya Sundeep July 19, 2021, 8:59 a.m. UTC 
With this patch set packets can be switched between
all CGX mapped PFs and VFs in the system based on
the DMAC addresses. To implement this:
AF allocates high priority rules from top entry(0) in MCAM.
Rules are allocated for all the CGX mapped PFs and VFs though
they are not active and with no NIXLFs attached.
Rules for a PF/VF will be enabled only after they are brought up.
Two rules one for TX and one for RX are allocated for each PF/VF.

A packet sent from a PF/VF with a destination mac of another
PF/VF will be hit by TX rule and sent to LBK channel 63. The
same returned packet will be hit by RX rule whose action is
to forward packet to PF/VF with that destination mac.

Implementation of this for 98xx is tricky since there are
two NIX blocks and till now a PF/VF can install rule for
an NIX0/1 interface only if it is mapped to corresponding NIX0/1 block.
Hence Tx rules are modified such that TX interface in MCAM
entry can be either NIX0-TX or NIX1-TX.

Testing:

1. Create two VFs over PF1(on NIX0) and assign two VFs to two VMs
2. Assign ip addresses to two VFs in VMs and PF2(on NIX1) in host.
3. Assign static arp entries in two VMs and PF2.
4. Ping between VMs and host PF2.


Thanks,
Sundeep


Subbaraya Sundeep (3):
  octeontx2-af: Enable transmit side LBK link
  octeontx2-af: Prepare for allocating MCAM rules for AF
  octeontx2-af: Introduce internal packet switching

 drivers/net/ethernet/marvell/octeontx2/af/Makefile |   2 +-
 drivers/net/ethernet/marvell/octeontx2/af/rvu.c    |  10 +-
 drivers/net/ethernet/marvell/octeontx2/af/rvu.h    |  21 ++
 .../net/ethernet/marvell/octeontx2/af/rvu_cgx.c    |   3 +
 .../ethernet/marvell/octeontx2/af/rvu_debugfs.c    |   5 +-
 .../ethernet/marvell/octeontx2/af/rvu_devlink.c    |  48 +++-
 .../net/ethernet/marvell/octeontx2/af/rvu_nix.c    |  36 +++
 .../net/ethernet/marvell/octeontx2/af/rvu_npc.c    |  47 +++-
 .../net/ethernet/marvell/octeontx2/af/rvu_npc_fs.c |  29 ++-
 .../net/ethernet/marvell/octeontx2/af/rvu_switch.c | 258 +++++++++++++++++++++
 10 files changed, 427 insertions(+), 32 deletions(-)
 create mode 100644 drivers/net/ethernet/marvell/octeontx2/af/rvu_switch.c

Comments

Jakub Kicinski July 20, 2021, 11:51 a.m. UTC | #1 
On Mon, 19 Jul 2021 14:29:34 +0530, Subbaraya Sundeep wrote:
> +static int rvu_devlink_eswitch_mode_set(struct devlink *devlink, u16 mode,

> +					struct netlink_ext_ack *extack)

> +{

> +	struct rvu_devlink *rvu_dl = devlink_priv(devlink);

> +	struct rvu *rvu = rvu_dl->rvu;

> +	struct rvu_switch *rswitch;

> +

> +	rswitch = &rvu->rswitch;

> +	switch (mode) {

> +	case DEVLINK_ESWITCH_MODE_LEGACY:

> +	case DEVLINK_ESWITCH_MODE_SWITCHDEV:

> +		if (rswitch->mode == mode)

> +			return 0;

> +		rswitch->mode = mode;

> +		if (mode == DEVLINK_ESWITCH_MODE_SWITCHDEV)

> +			rvu_switch_enable(rvu);

> +		else

> +			rvu_switch_disable(rvu);


I don't see the code handle creation and tearing down of representors.

How do things work in this driver? Does AF have a representor netdev
for each VF (that's separate from the VF netdev itself)? Those should
only exist in switchdev mode, while legacy mode should use DMAC
switching.

I think what you want is a textbook VEPA vs VEB switch. Please take a
look at drivers implementing .ndo_bridge_getlink/.ndo_bridge_setlink.
sundeep subbaraya July 20, 2021, 5:56 p.m. UTC | #2 
Hi Jakub,

On Tue, Jul 20, 2021 at 5:26 PM Jakub Kicinski <kuba@kernel.org> wrote:
>

> On Mon, 19 Jul 2021 14:29:34 +0530, Subbaraya Sundeep wrote:

> > +static int rvu_devlink_eswitch_mode_set(struct devlink *devlink, u16 mode,

> > +                                     struct netlink_ext_ack *extack)

> > +{

> > +     struct rvu_devlink *rvu_dl = devlink_priv(devlink);

> > +     struct rvu *rvu = rvu_dl->rvu;

> > +     struct rvu_switch *rswitch;

> > +

> > +     rswitch = &rvu->rswitch;

> > +     switch (mode) {

> > +     case DEVLINK_ESWITCH_MODE_LEGACY:

> > +     case DEVLINK_ESWITCH_MODE_SWITCHDEV:

> > +             if (rswitch->mode == mode)

> > +                     return 0;

> > +             rswitch->mode = mode;

> > +             if (mode == DEVLINK_ESWITCH_MODE_SWITCHDEV)

> > +                     rvu_switch_enable(rvu);

> > +             else

> > +                     rvu_switch_disable(rvu);

>

> I don't see the code handle creation and tearing down of representors.

>

> How do things work in this driver? Does AF have a representor netdev

> for each VF (that's separate from the VF netdev itself)? Those should

> only exist in switchdev mode, while legacy mode should use DMAC

> switching.

>

> I think what you want is a textbook VEPA vs VEB switch. Please take a

> look at drivers implementing .ndo_bridge_getlink/.ndo_bridge_setlink.


MCAM used for switching is present in AF and AF is not a netdev to
use ndo_bridge_setlink. Currently VF->VF/ PF->VF switching is possible
only with an external switch in hairpin mode (like VEPA), what we want to
achieve is switching based on DMAC in MCAM itself(internally).
We used DEVLINK_ESWITCH_MODE_SWITCHDEV as a trigger to
allocate MCAM rules. I understand now that it can be used to create
VF representors only. Can you please suggest any appropriate devlink
command we can use here so that new rules are created. Having these
rules by default will waste MCAM space.

Thanks,
Sundeep