On Tue, 19-07-16, 18:41, Ferruh Yigit wrote: > On 7/10/2019 11:43 AM, Xiaoyu Min wrote: > > This patch intend to support > > action_raw_encap/decap [1] in a generic and convenient way. > > > > Two new commands - set raw_encap, set raw_decap are introduced just > > like the other commands for encap/decap, i.e. set vxlan. > > > > These two commands have corresponding global buffers > > which can be used by PMD as the input buffer for raw encap/decap. > > > > The commands use the rte_flow pattern syntax to help user build the > > raw buffer in a convenient way. > > > > A common way to use it: > > > > - encap matched egress packet with VxLAN tunnel: > > testpmd> set raw_encap eth src is 10:11:22:33:44:55 / vlan tci is 1 > > inner_type is 0x0800 / ipv4 / udp dst is 4789 / vxlan vni > > is 2 / end_set > > testpmd> flow create 0 egress pattern eth / ipv4 / end actions > > raw_encap / end > > > > - decap l2 header and encap GRE tunnel on matched egress packet: > > testpmd> set raw_decap eth / end_set > > testpmd> set raw_encap eth dst is 10:22:33:44:55:66 / ipv4 / gre > > protocol is 0x0800 / end_set > > testpmd> flow create 0 egress pattern eth / ipv4 / end actions > > raw_decap / raw_encap / end > > > > - decap VxLAN tunnel and encap l2 header on matched ingress packet: > > testpmd> set raw_encap eth src is 10:11:22:33:44:55 type is 0x0800 / > > end_set > > testpmd> set raw_decap eth / ipv4 / udp / vxlan / end_set > > testpmd> flow create 0 ingress pattern eth / ipv4 / udp dst is 250 / > > vxlan vni is 0x1234 / ipv4 / end actions raw_decap / > > raw_encap / queue index 1 / mark id 0x1234 / end > > > > [1] > > https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmails.dpdk.org%2Farchives%2Fdev%2F2018-October%2F116092.html&data=02%7C01%7Cjackmin%40mellanox.com%7C70ecd953302c47ac8c6a08d70a14dd70%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636988957053156948&sdata=jbpk3oPLW8XQcS1aUxESwVkqaGzzumRObaFwh2%2BAxbA%3D&reserved=0 > > > > Signed-off-by: Xiaoyu Min <jack...@mellanox.com> > > --- > > app/test-pmd/cmdline.c | 7 + > > app/test-pmd/cmdline_flow.c | 535 +++++++++++++++++++- > > app/test-pmd/testpmd.h | 2 + > > doc/guides/testpmd_app_ug/testpmd_funcs.rst | 48 ++ > > 4 files changed, 591 insertions(+), 1 deletion(-) > > > > diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c > > index 01dd45f27c..69c5d9e8f6 100644 > > --- a/app/test-pmd/cmdline.c > > +++ b/app/test-pmd/cmdline.c > > @@ -760,6 +760,12 @@ static void cmd_help_long_parsed(void *parsed_result, > > " eth-src (eth-src) eth-dst (eth-dst)\n" > > " Configure the NVGRE encapsulation for > > flows.\n\n" > > > > + "raw_encap {flow items}" > > + " Configure the encapsulation with raw data.\n\n" > > + > > + "raw_decap {flow items}" > > + " Configure the decapsulation with raw data.\n\n" > > + > > , list_pkt_forwarding_modes() > > ); > > } > > I think the exact command is "set raw_encap {flow items}" && "set raw_decap > {flow items}", Yes, this is the exact one. I'll update it.
> also can you please move them "filters" section, from current > "config" section? Sorry, I don't understand. Why "set raw_encap/ set raw_decap" should belong to the "filter" setion? I think these commands are as same as "set vxlan"s which are listed in "config" section. Should we, at least, align with them? Or I miss something? > > Overall these dynamic commands nice from user perspective, thanks to Adrien, > but > the amount of code it brings and complexity a little worries me for long > term... +1 >
