[dpdk-dev] [PATCH v3 1/3] ethdev: extend struct to support flow director in VFs

[Thomas Monjalon]

2015-11-01 14:33, Wu, Jingjing:
> Hi, Thomas
> 
> 
> > -----Original Message-----
> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > Sent: Sunday, November 1, 2015 10:28 PM
> > To: Wu, Jingjing
> > Cc: dev at dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v3 1/3] ethdev: extend struct to support flow director in VFs
> > 
> > 2015-11-01 00:24, Jingjing Wu:
> > > This patch extends struct rte_eth_fdir_flow_ext to support flow
> > > director in VFs.
> > [...]
> > > --- a/lib/librte_ether/rte_eth_ctrl.h
> > > +++ b/lib/librte_ether/rte_eth_ctrl.h
> > > @@ -426,6 +426,8 @@ struct rte_eth_fdir_flow_ext {
> > >  	uint16_t vlan_tci;
> > >  	uint8_t flexbytes[RTE_ETH_FDIR_MAX_FLEXLEN];
> > >  	/**< It is filled by the flexible payload to match. */
> > > +	uint8_t is_vf;   /**< 1 for VF, 0 for port dev */
> > > +	uint16_t dst_id; /**< VF ID, available when is_vf is 1*/
> > >  };
> > 
> > Why adding these parameters in an input struct?
> > Shouldn't it be in rte_eth_fdir_action along with rx_queue?
> Thanks for your comments. The reason of adding these in input is because this is input but not action.
> The patch is to support Flow director works in VF, then direct packets to the rx_queue (belong this vf) 
> which defined in action, but not direct packets to VF.

Oh!
>From the VM, using
rte_eth_dev_filter_ctrl(port_id, filter_type, filter_op, arg)
it can be deduced from the VF device, no?
Is the use case to define a VF flow director outside of the VM?