[dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on VLAN header

[Matan Azrad]

Hi

This bit on in dst mac address = "01:00:00:00:00:00" means the packets is L2 multicast packet.

When you run Testpmd application the multicast configuration is forwarded to the device by default.

So, you have 2 rules:
The default which try to match on the above dst mac bit and to do RSS action for all the queues.
Your rule which try to match on dst mac 11:22:33:44:55:66 (the multicast bit is on) and more and to send it to queue 1.

So, your flow is sub flow of the default flow.

Since the current behavior in our driver is to put all the multicast rules in the same priority - the behavior for the case is unpredictable:
1. you can get the packet twice for the 2 rules.
2. you can get the packet onl for the default RSS action.
3. you can get the packet only on queue 1 as in your rule.

Unfortunately, here, you got option 1 I think (you get the packet twice in your application).

This behavior in our driver to put the 2 rules in same behavior is in discussion by us - maybe it will be changed later.

To workaround the issue:
1. do not configure the default rules (run with --flow-isolate-all in testpmd cmdline).
2. do not configure 2 different multicast rules (even with different priorities).

Enjoy, let me know if you need more help....

Matan

From: Hideyuki Yamashita
> Hi Slava,
> 
> 
> Thanks for your response.
> 
> 1. Is the bug number is the follwoing?
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.
> dpdk.org%2Fshow_bug.cgi%3Fid%3D96&data=02%7C01%7Cmatan%40
> mellanox.com%7Ce10ce5ee0f8f4350c6a508d76bee3a97%7Ca652971c7d2e4d
> 9ba6a4d149256f461b%7C0%7C0%7C637096543244123210&sdata=V3V21
> gwJExHt7mkg0sAEwW%2FLTCIbJEkHznNtUCVkN%2BA%3D&reserved=0
> 
> 2.I've sent packets using scapy with the follwing script and I think it is unicast
> ICMP.
> How did you thought the packets are broadcast/muticast?
> Note that I am not familiar with log of testpmd.
> 
> ----------------------------------------------------------------------------------------------
> from scapy.all import *
> 
> vlan_vid = 100
> vlan_prio = 0
> vlan_id = 0
> vlan_flg = True
> src_mac = "CC:CC:CC:CC:CC:CC"
> dst_mac = "11:22:33:44:55:66"
> dst_ip = "192.168.200.101"
> iface = "p7p1"
> pps = 5
> loop = 5
> 
> def icmp_send():
>     ls(Dot1Q)
>     if vlan_flg:
>         pkt = Ether(dst=dst_mac, src=src_mac)/Dot1Q(vlan=vlan_vid,
> prio=vlan_prio, id=vlan_id)/IP(dst=dst_ip)/ICMP()
>     else:
>         pkt = Ether(dst=dst_mac, src=src_mac)/IP(dst=dst_ip)/ICMP()
>     pkt.show()
>     sendpfast(pkt, iface=iface, pps=pps, loop=loop, file_cache=True)
> 
> icmp_send()
> -----------------------------------------------------------------------------
> 
> Thanks!
> 
> BR,
> Hideyuki Yamashita
> NTT TechnoCross
> 
> > Hi, Hideyuki
> >
> > The frame in your report is broadcast/multicast. Please, try unicast one.
> > For broadcast we have the ticket, currently issue is under investigation.
> > Anyway, thanks for reporting.
> >
> > With best regards, Slava
> >
> > > -----Original Message-----
> > > From: Hideyuki Yamashita <yamashita.hideyuki at ntt-tx.co.jp>
> > > Sent: Thursday, November 14, 2019 7:02
> > > To: dev at dpdk.org
> > > Cc: Slava Ovsiienko <viacheslavo at mellanox.com>
> > > Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow
> > > action on VLAN header
> > >
> > > Hello Slava,
> > >
> > > As I reported to you, creating flow was successful with Connect-X5.
> > > However when I sent packets to the NIC from outer side of the host,
> > > I have problem.
> > >
> > >
> > > [Case 1]
> > > Packet distribution on multi-queue based on dst MAC address.
> > >
> > > NIC config:
> > > 04:00.0 Mellanox Connect-X5
> > > 0.5.00.0 Intel XXV710
> > >
> > > testpmd startup param:
> > > sudo ./testpmd -c 1ffff -n 4 --socket-mem=1024,1024 --log-level=10 -w
> > > 04:00.0,dv_flow_en=1  -w 05:00.0    -- -i --rxq=16 --txq=16 --disable-rss --
> pkt-
> > > filter-mode=perfect
> > >
> > > flow command:
> > > testpmd> flow create 0 ingress pattern eth dst is 11:22:33:44:55:66
> > > testpmd> / end actions queue index 1 / end
> > > Flow rule #0 created
> > > testpmd> flow create 1 ingress pattern eth dst is 11:22:33:44:55:66
> > > testpmd> type mask 0xffff / end actions queue index 1 / end
> > > Flow rule #0 created
> > >
> > > Packet reception:(no VLAN tag)
> > > port 0/queue 0: received 1 packets
> > >   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 -
> > > length=60
> > > - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN
> L4_NONFRAG  -
> > > sw ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Receive queue=0x0
> > >   ol_flags: PKT_RX_L4_CKSUM_UNKNOWN PKT_RX_IP_CKSUM_GOOD
> > > PKT_RX_OUTER_L4_CKSUM_UNKNOWN port 1/queue 0: sent 1 packets
> > >   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 -
> > > length=60
> > > - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN
> L4_NONFRAG  -
> > > sw ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Send queue=0x0
> > >   ol_flags: PKT_RX_L4_CKSUM_UNKNOWN PKT_RX_IP_CKSUM_GOOD
> > > PKT_RX_OUTER_L4_CKSUM_UNKNOWN
> > >
> > > port 1/queue 1: received 1 packets
> > >   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 -
> > > length=60
> > > - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_ICMP  -
> sw
> > > ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Receive queue=0x1
> > >   ol_flags: PKT_RX_L4_CKSUM_GOOD PKT_RX_IP_CKSUM_GOOD
> > > PKT_RX_OUTER_L4_CKSUM_UNKNOWN port 0/queue 1: sent 1 packets
> > >   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 -
> > > length=60
> > > - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_ICMP  -
> sw
> > > ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Send queue=0x1
> > >   ol_flags: PKT_RX_L4_CKSUM_GOOD PKT_RX_IP_CKSUM_GOOD
> > > PKT_RX_OUTER_L4_CKSUM_UNKNOWN
> > >
> > > Result:
> > > Matched packet queued to queue=0 port=0. Not queue=1, port=0.
> > >
> > > Expectation:
> > > When receiving packet which has dst MAC 11:22:33:44:55:66 should be
> > > received on queue=1 port=0.
> > >
> > > Question:
> > > Why matching packet is NOT enqueued into queue=1 on port=0?
> > >
> > >
> > > [Case 2]
> > > Packet distribution on multi-queue based on VLAN tag
> > >
> > > testpmd startup param:
> > > sudo ./testpmd -c 1ffff -n 4 --socket-mem=1024,1024 --log-level=10 -w
> > > 04:00.0,dv_flow_en=1  -w 05:00.0    -- -i --rxq=16 --txq=16 --disable-rss --
> pkt-
> > > filter-mode=perfect
> > >
> > > flow command:
> > > flow create 0 ingress group 1 pattern eth / vlan vid is 100 / end
> > > actions queue index 1 / of_pop_vlan / end flow create 0 ingress
> > > group 0 pattern eth / end actions jump group 1 / end
> > >
> > > Packet Reception: (VLAN100)
> > > port 0/queue 1: received 1 packets
> > >   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 -
> > > length=56
> > > - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN
> L4_NONFRAG  -
> > > sw ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Receive queue=0x1
> > >   ol_flags: PKT_RX_L4_CKSUM_UNKNOWN PKT_RX_IP_CKSUM_GOOD
> > > PKT_RX_OUTER_L4_CKSUM_UNKNOWN port 1/queue 1: sent 1 packets
> > >   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 -
> > > length=56
> > > - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN
> L4_NONFRAG  -
> > > sw ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Send queue=0x1
> > >   ol_flags: PKT_RX_L4_CKSUM_UNKNOWN PKT_RX_IP_CKSUM_GOOD
> > > PKT_RX_OUTER_L4_CKSUM_UNKNOWN
> > >
> > > Result:
> > > Matched packetd queued to queue=1, port=0 Other packet(VLAN101
> > > packet) discarded.
> > >
> > > Expectation:
> > > Matched packet queued to queue =1, port=0 Non Matched packet
> queued
> > > to queue=0, port=0
> > >
> > > Question:
> > > Is above behavior collect?
> > > What is the default behavior of unmatchedd packets (queue to queue=0
> > > or discard packet)
> > >
> > > BR,
> > > Hideyuki Yamashita
> > > NTT TechnoCross
> > >
> > >
> > >
> > >
> > >
>