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

  This patch extends struct rte_eth_fdir_flow_ext to support flow
director in VFs.

Signed-off-by: Jingjing Wu <jingjing.wu@intel.com>
---
 doc/guides/rel_notes/deprecation.rst | 4 ----
 doc/guides/rel_notes/release_2_2.rst | 3 +++
 lib/librte_ether/rte_eth_ctrl.h      | 2 ++
 3 files changed, 5 insertions(+), 4 deletions(-)
  

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?
  

Hi, Thomas


> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Sunday, November 1, 2015 10:28 PM
> To: Wu, Jingjing
> Cc: dev@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.

Thanks
Jingjing
  

2015-11-01 14:33, Wu, Jingjing:
> Hi, Thomas
> 
> 
> > -----Original Message-----
> > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > Sent: Sunday, November 1, 2015 10:28 PM
> > To: Wu, Jingjing
> > Cc: dev@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?
  

> 
> 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?

Yes, if VM can configure through rte_eth_dev_filter_ctrl, it will be better.
But flow director can only be programed on PF, and currently there is no such
virtual channel between PF and VF in share code. Due to the principle aligned
with i40e kernel driver develop, we cannot add new virtual channel by ourselves.
So I did it this way on DPDK when DPDK using as PF driver.

Thanks
Jingjing