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 2A138A0351; Mon, 18 Nov 2019 11:03:10 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id DE2553256; Mon, 18 Nov 2019 11:03:09 +0100 (CET) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70070.outbound.protection.outlook.com [40.107.7.70]) by dpdk.org (Postfix) with ESMTP id 1ED422B87 for ; Mon, 18 Nov 2019 11:03:08 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FH18mV9ehzrD8O2K5rMyOP3ynqHZrNbwbEV2zJ8jS2F95V066nVQrn1+m7muXXThki/HWyDY5me0l+1luzkmEdgDikOPtAgWA/uSac96gUYnhCbhBDjEXfIP1mpalNAUmGwaanEHsI3VzPEWXidZgfq9l/LTArZnx914TyrM1riD3fyLcsusu0hbw10aq/rr6jjm1/HmuwKevWF4q+EZCYRQDAWNs1m38VoEpoiFIwSyGltSMPCGwQ1gCBmhjQ69fPeZJ1mgSOu5OY8jCJCRJYz3HkpQSSoee7IGAuPv7PRBn5D6mSVAdG4TITF5W5bTjhzmq33yofTCXlerFTxjpg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EbcCW/Y8qMQ071cLc6j7RIIjunCpxejQJVrTy+RGTdA=; b=LUwBASdaxbTqVwi8jaSQb+uPCwqIMdDHTDoqFttGGNVKXOYtEWcGTSC6vLpd5V8QPh644dSmMVDbzOxmNU1iC0IkmmasgdaKkX9/+Sp4NKsTyRyw+nPIsIzR6dDblgv3om6V8mUAr6g3RknKc3gccedqxdMDwf9IwCKnydzPAu7FmFWUourHQKw/WHedEXLh9mCRlnTAP2VcyFFrMv2rL39yHMD6l5HS7J4kMKJvEfch8EcY+Mjufcjs4nBqd/p1fadsBamXGtmpqvC0eMG/SHG4ntUs6AFQwtK/iRKiS6e6k92RXbD7+z3AaGWeIhvUxswGoHb3F8qYAZjM3W/PjA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mellanox.com; dmarc=pass action=none header.from=mellanox.com; dkim=pass header.d=mellanox.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EbcCW/Y8qMQ071cLc6j7RIIjunCpxejQJVrTy+RGTdA=; b=iePrnsDJn1dytc2YvxjfNHNj9qPwo5DaxaSVvCxtzu+SxNau+UfLRkeVGrqEtkF8sYLDUgoMwYdnTCoAn7suKMV5GxfOa0I6VYiW3zqWnIRPbx9cO6KtmQyYIES28qisg6Fv39SR5i5Yfes7obZyPy+NSrVKymy1ntQd+B0JxSE= Received: from AM0PR0502MB4019.eurprd05.prod.outlook.com (52.133.39.139) by AM0PR0502MB3940.eurprd05.prod.outlook.com (52.133.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.26; Mon, 18 Nov 2019 10:03:07 +0000 Received: from AM0PR0502MB4019.eurprd05.prod.outlook.com ([fe80::fd7a:e5a8:deec:c1b0]) by AM0PR0502MB4019.eurprd05.prod.outlook.com ([fe80::fd7a:e5a8:deec:c1b0%7]) with mapi id 15.20.2451.029; Mon, 18 Nov 2019 10:03:07 +0000 From: Matan Azrad To: Hideyuki Yamashita , Slava Ovsiienko CC: "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on VLAN header Thread-Index: AQHVep9wO0nA4vsym02JLzEDdOrMkKdKThMAgBYByoCABHh/AIAABNuAgAYceYCABlkugIAB2s8AgAABCoCAAAqQgIABVjCAgAAs14CAAAxuAIAH2PSAgAGcxgCAAFywAIAAzCSAgAAVCwCAAFQIAIAKm5AAgAG4GwCABKTDgIAANWNg Date: Mon, 18 Nov 2019 10:03:06 +0000 Message-ID: References: <20191114140134.88E8.17218CA3@ntt-tx.co.jp_1> <20191118151131.7FCA.17218CA3@ntt-tx.co.jp_1> In-Reply-To: <20191118151131.7FCA.17218CA3@ntt-tx.co.jp_1> Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=matan@mellanox.com; x-originating-ip: [193.47.165.251] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: ed1598e7-4579-4136-f05b-08d76c0e8286 x-ms-traffictypediagnostic: AM0PR0502MB3940:|AM0PR0502MB3940: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 0225B0D5BC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(346002)(136003)(376002)(366004)(52314003)(13464003)(199004)(189003)(53546011)(7736002)(305945005)(256004)(99286004)(486006)(86362001)(110136005)(71200400001)(52536014)(5660300002)(476003)(6436002)(8936002)(446003)(14444005)(2906002)(316002)(81166006)(55016002)(76176011)(11346002)(81156014)(7696005)(64756008)(66446008)(66476007)(66946007)(102836004)(9686003)(6506007)(4326008)(74316002)(6306002)(71190400001)(26005)(14454004)(25786009)(76116006)(478600001)(186003)(229853002)(3846002)(6116002)(66066001)(966005)(33656002)(66556008)(6246003)(6636002)(45080400002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR0502MB3940; H:AM0PR0502MB4019.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: w9OEsgWJb+r0tYhYSsnbu+u8PdOZvNv7uJz4ADOF6egd+R7sP5H++Eoj5nOU2vUSIHjh98VogCLezCed5cPlAyB/JL48BS3D8NPQi6T9MDKk5VdvwoiDWtKG3/pdGun7aeWwP4p74SslMFn+pgdbk2e1UI0mM9bYxnuSxDk4UxUGal9M4REEJpv+5zt9eUdHv7VkihwAsmnutxaodAtKWnfX0NiPNoWeAU4a1cdj52RvQOkeUu7hFaWnKx5kBj5VjYwpLqgaVjsLclTE8xguL62cb93xd8qj3a2BGAhb8ce9kWcBUICZ6awgCiwaiHlkBPfjBSjoeMtTk5OIyKO3FK4RTic0URZwLl0oJlpc+HNDH5EeN2bDFCY+b2GSC3kaFX9IGUCby01fn30Au8HmNA+4Y6sn3O5tDvbExjd/u4krEmbbPWOTzaHBvRuVZcCz Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: ed1598e7-4579-4136-f05b-08d76c0e8286 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2019 10:03:07.0308 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: cepMY09zd3VUC+qE+geFXkhWUokkFChF66xxgoF0hI9FoR9CI8t1qqvFLMnd7QVMC2NcSLdxy75Qmp2GBzWTaw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR0502MB3940 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" Hi This bit on in dst mac address =3D "01:00:00:00:00:00" means the packets is= L2 multicast packet. When you run Testpmd application the multicast configuration is forwarded t= o 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 actio= n for all the queues. Your rule which try to match on dst mac 11:22:33:44:55:66 (the multicast bi= t 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 discu= ssion 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 testp= md cmdline). 2. do not configure 2 different multicast rules (even with different priori= ties). Enjoy, let me know if you need more help.... Matan From: Hideyuki Yamashita > Hi Slava, >=20 >=20 > Thanks for your response. >=20 > 1. Is the bug number is the follwoing? > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fbugs. > dpdk.org%2Fshow_bug.cgi%3Fid%3D96&data=3D02%7C01%7Cmatan%40 > mellanox.com%7Ce10ce5ee0f8f4350c6a508d76bee3a97%7Ca652971c7d2e4d > 9ba6a4d149256f461b%7C0%7C0%7C637096543244123210&sdata=3DV3V21 > gwJExHt7mkg0sAEwW%2FLTCIbJEkHznNtUCVkN%2BA%3D&reserved=3D0 >=20 > 2.I've sent packets using scapy with the follwing script and I think it i= s unicast > ICMP. > How did you thought the packets are broadcast/muticast? > Note that I am not familiar with log of testpmd. >=20 > -------------------------------------------------------------------------= --------------------- > from scapy.all import * >=20 > vlan_vid =3D 100 > vlan_prio =3D 0 > vlan_id =3D 0 > vlan_flg =3D True > src_mac =3D "CC:CC:CC:CC:CC:CC" > dst_mac =3D "11:22:33:44:55:66" > dst_ip =3D "192.168.200.101" > iface =3D "p7p1" > pps =3D 5 > loop =3D 5 >=20 > def icmp_send(): > ls(Dot1Q) > if vlan_flg: > pkt =3D Ether(dst=3Ddst_mac, src=3Dsrc_mac)/Dot1Q(vlan=3Dvlan_vid= , > prio=3Dvlan_prio, id=3Dvlan_id)/IP(dst=3Ddst_ip)/ICMP() > else: > pkt =3D Ether(dst=3Ddst_mac, src=3Dsrc_mac)/IP(dst=3Ddst_ip)/ICMP= () > pkt.show() > sendpfast(pkt, iface=3Diface, pps=3Dpps, loop=3Dloop, file_cache=3DTr= ue) >=20 > icmp_send() > -------------------------------------------------------------------------= ---- >=20 > Thanks! >=20 > BR, > Hideyuki Yamashita > NTT TechnoCross >=20 > > Hi, Hideyuki > > > > The frame in your report is broadcast/multicast. Please, try unicast on= e. > > For broadcast we have the ticket, currently issue is under investigatio= n. > > 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=3D1024,1024 --log-level=3D1= 0 -w > > > 04:00.0,dv_flow_en=3D1 -w 05:00.0 -- -i --rxq=3D16 --txq=3D16 --d= isable-rss -- > pkt- > > > filter-mode=3Dperfect > > > > > > 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=3DCC:CC:CC:CC:CC:CC - dst=3D11:22:33:44:55:66 - type=3D0x0800 - > > > length=3D60 > > > - nb_segs=3D1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN > L4_NONFRAG - > > > sw ptype: L2_ETHER L3_IPV4 - l2_len=3D14 - l3_len=3D20 - Receive que= ue=3D0x0 > > > 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=3DCC:CC:CC:CC:CC:CC - dst=3D11:22:33:44:55:66 - type=3D0x0800 - > > > length=3D60 > > > - nb_segs=3D1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN > L4_NONFRAG - > > > sw ptype: L2_ETHER L3_IPV4 - l2_len=3D14 - l3_len=3D20 - Send queue= =3D0x0 > > > 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=3DCC:CC:CC:CC:CC:CC - dst=3D11:22:33:44:55:66 - type=3D0x0800 - > > > length=3D60 > > > - nb_segs=3D1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_ICMP - > sw > > > ptype: L2_ETHER L3_IPV4 - l2_len=3D14 - l3_len=3D20 - Receive queue= =3D0x1 > > > 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=3DCC:CC:CC:CC:CC:CC - dst=3D11:22:33:44:55:66 - type=3D0x0800 - > > > length=3D60 > > > - nb_segs=3D1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_ICMP - > sw > > > ptype: L2_ETHER L3_IPV4 - l2_len=3D14 - l3_len=3D20 - Send queue=3D0= x1 > > > ol_flags: PKT_RX_L4_CKSUM_GOOD PKT_RX_IP_CKSUM_GOOD > > > PKT_RX_OUTER_L4_CKSUM_UNKNOWN > > > > > > Result: > > > Matched packet queued to queue=3D0 port=3D0. Not queue=3D1, port=3D0. > > > > > > Expectation: > > > When receiving packet which has dst MAC 11:22:33:44:55:66 should be > > > received on queue=3D1 port=3D0. > > > > > > Question: > > > Why matching packet is NOT enqueued into queue=3D1 on port=3D0? > > > > > > > > > [Case 2] > > > Packet distribution on multi-queue based on VLAN tag > > > > > > testpmd startup param: > > > sudo ./testpmd -c 1ffff -n 4 --socket-mem=3D1024,1024 --log-level=3D1= 0 -w > > > 04:00.0,dv_flow_en=3D1 -w 05:00.0 -- -i --rxq=3D16 --txq=3D16 --d= isable-rss -- > pkt- > > > filter-mode=3Dperfect > > > > > > 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=3DCC:CC:CC:CC:CC:CC - dst=3D11:22:33:44:55:66 - type=3D0x0800 - > > > length=3D56 > > > - nb_segs=3D1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN > L4_NONFRAG - > > > sw ptype: L2_ETHER L3_IPV4 - l2_len=3D14 - l3_len=3D20 - Receive que= ue=3D0x1 > > > 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=3DCC:CC:CC:CC:CC:CC - dst=3D11:22:33:44:55:66 - type=3D0x0800 - > > > length=3D56 > > > - nb_segs=3D1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN > L4_NONFRAG - > > > sw ptype: L2_ETHER L3_IPV4 - l2_len=3D14 - l3_len=3D20 - Send queue= =3D0x1 > > > ol_flags: PKT_RX_L4_CKSUM_UNKNOWN PKT_RX_IP_CKSUM_GOOD > > > PKT_RX_OUTER_L4_CKSUM_UNKNOWN > > > > > > Result: > > > Matched packetd queued to queue=3D1, port=3D0 Other packet(VLAN101 > > > packet) discarded. > > > > > > Expectation: > > > Matched packet queued to queue =3D1, port=3D0 Non Matched packet > queued > > > to queue=3D0, port=3D0 > > > > > > Question: > > > Is above behavior collect? > > > What is the default behavior of unmatchedd packets (queue to queue=3D= 0 > > > or discard packet) > > > > > > BR, > > > Hideyuki Yamashita > > > NTT TechnoCross > > > > > > > > > > > > > > > >=20