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?
