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

[Thomas Monjalon <thomas.monjalon-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>]

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).

> +#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.

> +/**
> + * A structure used to define the input for an flow director filter entry

typo: for *a* flow director

> + */
> +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 ?

> +/**
> + * 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.
Is FD redundant with FDIR?

> +/**
> + * 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"?

> +	uint8_t  drop;            /**< accept or reject */
> +	uint8_t  flex_off;        /**< offset used define words to report */

still difficult to understand the flex logic

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

> +	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.
Thanks
-- 
Thomas