[dpdk-dev] [PATCH 2/4] i40e: split function for input set change of hash and fdir
jingjing.wu at intel.com
Tue Jan 26 02:12:49 CET 2016
> > Thanks for your comments. You are correct, I removed the
> > I40E_INSET_FLEX_PAYLOAD from valid fdir input set values, and this is
> > one reason why I splited function for input set change of hash and and
> > it is because all flex payload configuration can be set in struct
> > rte_fdir_conf during device configure phase. And it is a more flexible
> > configuration including flexpayload's selection, input set selection by word
> and mask setting in bits.
> Should it be then two patches? First patch to split fdir and hash input set
> configuration and then second one to remove existing functionality? At the
> moment it is not obvious that this patch not just splits fdir input set
> configuration but removes some features in a way that fdir it is not
> compatible with DPDK 2.2 anymore.
OK. I will try to split it to two patches.
> > If I enable it in the input set change API, it will be duplicate. And
> > the input set change on flexible payload only on word, just some
> > ability compared with rte_fdir_conf.
> > If flexible selection isn't done in struct rte_fdir_conf, the input
> > set selection in input set change API doesn't make sense. If flexible
> > selection is done in struct rte_fdir_conf, why not selection input set
> > in struct rte_fdir_conf at the same time?
> I do not have a problem with selecting it at the same time - it always was this
> way with the legacy systems. But now new NIC supports new way of
> configuring input set with flexible payload as a part of this input set. So why
> not to have new way of configuration available as well and change input set
> using one API call instead of splitting single configuration in to two parts?
Yes, if we support two way, at least we need to make sure the consistency.
In this patch set, I didn't add new way to configure flexible selection and mask
Setting. So to make sure consistency, just remove the flexible payload in this
> > And about you concern, "when application has to run on an old NIC and
> > on a new one", The rte_fdir_conf is for each eth_dev, so it will be fine.
More information about the dev