[Intel-wired-lan] [PATCH net-next 07/12] ice: setting and releasing switchdev environment

Nguyen, Anthony L anthony.l.nguyen at intel.com
Tue Jun 22 15:14:58 UTC 2021


On Mon, 2021-06-21 at 21:18 -0400, Michal Swiatkowski wrote:
> On Mon, Jun 21, 2021 at 08:35:35PM -0400, Michal Swiatkowski wrote:
> > On Mon, Jun 21, 2021 at 06:21:15PM +0000, Nguyen, Anthony L wrote:
> > > On Fri, 2021-06-18 at 01:44 +0200, Michal Swiatkowski wrote:
> > > > From: Grzegorz Nitka <grzegorz.nitka at intel.com>
> > > > 
> > > > Switchdev environment has to be set up when user create VFs
> > > > and eswitch mode is switchdev. Release is done when user
> > > > delete all VFs.
> > > > 
> > > > Data path in this implementation is based on control plane VSI.
> > > > This VSI is used to pass traffic from port representors to
> > > > coresponfing VFs and vice versa. Default TX rule has to be
> > > > added to forward packet to control plane VSI. This will
> > > > redirect
> > > > packets from VFs which don't match other rules to control plane
> > > > VSI.
> > > > 
> > > > On RX site default rule is added on uplink VSI to receive all
> > > > traffic that doesn't match other rules. When setting switchdev
> > > > environment all other rules from VFs should be removed. Packet
> > > > to
> > > > VFs will be forwarded by control plane VSI.
> > > > 
> > > > As VF without any mac rules can't send any packet because of
> > > > antispoof mechanism, VSI antispoof should be turned off on each
> > > > VFs.
> > > > 
> > > > To send packet from representor to correct VSI, destintion VSI
> > > > field in TX descriptor will have to be filled. Allow that by
> > > > setting destination override bit in control plane VSI security
> > > > config.
> > > > 
> > > > Packet from VFs will be received on control plane VSI. Driver
> > > > should decide to which netdev forward the packet. Decision is
> > > > made based on src_vsi field from descriptor. There is a target
> > > > netdev list in control plane VSI struct which choose netdev
> > > > based on src_vsi number.
> > > > 
> > > > Co-developed-by: Michal Swiatkowski <
> > > > michal.swiatkowski at linux.intel.com>
> > > > Signed-off-by: Michal Swiatkowski <
> > > > michal.swiatkowski at linux.intel.com
> > > > Signed-off-by: Grzegorz Nitka <grzegorz.nitka at intel.com>
> > > > ---
> > > 
> > > <snip>
> > > 
> > > > +/**
> > > > + * ice_eswitch_vsi_setup - configure switchdev control VSI
> > > > + * @pf: pointer to PF structure
> > > > + * @pi: pointer to port_info structure
> > > > + */
> > > > +static struct ice_vsi *
> > > > +ice_eswitch_vsi_setup(struct ice_pf *pf, struct ice_port_info
> > > > *pi)
> > > > +{
> > > > +	return ice_vsi_setup(pf, pi, ICE_VSI_SWITCHDEV_CTRL,
> > > > ICE_INVAL_VFID);
> > > 
> > > This doesn't build; the switchdev VSI doesn't get introduced
> > > until the
> > > next patch. 
> > > 
> > 
> > Sorry, I missed that, will fix it in next version.
> > 
> 
> This patchset is already on your dev-queue branch, what should I do
> in
> this case? You will reveret this, or I should send fixed version
> without
> applying it on top of the dev-queue?

I forgot to drop the patches from dev-queue. Everything should be clear
now.

> 
> > > drivers/net/ethernet/intel/ice/ice_eswitch.c: In function
> > > ice_eswitch_vsi_setup:
> > > drivers/net/ethernet/intel/ice/ice_eswitch.c:263:31: error:
> > > ICE_VSI_SWITCHDEV_CTRL undeclared (first use in this function)
> > >   263 |  return ice_vsi_setup(pf, pi, ICE_VSI_SWITCHDEV_CTRL,
> > > ICE_INVAL_VFID);
> > >       |                               ^~~~~~~~~~~~~~~~~~~~~~
> > > drivers/net/ethernet/intel/ice/ice_eswitch.c:263:31: note: each
> > > undeclared identifier is reported only once for each function it
> > > appears in
> > > drivers/net/ethernet/intel/ice/ice_eswitch.c:264:1: error:
> > > control
> > > reaches end of non-void function [-Werror=return-type]
> > >   264 | }
> > > 
> > _______________________________________________
> > Intel-wired-lan mailing list
> > Intel-wired-lan at osuosl.org
> > https://lists.osuosl.org/mailman/listinfo/intel-wired-lan


More information about the Intel-wired-lan mailing list