Hi, Andrey

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.

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?

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.

Thanks
Jingjing  

-----Original Message-----
From: Chilikin, Andrey
Sent: Thursday, January 21, 2016 4:05 AM
To: Wu, Jingjing; dev@dpdk.org
Cc: Zhang, Helin; Pei, Yulong; Ananyev, Konstantin
Subject: RE: [PATCH 2/4] i40e: split function for input set change of hash and
fdir

Hi Jingjing,

As I can see this patch not only splits fdir functionality from common
fdir/hash code but also removes compatibility with DPDK 2.2 as it deletes
I40E_INSET_FLEX_PAYLOAD from valid fdir input set values. Yes, flexible
payload configuration can be set for fdir separately at the port initialization,
but this is more legacy from the previous generations of NICs which did not
support dynamic input set configuration. I believe it would better to have
I40E_INSET_FLEX_PAYLOAD valid for fdir input set same as in DPDK 2.2. So in
legacy mode, when application has to run on an old NIC and on a new one,
only legacy configuration would be used, but for applications targeting new
HW single point of configuration would be used instead of mix of two.

Regards,
Andrey