Re: [net-next PATCH 3/3] octeontx2-af: Introduce internal packet switching

Hi Jakub,

On Tue, Jul 20, 2021 at 5:26 PM Jakub Kicinski [off-list ref] wrote:

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

quoted

+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