Hi Jingjing,

On Thursday, January 01/14/16, 2016 at 17:30:53 -0800, Wu, Jingjing wrote:

Hi, Rahul

quoted

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.

Yes, 80 is just an example. 

quoted

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?

Yes, it also makes sense.

quoted

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?

Yes, I guess it will be better to doc it or example it. Even currently, different kinds of NIC may need different configuration.
Or you can add description (how to configure) in your driver's comment log?
Not sure about the others' opinion?

Thanks
Jingjing

Ok.  We will wait for a couple of days to get more opinions from others.
If the above generic approach is agreeable to everyone, then I will post
the patch series using this new approach.

Thanks,
Rahul