Hi Slava, Thanks for your response back and letting me know the limitation.
I tried to input flow you suggested. But it returns error. testpmd> flow create 0 ingress group 1 priority 0 pattern eth dst is 00:16:3e:2e:7b:6a / vlan vid is 1480 / end actions of_pop_vlan / queue index 0 / end Caught error type 3 (group field): groups is not supported: Operation not supported Note that my setup OFED is NOT 4.7.1.0.0.2, but 4.7.1.0.0.1 because that is the latest version which I can download from the following web site. https://jp.mellanox.com/page/products_dyn?product_family=26&ssn=u44h3rn8ngcmbdl6v0fvhqrgt3 Do you have any hints? BR, Hideyuki Yamashita NTT TechnoCross > Hi, Hideyuki. > > Thanks for providing extra information. > > We rechecked the VLAN actions support in OFED 4.7.1, it should be supported. > There are some limitations: > - VLAN pop is supported on ingress direction only > - VLAN push is supported on egress direction only > - not supported in group 0 (this is root table, has some limitations) > we should insert into group 0 flow with jump to group 1, and then insert > the rule with VLAN actions to group 1 > > I tried this flow (on my setup OFED 4.7.1.0.0.2): > > flow create 0 ingress group 1 priority 0 pattern eth dst is 00:16:3e:2e:7b:6a > / vlan vid is 1480 / end actions of_pop_vlan / queue index 0 / end > It was created successfully. > > With best regards, Slava > > > -----Original Message----- > > From: Hideyuki Yamashita <yamashita.hidey...@ntt-tx.co.jp> > > Sent: Friday, October 25, 2019 7:49 > > To: Slava Ovsiienko <viachesl...@mellanox.com> > > Cc: Moti Haimovsky <mo...@mellanox.com>; dev@dpdk.org > > Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on > > VLAN header > > > > Hello Slava, > > > > Thanks for your response back. > > > > While waiting your final response, > > I am sending additional info from my side. > > > > 1 > > I am using "MLNX_OFED_LINUX-4.7-1.0.0.1-ubuntu18.04-x86_64" > > as OFED. > > > > tx_h-yamashita@R730n10:~/dpdk-next-net$ pwd /home/tx_h- > > yamashita/dpdk-next-net > > tx_h-yamashita@R730n10:~/dpdk-next-net$ ls > > app MAINTAINERS > > buildtools Makefile > > config meson.build > > devtools meson_options.txt > > doc mk > > drivers MLNX_OFED_LINUX-4.7-1.0.0.1-ubuntu18.04-x86_64 > > examples MLNX_OFED_LINUX-4.7-1.0.0.1-ubuntu18.04-x86_64.tgz > > GNUmakefile README > > kernel usertools > > lib VERSION > > license x86_64-native-linuxapp-gcc > > > > 2. > > I am using ConnextX-4 and ConnectX-5. > > I attach the result of typing ethtool -i . > > > > Bus info Device Class Description > > ========================================================== > > pci@0000:03:00.0 enp3s0f0 network MT27710 Family [ConnectX-4 > > Lx] > > pci@0000:03:00.1 enp3s0f1 network MT27710 Family [ConnectX-4 > > Lx] > > pci@0000:04:00.0 enp4s0f0 network MT27800 Family [ConnectX-5] > > pci@0000:04:00.1 enp4s0f1 network MT27800 Family [ConnectX-5] > > > > tx_h-yamashita@R730n10:~/dpdk-next-net$ ethtool -i enp3s0f0 > > driver: mlx5_core > > version: 4.7-1.0.0 > > firmware-version: 14.25.1020 (MT_0000000266) > > expansion-rom-version: > > bus-info: 0000:03:00.0 > > supports-statistics: yes > > supports-test: yes > > supports-eeprom-access: no > > supports-register-dump: no > > supports-priv-flags: yes > > tx_h-yamashita@R730n10:~/dpdk-next-net$ ethtool -i enp4s0f0 > > driver: mlx5_core > > version: 4.7-1.0.0 > > firmware-version: 16.25.6000 (MT_0000000012) > > expansion-rom-version: > > bus-info: 0000:04:00.0 > > supports-statistics: yes > > supports-test: yes > > supports-eeprom-access: no > > supports-register-dump: no > > supports-priv-flags: yes > > > > If you needs more info from my side, please let me know. > > > > BR, > > Hideyuki Yamashita > > NTT TechnoCross > > > > > Hi, Hideyuki > > > > > > > -----Original Message----- > > > > From: Hideyuki Yamashita <yamashita.hidey...@ntt-tx.co.jp> > > > > Sent: Monday, October 21, 2019 10:12 > > > > To: Hideyuki Yamashita <yamashita.hidey...@ntt-tx.co.jp> > > > > Cc: Slava Ovsiienko <viachesl...@mellanox.com>; Moti Haimovsky > > > > <mo...@mellanox.com>; dev@dpdk.org > > > > Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow > > > > action on VLAN header > > > > > > > > Dear Slava, Moti and all, > > > > > > > > Please let me know if you need more information. > > > > Partial answer is acceptable for me. > > > > > > > > Thanks in advaince! > > > > > > I'm sorry for delay, your issue is still in progress. > > > I've tested your rules on my standard configuration - these ones are > > > rejected by FW/SW, not by DPDK code. Moti tested the flows on custom > > setup (I suppose experimental FW/kernel). > > > AFAIK, VLAN feature was planned to GA with OFED 4.7.1, please, let me > > > check it (hope in few days, there are holidays still lasting in IL). > > > > > > With best regards, Slava > > > > > > > > BR, > > > > HIdeyuki Yamashita > > > > NTT TechnoCross > > > > > > > > > Dear Slava and experts, > > > > > > > > > > Thanks for your answering me. > > > > > Baased on your answer, I tested using testpmd. > > > > > And about the outcome, I have several questions. > > > > > > > > > > > > > > > [1.Test environment] > > > > > OS:Ubuntu18.04 > > > > > NIC1:MCX4121A-ACAT 25G > > > > > NIC2:MCX516A-CCAT 100G > > > > > Repo:dpdk-next-net > > > > > > > > > > I checked that the following is shown in git log command. > > > > > 9f1e94469 net/mlx5: fix netlink rdma socket callback routine > > > > > 50735012c > > > > > net/mlx5: support reading module EEPROM data > > > > > f53a5f917 net/mlx5: support modify VLAN ID on existing VLAN header > > > > > 9af8046a1 net/mlx5: support modify VLAN ID on new VLAN header > > > > > 43184603e net/mlx5: support modifying VLAN priority on VLAN header > > > > > 4f59ffbd8 net/mlx5: support push flow action on VLAN header > > > > > b4bd8f5da > > > > > net/mlx5: support pop flow action on VLAN header 048e3e84c > > net/mlx5: > > > > > add VLAN push/pop DR commands to glue > > > > > > > > > > [2.Test result] > > > > > I tested the follwoing flows with testpmd included in dpdk-next-net. > > > > > > > > > > A.flow create 0 ingress pattern eth / vlan id is 100 / end actions > > > > > OF_POP_VLAN / end B.flow create 0 ingress pattern eth dst is > > > > > BB:BB:BB:BB:BB:BB / end actions OF_PUSH_VLAN ethertype 1000 / end > > > > > C.flow create 0 ingress pattern eth dst is BB:BB:BB:BB:BB:BB / end > > > > > actions OF_SET_VLAN_VID vlan_vid 200 / end D.flow create X ingress > > > > > pattern eth dst is BB:BB:BB:BB:BB:BB / end actions of_SET_VLAN_PCP > > > > > vlan_pcp 3 / end E.flow create 0 egress pattern eth src is > > > > > BB:BB:BB:BB:BB:BB / end actions OF_PUSH_VLAN ethertype 1000 / end > > > > > > > > > > A-D, resulted in "Caught error type 16 (specific action): cause: > > > > 0x7ffcc711db48, action not supported: Operation not supported". > > > > > E resulted in "Egress is not supported". > > > > > > > > > > [3. Quetions] > > > > > Q1. What is the appropriate flow to entag/detag VLAN using testpmd? > > > > > I think related commits are included so it "should" work and my > > > > > guess is > > > > that my flow is somehow wrong. > > > > > Q2. Is it correct understanding that "egress" is not supported for > > > > > mlx5 > > > > PMD? > > > > > Q3. If yes, is it possible to entag VLAN tag to the outgoing > > > > > packet from > > > > physical NIC by using rte_flow? > > > > > > > > > > BR, > > > > > Hideyuki Yamashita > > > > > NTT TechnoCross > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Hideyuki Yamashita <yamashita.hidey...@ntt-tx.co.jp> > > > > > > > Sent: Friday, October 4, 2019 13:35 > > > > > > > To: Hideyuki Yamashita <yamashita.hidey...@ntt-tx.co.jp> > > > > > > > Cc: Moti Haimovsky <mo...@mellanox.com>; Slava Ovsiienko > > > > > > > <viachesl...@mellanox.com>; dev@dpdk.org > > > > > > > Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow > > > > > > > action on VLAN header > > > > > > > > > > > > > > Can somebody (Mellanox guys?) help me out? > > > > > > > > > > > > Hi, Hideyuki > > > > > > > > > > > > I'm sorry, there are long holidays in IL, so let me try to answer. > > > > > > > > > > > > > > > > > > > > > Hello Moti, > > > > > > > > > > > > > > > > I have some questions on the patch. > > > > > > > > Just want to know how to use it. > > > > > > > > > > > > > > > > Q1. Is it correct understanding that the patch will be > > > > > > > > reflected in > > > > > > > > 19.11 if it is approved? > > > > > > > > > > > > Yes, it is merged and should be reflected. > > > > > > > > > > > > > > > > > > > > > > Q2.Which action should I specify when I want to insert VLAN > > > > > > > > tag to non-VLAN frame? > > > > > > > > > > > > > > > > OF_PUSH_VLAN and OF_SET_VLAN_VID and OF_SET_VLAN_PCP ? > > > > > > > > > > > > All of them, OF_PUSH_VLAN inserts the VLAN header, > > > > > > OF_SET_VLAN_VID and OF_SET_VLAN_PCP fill the fields with > > appropriate values. > > > > > > > > > > > > > > > > > > > > > > Q3. Is it possible to detag VLAN when it receives VLAN > > > > > > > > tagged frame from outside of the host? > > > > > > Do you mean some complex configuration with multiple VMs and > > > > engaged > > > > > > E-Switch feature? Anyway, there are multiple ways to strip > > > > > > (untag) VLAN > > > > header: > > > > > > - with E-Switch rules (including match on specified port) > > > > > > - with local port rules > > > > > > - stripping VLAN in Rx queue > > > > > > > > > > > > > > > > > > > > > > Q4. Is it possible to entag VLAN to non-VLAN frame when it > > > > > > > > sends packet to outside of host? > > > > > > Yes. > > > > > > > > > > > > > > > > > > > > > > Q5.Are there any restriction to conbime other ACTIONS like > > QUEUE? > > > > > > Should no be. Action QUEUE is on Rx NIC namespace, VLAN POP is > > > > supported there. > > > > > > > > > > > > > > > > > > > > > > Q6. Is it possible to apply rte_flow actions for specified > > > > > > > > tx queue of physical NIC? > > > > > > > > (e.g. VM connect with PHY:0 using tx queue index:1, I want > > > > > > > > to entag VLAN 101 to the traffic from VM to PHY:0 is it > > > > > > > > possible?) > > > > > > Directly - no, there is no item to match with specific Tx queue. > > > > > > > > > > > > If setting VLAN on specific Tx queue is desired we have two options: > > > > > > > > > > > > - engage Tx offload DEV_TX_OFFLOAD_VLAN_INSERT, and provide > > VLAN > > > > > > with each packet being transferred to tx_burst > > > > > > > > > > > > - engage DEV_TX_OFFLOAD_MATCH_METADATA feature, and set > > > > specific > > > > > > metadata for all packets on specific queue. Then the rules > > > > > > matching with this metadata may be inserted. > > > > > > > > > > > > [snip] > > > > > > > > > > > > With best regards, Slava > > > > > > > > > > > > > > > >
