Re: [dpdk-dev] [RFC v2 1/2] ethdev: add packet filter flow and new behavior switch to fdir

[Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>]

Hi Jingjing,

On Thursday, January 01/14/16, 2016 at 00:48:17 -0800, Wu, Jingjing wrote:
> Hi, Rahul
> 
> Just another thought, please consider about it:
> 
> Add a new flow type like
> 
> #define RTE_ETH_FLOW_IPV6_UDP_EX        17
> +#define RTE_ETH_FLOW_RAW_PKT             18
> 
> Then add a new item in rte_eth_fdir_flow
> union rte_eth_fdir_flow {
> 	struct rte_eth_l2_flow     l2_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   ipv6_flow;
> 	struct rte_eth_mac_vlan_flow mac_vlan_flow;
> 	struct rte_eth_tunnel_flow   tunnel_flow;
> +	uint8_t raw_pkt[80];
> };
> 
> Then add mask item in rte_eth_fdir_input:
> 
> struct rte_eth_fdir_input {
> 	uint16_t flow_type;
> 	union rte_eth_fdir_flow flow;
> +	union rte_eth_fdir_flow flow_mask;
> 	/**< Flow fields to match, dependent on flow_type */
> 	struct rte_eth_fdir_flow_ext flow_ext;
> 	/**< Additional fields to match */
> };
> 
> Then the filter can be added just in a format of raw packet, it looks generic, and even other NIC can use this too.
> 
> Thanks
> Jingjing

This approach seems generic enough to allow any vendor specific data
to be passed in filter as well.  However, 80 seems to be too low for
multiple flow types that can be combined in the same filter rule.
I think size of 256 seems reasonable.

Could the same thing be done for action arguments as well? Can we add
the same generic info to rte_eth_fdir_action too?

struct rte_eth_fdir_action {
        uint16_t rx_queue;
	enum rte_eth_fdir_behavior behavior;
	enum rte_eth_fdir_status report_status;
	uint8_t flex_off;
+       uint8_t behavior_arg[256];
};

This way, we can pass vendor specific action arguments too. What do
you think?

Also, now if we take this approach then, I am wondering, that all
vendors would need to document their own vendor-specific format of
taking filter match and filter action arguments, right?

And probably, even come up with their own example application showing
how to apply filters via dpdk on their card?

Thanks,
Rahul