[dpdk-dev] [PATCH 1/3] fm10k: update VLAN filter

He, Shaopeng shaopeng.he at intel.com
Wed Jun 10 07:52:51 CEST 2015


> -----Original Message-----
> From: Qiu, Michael
> Sent: Tuesday, June 09, 2015 11:52 PM
> To: He, Shaopeng; dev at dpdk.org
> Cc: Chen, Jing D
> Subject: Re: [PATCH 1/3] fm10k: update VLAN filter
> 
> On 2015/6/2 10:59, He, Shaopeng wrote:
> > VLAN filter was updated to add/delete one static entry in MAC table
> > for each combination of VLAN and MAC address. More sanity checks were
> added.
> >
> > Signed-off-by: Shaopeng He <shaopeng.he at intel.com>
> > ---
> >  drivers/net/fm10k/fm10k.h        | 23 +++++++++++++++++
> >  drivers/net/fm10k/fm10k_ethdev.c | 55
> > +++++++++++++++++++++++++++++++++++++---
> >  2 files changed, 75 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/net/fm10k/fm10k.h b/drivers/net/fm10k/fm10k.h
> > index ad7a7d1..3b95b72 100644
> > --- a/drivers/net/fm10k/fm10k.h
> > +++ b/drivers/net/fm10k/fm10k.h
> > @@ -109,11 +109,31 @@
> >
> >  #define FM10K_VLAN_TAG_SIZE 4
> >
> > +/* Maximum number of MAC addresses per PF/VF */
> > +#define FM10K_MAX_MACADDR_NUM       1
> > +
> > +#define FM10K_UINT32_BIT_SIZE      (CHAR_BIT * sizeof(uint32_t))
> > +#define FM10K_VFTA_SIZE            (4096 / FM10K_UINT32_BIT_SIZE)
> > +
> > +/* vlan_id is a 12 bit number.
> > + * The VFTA array is actually a 4096 bit array, 128 of 32bit elements.
> > + * 2^5 = 32. The val of lower 5 bits specifies the bit in the 32bit element.
> > + * The higher 7 bit val specifies VFTA array index.
> > + */
> > +#define FM10K_VFTA_BIT(vlan_id)    (1 << ((vlan_id) & 0x1F))
> > +#define FM10K_VFTA_IDX(vlan_id)    ((vlan_id) >> 5)
> > +
> > +struct fm10k_macvlan_filter_info {
> > +	uint16_t vlan_num;       /* Total VLAN number */
> > +	uint32_t vfta[FM10K_VFTA_SIZE];        /* VLAN bitmap */
> > +};
> > +
> >  struct fm10k_dev_info {
> >  	volatile uint32_t enable;
> >  	volatile uint32_t glort;
> >  	/* Protect the mailbox to avoid race condition */
> >  	rte_spinlock_t    mbx_lock;
> > +	struct fm10k_macvlan_filter_info    macvlan;
> >  };
> >
> >  /*
> > @@ -137,6 +157,9 @@ struct fm10k_adapter {  #define
> > FM10K_DEV_PRIVATE_TO_MBXLOCK(adapter) \
> >  	(&(((struct fm10k_adapter *)adapter)->info.mbx_lock))
> >
> > +#define FM10K_DEV_PRIVATE_TO_MACVLAN(adapter) \
> > +		(&(((struct fm10k_adapter *)adapter)->info.macvlan))
> > +
> >  struct fm10k_rx_queue {
> >  	struct rte_mempool *mp;
> >  	struct rte_mbuf **sw_ring;
> > diff --git a/drivers/net/fm10k/fm10k_ethdev.c
> > b/drivers/net/fm10k/fm10k_ethdev.c
> > index 3a26480..d2f3e44 100644
> > --- a/drivers/net/fm10k/fm10k_ethdev.c
> > +++ b/drivers/net/fm10k/fm10k_ethdev.c
> > @@ -819,15 +819,61 @@ fm10k_dev_infos_get(struct rte_eth_dev *dev,
> > static int  fm10k_vlan_filter_set(struct rte_eth_dev *dev, uint16_t
> > vlan_id, int on)  {
> > -	struct fm10k_hw *hw = FM10K_DEV_PRIVATE_TO_HW(dev->data-
> >dev_private);
> > +	s32 result;
> > +	uint32_t vid_idx, vid_bit, mac_index;
> > +	struct fm10k_hw *hw;
> > +	struct fm10k_macvlan_filter_info *macvlan;
> > +	struct rte_eth_dev_data *data = dev->data;
> >
> > -	PMD_INIT_FUNC_TRACE();
> > +	hw = FM10K_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> > +	macvlan = FM10K_DEV_PRIVATE_TO_MACVLAN(dev->data-
> >dev_private);
> >
> >  	/* @todo - add support for the VF */
> >  	if (hw->mac.type != fm10k_mac_pf)
> >  		return -ENOTSUP;
> >
> > -	return fm10k_update_vlan(hw, vlan_id, 0, on);
> > +	if (vlan_id > ETH_VLAN_ID_MAX) {
> > +		PMD_INIT_LOG(ERR, "Invalid vlan_id: must be < 4096");
> > +		return (-EINVAL);
> > +	}
> > +
> > +	vid_idx = FM10K_VFTA_IDX(vlan_id);
> > +	vid_bit = FM10K_VFTA_BIT(vlan_id);
> > +	/* this VLAN ID is already in the VLAN filter table, return SUCCESS */
> > +	if (on && (macvlan->vfta[vid_idx] & vid_bit))
> > +		return 0;
> > +	/* this VLAN ID is NOT in the VLAN filter table, cannot remove */
> > +	if (!on && !(macvlan->vfta[vid_idx] & vid_bit)) {
> > +		PMD_INIT_LOG(ERR, "Invalid vlan_id: not existing "
> > +			"in the VLAN filter table");
> > +		return (-EINVAL);
> > +	}
> > +
> > +	fm10k_mbx_lock(hw);
> > +	result = fm10k_update_vlan(hw, vlan_id, 0, on);
> 
> Would it make sense about release the lock here? So that to make sure we
> do not hold this lock for a long time.
Agree, make sense, thanks for the suggestion!


More information about the dev mailing list