Hi Jingjing,
On Thursday, January 01/14/16, 2016 at 17:30:53 -0800, Wu, Jingjing wrote:
> Hi, Rahul
>
> > 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.
> > 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.
> > 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
