Re: [dpdk-dev] [PATCH v4 04/21] ethdev: define structures for adding/deleting flow director

[Thomas Monjalon <thomas.monjalon@6wind.com>]

2014-10-28 01:18, Wu, Jingjing:
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > 2014-10-22 09:01, Jingjing Wu:
> > > +#define RTE_ETH_FDIR_MAX_FLEXWORD_LEN  8
> > > +/**
> > > + * A structure used to contain extend input of flow  */ struct
> > > +rte_eth_fdir_flow_ext {
> > > +	uint16_t vlan_tci;
> > > +	uint8_t num_flexwords;         /**< number of flexwords */
> > > +	uint16_t flexwords[RTE_ETH_FDIR_MAX_FLEXWORD_LEN];
> > > +	uint16_t dest_id;              /**< destination vsi or pool id*/
> > > +};
> > 
> > Flexword should be explained.
> > 
> The flexword means the application can choose a part of packet's payload
> as key words to compare match. It is flexible.
> In Ixgbe, the flexwords is 1 word (2 bytes), while Fortville extend it to 8 words.

OK. The problem is that I don't know how to fill the flexwords bytes.
You should explain it in the doxygen comment.
You say it's flexible. Is it usable with a non-IP packet?
Please explain constraints and syntax.

> > > +struct rte_eth_fdir_input {
> > > +	enum rte_eth_flow_type flow_type;      /**< type of flow */
> > > +	union rte_eth_fdir_flow flow;          /**< specific flow structure */
> > > +	struct rte_eth_fdir_flow_ext flow_ext; /**< specific flow info */ };
> > 
> > I don't understand the logic behind flow/flow_ext.
> > Why flow_ext is not merged into flow ?
> > 
> The flow defines the key words for each flow_type, while the flow_ext
> has other elements which have little to do with flow_type.
> For example the flexword, dst_id (can used as pool id), I think it is not
> reasonable to make it as an element in the flow.

Sorry, I don't understand.
flow and flow_ext are associated with a flow type.
The comments are "specific flow structure" and "specific flow info" which
doesn't bring any useful information.

> > > +/**
> > > + * Flow director report status
> > > + */
> > > +enum rte_eth_fdir_status {
> > > +	RTE_ETH_FDIR_NO_REPORT_STATUS = 0, /**< no report FDIR. */
> > > +	RTE_ETH_FDIR_REPORT_FD_ID,         /**< only report FD ID. */
> > > +	RTE_ETH_FDIR_REPORT_FD_ID_FLEX_4,  /**< report FD ID and 4 flex bytes. */
> > > +	RTE_ETH_FDIR_REPORT_FLEX_8,        /**< report 8 flex bytes. */
> > > +};
> > 
> > The names and explanations are cryptics.
> 
> The enum defines what will be reported when FIR match.
> Can be FD_ID or flex bytes

Just to be sure, have you understood that I'm requesting more explanations
in the comments to allow users of your API to understand it?

> > > +/**
> > > + * A structure used to define an action when match FDIR packet filter.
> > > + */
> > > +struct rte_eth_fdir_action {
> > > +	uint16_t rx_queue;        /**< queue assigned to if fdir match. */
> > > +	uint16_t cnt_idx;         /**< statistic counter index */
> > 
> > what is the action of "statistic counter index"?
> 
> When FD match happened, the counter will increase.

Which counter?
Which value should be set in cnt_idx?

> Fortville can support to configure the different counter for filter entries.
> The action is a part of a filter entry, so this element means which counter the entry will use.

I perfectly understand that you are writing some code to allow usage of
Fortville features through DPDK. Thank you for bringing new features.
But I want to know if I'm allowed to use it without reading the Fortville datasheet?
And could this API be shared by other hardwares (e.g. ixgbe)?

> > > +	uint8_t  drop;            /**< accept or reject */
> > > +	uint8_t  flex_off;        /**< offset used define words to report */
> > 
> > still difficult to understand the flex logic
> 
> Just as mentioned above, Fortville can support 8 flex words comparing.
> But for reporting, only 4 or 8 bytes in the flex words can be reported.
> So need to specify the offset to choose the 4 or 8 bytes.

I don't even know what are the meaning of these 4 or 8 bytes.
Please don't consider that every DPDK user know the Fortville datasheet.

> > > +/**
> > > + * A structure used to define the flow director filter entry by
> > > +filter_ctl API
> > > + * to support RTE_ETH_FILTER_FDIR with RTE_ETH_FILTER_ADD and
> > > + * RTE_ETH_FILTER_DELETE operations.
> > > + */
> > > +struct rte_eth_fdir_filter {
> > > +	uint32_t soft_id;                   /**< id */
> > 
> > Should the application handle the id numbering?
> > Why is it soft_id instead of id?
> 
> Yes, the soft_id is just id, is also reported id when entry match.
> The id is specified by user, and can be used to identify this entry,
> application should handle it.

OK, so explain it in comments.
Or better, generate and return the id when creating a filter.

Thanks
-- 
Thomas