From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 279FDA04B5; Wed, 4 Dec 2019 03:43:29 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 5A94F1BF6E; Wed, 4 Dec 2019 03:43:28 +0100 (CET) Received: from dish-sg.nttdocomo.co.jp (dish-sg.nttdocomo.co.jp [202.19.227.74]) by dpdk.org (Postfix) with ESMTP id 588FF1BF6C for ; Wed, 4 Dec 2019 03:43:26 +0100 (CET) X-dD-Source: Outbound Received: from zssg-mailmd102.ddreams.local (zssg-mailmd900.ddreams.local [10.160.172.63]) by zssg-mailou104.ddreams.local (Postfix) with ESMTP id 47461120114; Wed, 4 Dec 2019 11:43:24 +0900 (JST) Received: from t131sg-mailcc12.ddreams.local (t131sg-mailcc12.ddreams.local [100.66.31.87]) by zssg-mailmd102.ddreams.local (dDREAMS) with ESMTP id <0Q1Y012WEVKCWD80@dDREAMS>; Wed, 04 Dec 2019 11:43:24 +0900 (JST) Received: from t131sg-mailcc11 (localhost [127.0.0.1]) by t131sg-mailcc12.ddreams.local (unknown) with SMTP id xB42hOh0016044; Wed, 4 Dec 2019 11:43:24 +0900 Received: from zssg-mailmf104.ddreams.local (unknown [127.0.0.1]) by zssg-mailmf104.ddreams.local (Postfix) with ESMTP id 6BCE47E6038; Wed, 4 Dec 2019 11:43:10 +0900 (JST) Received: from zssg-mailmf104.ddreams.local (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 69E5D8E605A; Wed, 4 Dec 2019 11:43:10 +0900 (JST) Received: from localhost (unknown [127.0.0.1]) by IMSVA (Postfix) with SMTP id 5E8D78E606A; Wed, 4 Dec 2019 11:43:10 +0900 (JST) X-IMSS-HAND-OFF-DIRECTIVE: localhost:10026 Received: from zssg-mailmf104.ddreams.local (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D509D8E605E; Wed, 4 Dec 2019 11:43:09 +0900 (JST) Received: from zssg-mailua104.ddreams.local (unknown [10.160.172.62]) by zssg-mailmf104.ddreams.local (Postfix) with ESMTP; Wed, 4 Dec 2019 11:43:09 +0900 (JST) Received: from [10.87.198.18] (unknown [10.160.183.129]) by zssg-mailua104.ddreams.local (dDREAMS) with ESMTPA id <0Q1Y00VZ0VJNJOF0@dDREAMS>; Wed, 04 Dec 2019 11:43:00 +0900 (JST) Date: Wed, 04 Dec 2019 11:43:00 +0900 From: Hideyuki Yamashita In-reply-to: <20191119203609.3FFD.17218CA3@ntt-tx.co.jp_1> References: <20191119203609.3FFD.17218CA3@ntt-tx.co.jp_1> Message-id: <20191204114259.CFE8.17218CA3@ntt-tx.co.jp_1> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: Becky! ver. 2.74.02 [ja] X-TM-AS-GCONF: 00 To: Matan Azrad , Slava Ovsiienko Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on VLAN header X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 > > > > > Sent: Thursday, November 14, 2019 7:02 > > > > > To: dev@dpdk.org > > > > > Cc: Slava Ovsiienko > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >