diff mbox

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

Message ID 1413939687-11177-5-git-send-email-jingjing.wu@intel.com (mailing list archive)
State Changes Requested, archived
Headers show

Commit Message

Jingjing Wu Oct. 22, 2014, 1:01 a.m. UTC
define structures to add or delete flow director filter

Signed-off-by: Jingjing Wu <jingjing.wu@intel.com>
---
 lib/librte_ether/rte_eth_ctrl.h | 160 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 160 insertions(+)

Comments

Thomas Monjalon Oct. 27, 2014, 4:57 p.m. UTC | #1
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
Jingjing Wu Oct. 28, 2014, 1:18 a.m. UTC | #2
Hi, Thomas

> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Tuesday, October 28, 2014 12:58 AM
> To: Wu, Jingjing
> Cc: dev@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
Thomas Monjalon Oct. 28, 2014, 1:17 p.m. UTC | #3
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
Jingjing Wu Oct. 29, 2014, 1:29 a.m. UTC | #4
Hi, Thomas

Thanks for your comments.

Jingjing

> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Tuesday, October 28, 2014 9:18 PM
> To: Wu, Jingjing
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v4 04/21] ethdev: define structures for
> adding/deleting flow director
> 
> 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.
> 
OK. Will add more explanations in comments.

> > > > +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.
Take an example like: flow_type is IPV4, and the key words in IP is supposed
to be dst_ip and src_ip. Other fields like dst_id has little to do with IPV4.

> The comments are "specific flow structure" and "specific flow info" which
> doesn't bring any useful information.
> 
OK, I think I need to change the comments.

> > > > +/**
> > > > + * 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?
>
OK, get 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?
> 
A hardware counter provided in Fortville. It supposed that the user know about
the hardware, or just set to 0 if don't specify a counter, a default counter will be
used for all entries. I will add more comments. 

> > 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?
Yes, you can. But for same extended functions, need more explanation.
You are correct, I need to add more explanation.

> And could this API be shared by other hardwares (e.g. ixgbe)?
Yes, I also considered about it during design. And the integrating ixgbe's flow 
director to the API is ready. I plan to send another patch for it when 
this patch set is applied.

> 
> > > > +	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.
Additional, these 4 or 8 bytes are a part of the 8 flex words.
> Please don't consider that every DPDK user know the Fortville datasheet.
OK. More comments.
> 
> > > > +/**
> > > > + * 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.
OK.
> Or better, generate and return the id when creating a filter.
> 
> Thanks
> --
> Thomas
diff mbox

Patch

diff --git a/lib/librte_ether/rte_eth_ctrl.h b/lib/librte_ether/rte_eth_ctrl.h
index df21ac6..3efdaae 100644
--- a/lib/librte_ether/rte_eth_ctrl.h
+++ b/lib/librte_ether/rte_eth_ctrl.h
@@ -51,6 +51,7 @@  extern "C" {
  */
 enum rte_filter_type {
 	RTE_ETH_FILTER_NONE = 0,
+	RTE_ETH_FILTER_FDIR,
 	RTE_ETH_FILTER_MAX
 };
 
@@ -71,6 +72,165 @@  enum rte_filter_op {
 	RTE_ETH_FILTER_OP_MAX
 };
 
+/**
+ * Define all structures for Flow Director Filter type corresponding with specific operations.
+ */
+
+/**
+ * flow type
+ */
+enum rte_eth_flow_type {
+	RTE_ETH_FLOW_TYPE_NONE = 0x0,
+	RTE_ETH_FLOW_TYPE_UDPV4,
+	RTE_ETH_FLOW_TYPE_TCPV4,
+	RTE_ETH_FLOW_TYPE_SCTPV4,
+	RTE_ETH_FLOW_TYPE_IPV4_OTHER,
+	RTE_ETH_FLOW_TYPE_UDPV6,
+	RTE_ETH_FLOW_TYPE_TCPV6,
+	RTE_ETH_FLOW_TYPE_SCTPV6,
+	RTE_ETH_FLOW_TYPE_IPV6_OTHER,
+};
+
+/**
+ * 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. */
+};
+
+/**
+ * A structure used to define the input for IPV6 UDP flow
+ */
+struct rte_eth_udpv6_flow {
+	uint32_t src_ip[4];      /**< IPv6 source address to match. */
+	uint32_t dst_ip[4];      /**< IPv6 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 IPV6 TCP flow
+ */
+struct rte_eth_tcpv6_flow {
+	uint32_t src_ip[4];      /**< IPv6 source address to match. */
+	uint32_t dst_ip[4];      /**< IPv6 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 IPV6 SCTP flow
+ */
+struct rte_eth_sctpv6_flow {
+	uint32_t src_ip[4];      /**< IPv6 source address to match. */
+	uint32_t dst_ip[4];      /**< IPv6 destination address to match. */
+	uint32_t verify_tag;     /**< verify tag to match */
+};
+
+/**
+ * A structure used to define the input for IPV6 flow
+ */
+struct rte_eth_ipv6_flow {
+	uint32_t src_ip[4];      /**< IPv6 source address to match. */
+	uint32_t dst_ip[4];      /**< IPv6 destination address to match. */
+};
+
+/**
+ * An union contains the inputs for all types of flow
+ */
+union rte_eth_fdir_flow {
+	struct rte_eth_udpv4_flow  udp4_flow;
+	struct rte_eth_tcpv4_flow  tcp4_flow;
+	struct rte_eth_sctpv4_flow sctp4_flow;
+	struct rte_eth_ipv4_flow   ip4_flow;
+	struct rte_eth_udpv6_flow  udp6_flow;
+	struct rte_eth_tcpv6_flow  tcp6_flow;
+	struct rte_eth_sctpv6_flow sctp6_flow;
+	struct rte_eth_ipv6_flow   ip6_flow;
+};
+
+#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*/
+};
+
+/**
+ * A structure used to define the input for an flow director filter entry
+ */
+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 */
+};
+
+/**
+ * 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. */
+};
+
+/**
+ * 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 */
+	uint8_t  drop;            /**< accept or reject */
+	uint8_t  flex_off;        /**< offset used define words to report */
+	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 */
+	struct rte_eth_fdir_input input;    /**< input set */
+	struct rte_eth_fdir_action action;  /**< action taken when match */
+};
+
 #ifdef __cplusplus
 }
 #endif