Hello Matan and Slava, Thanks for your quick response.
How about the following? BR, Hideyuki Yamashita NTT TechnoCross > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >