Hello Matan and Slava, Thanks for your quick response.
1. What you were saying is correct. When I create flow with dst mac 10:22:33:44:55:66 instead of 11:22:33:44:55:66, received packets are queued to specified queue. Thanks for your advice! Q1. What is the problem with broadcast/multicast address? Q2. What is the bug number on Bugzilla of DPDK? Q3. What is the default behavior of unmatched packets? Discard packet or queue those to default queue(e.g. queue=0)? When I tested packet distribution with vlan id, unmatched packets looked discarded.. I would like to know what is the default handling. Thanks! Best Regards, Hideyuki Yamashita NTT TechnoCross > 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.hidey...@ntt-tx.co.jp> > > > > Sent: Thursday, November 14, 2019 7:02 > > > > To: dev@dpdk.org > > > > Cc: Slava Ovsiienko <viachesl...@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 > > > > > > > > > > > > > > > > > > > > > > >
