On Wed, 19-07-03, 17:25, Adrien Mazarguil wrote: > On Tue, Jul 02, 2019 at 05:45:55PM +0800, Xiaoyu Min wrote: > > support matching on GRE key and present bits (C,K,S) > > > > example testpmd command could be: > > testpmd>flow create 0 ingress group 1 pattern eth / ipv4 / > > gre crksv is 0x2000 crksv mask 0xb000 / > > gre_key key is 0x12345678 / end > > actions rss queues 1 0 end / mark id 196 / end > > > > Which will match GRE packet with k present bit set and key value is > > 0x12345678. > > > > Signed-off-by: Xiaoyu Min <jack...@mellanox.com> > > I'm wondering... Is matching the K bit mandatory if one explicitly matches > gre_key already or is this a specific hardware limitation in your case? >
If there is gre_key item MLX5 PMD will force set HW matching on K bit, >From HW perspective it is mandatory. But, from testpmd (user) perspective, I agree with you, user needn't set matching on K bit if they already explicitly set gre_key item. > Perhaps we could document that the K bit is implicitly matched as "1" in the > default mask when a gre_key pattern item is present. If a user explicitly Yes, I should document this. So it should be documented in __testpmd_funcs.rst__ ? > spec/mask K as "0" and still provides gre_key, the PMD can safely ignore the > gre_key item. > Well, actullay, when a user explicitly set spec/mask K as "0" and still provide gre_key item, MLX5 PMD will implicitly set match on K bit as "1", just ingore the K bit set by user. The reason is wanna keep code simple, needn't to get information from other item (gre) inside gre_key item, or vice verse. And, I think, when a user provides a gre_key item, most probably, they do really wanna match on gre_key. What do you think? > I'm asking because I think most users won't bother with the K bit when > attempting to match some key and their rules may not behave as expected as a > result. > I see. > More below. > > > --- > > ** This patch is based on patch [1] > > > > [1] > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatches.dpdk.org%2Fpatch%2F55773%2F&data=02%7C01%7Cjackmin%40mellanox.com%7C590e61b809bb42869cf508d6ffcaa82c%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636977643198683579&sdata=LhTsrHRfX3LHhiHRBtz4WKUUklWupJueSBgWmiHPECM%3D&reserved=0 > > --- > > app/test-pmd/cmdline_flow.c | 32 +++++++++++++++++++++ > > doc/guides/testpmd_app_ug/testpmd_funcs.rst | 4 +++ > > 2 files changed, 36 insertions(+) > > > > diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c > > index 201bd9de56..8504cc8bc1 100644 > > --- a/app/test-pmd/cmdline_flow.c > > +++ b/app/test-pmd/cmdline_flow.c > > @@ -148,6 +148,9 @@ enum index { > > ITEM_MPLS_LABEL, > > ITEM_GRE, > > ITEM_GRE_PROTO, > > + ITEM_GRE_CRKSV, > > + ITEM_GRE_KEY, > > + ITEM_GRE_KEY_KEY, > > Assuming you move the GRE_KEY definition in rte_flow.h, please keep its > location synchronized in this list as well. > I'll do this. > > ITEM_FUZZY, > > ITEM_FUZZY_THRESH, > > ITEM_GTP, > > @@ -595,6 +598,7 @@ static const enum index next_item[] = { > > ITEM_NVGRE, > > ITEM_MPLS, > > ITEM_GRE, > > + ITEM_GRE_KEY, > > ITEM_FUZZY, > > ITEM_GTP, > > ITEM_GTPC, > > @@ -755,6 +759,13 @@ static const enum index item_mpls[] = { > > > > static const enum index item_gre[] = { > > ITEM_GRE_PROTO, > > + ITEM_GRE_CRKSV, > > CRKSV may be unnecessary in this patch if the K bit is documented and > implemented as described in my previous comment. > Well, actully, we also wanna testpmd can match on C,S bits with K bit together so we can test on gre packet with key only or csum + key, or csum + key + sequence. > > + ITEM_NEXT, > > + ZERO, > > +}; > > + > > +static const enum index item_gre_key[] = { > > + ITEM_GRE_KEY_KEY, > > ITEM_NEXT, > > ZERO, > > }; > > @@ -1898,6 +1909,27 @@ static const struct token token_list[] = { > > .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_gre, > > protocol)), > > }, > > + [ITEM_GRE_CRKSV] = { > > + .name = "crksv", > > + .help = "GRE's first word (bit0 - bit15)", > > + .next = NEXT(item_gre, NEXT_ENTRY(UNSIGNED), item_param), > > + .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_gre, > > + c_rsvd0_ver)), > > + }, > > + [ITEM_GRE_KEY] = { > > + .name = "gre_key", > > + .help = "match GRE Key", > > + .priv = PRIV_ITEM(GRE_KEY, > > + sizeof(rte_be32_t)), > > Could be a single line. > Yes, I'll update it. > > + .next = NEXT(item_gre_key), > > + .call = parse_vc, > > + }, > > + [ITEM_GRE_KEY_KEY] = { > > + .name = "key", > > + .help = "GRE key", > > + .next = NEXT(item_gre_key, NEXT_ENTRY(UNSIGNED), item_param), > > + .args = ARGS(ARG_ENTRY_HTON(rte_be32_t)), > > + }, > > [ITEM_FUZZY] = { > > .name = "fuzzy", > > .help = "fuzzy pattern match, expect faster than default", > > diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst > > b/doc/guides/testpmd_app_ug/testpmd_funcs.rst > > index cb83a3ce8a..fc3ba8a009 100644 > > --- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst > > +++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst > > @@ -3804,6 +3804,10 @@ This section lists supported pattern items and their > > attributes, if any. > > > > - ``protocol {unsigned}``: protocol type. > > > > +- ``gre_key``: match GRE optional key field. > > + > > + - ``key {unsigned}``: key value. > > + > > You should have named this field "value" then, i.e.: > > - ``value {unsigned}``: key value. > OK, I'll update it. > > - ``fuzzy``: fuzzy pattern match, expect faster than default. > > > > - ``thresh {unsigned}``: accuracy threshold. > > -- > > 2.21.0 > > > > -- > Adrien Mazarguil > 6WIND
