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

[Wu, Jingjing]

Hi, Thomas

> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Tuesday, October 28, 2014 12:58 AM
> To: Wu, Jingjing
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v4 04/21] ethdev: define structures for
> adding/deleting flow director
> 
> 2014-10-22 09:01, Jingjing Wu:
> > +/**
> > + * A structure used to define the input for IPV4 UDP flow  */ struct
> > +rte_eth_udpv4_flow {
> > +	uint32_t src_ip;      /**< IPv4 source address to match. */
> > +	uint32_t dst_ip;      /**< IPv4 destination address to match. */
> > +	uint16_t src_port;    /**< UDP Source port to match. */
> > +	uint16_t dst_port;    /**< UDP Destination port to match. */
> > +};
> > +
> > +/**
> > + * A structure used to define the input for IPV4 TCP flow  */ struct
> > +rte_eth_tcpv4_flow {
> > +	uint32_t src_ip;      /**< IPv4 source address to match. */
> > +	uint32_t dst_ip;      /**< IPv4 destination address to match. */
> > +	uint16_t src_port;    /**< TCP Source port to match. */
> > +	uint16_t dst_port;    /**< TCP Destination port to match. */
> > +};
> > +
> > +/**
> > + * A structure used to define the input for IPV4 SCTP flow  */ struct
> > +rte_eth_sctpv4_flow {
> > +	uint32_t src_ip;          /**< IPv4 source address to match. */
> > +	uint32_t dst_ip;          /**< IPv4 destination address to match. */
> > +	uint32_t verify_tag;      /**< verify tag to match */
> > +};
> > +
> > +/**
> > + * A structure used to define the input for IPV4 flow  */ struct
> > +rte_eth_ipv4_flow {
> > +	uint32_t src_ip;      /**< IPv4 source address to match. */
> > +	uint32_t dst_ip;      /**< IPv4 destination address to match. */
> > +};
> 
> Why not defining only 1 structure?
> struct rte_eth_ipv4_flow {
> 	uint32_t src_ip;
> 	uint32_t dst_ip;
> 	uint16_t src_port;
> 	uint16_t dst_port;
> 	uint32_t sctp_tag;
> };
> 
> I think the same structure could be used for many filters (not only flow
> director).
> 
Yes, one structure can contain all the elements we need, but I think it will be clearer that each kind of flow type has its key words.
 
> > +#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.

> > +/**
> > + * A structure used to define the input for an flow director filter
> > +entry
> 
> typo: for *a* flow director
Yes, will change.
> 
> > + */
> > +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.
> > +/**
> > + * 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
> Is FD redundant with FDIR?
Yes, good point. Will remove FD.
> 
> > +/**
> > + * 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. 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.  
> 
> > +	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.
> 
> > +	enum rte_eth_fdir_status report_status;  /**< status report option
> > +*/ };
> 
> > +/**
> > + * 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.
> 
> > +	struct rte_eth_fdir_input input;    /**< input set */
> > +	struct rte_eth_fdir_action action;  /**< action taken when match */
> > +};
> 
> It's really a hard job to define a clear and easy to use API.
> It would be really interesting to have more people involved in this discussion.
Agree too.
Thank you!
> Thanks
> --
> Thomas