[{"id":1763833,"web_url":"http://patchwork.ozlabs.org/comment/1763833/","msgid":"","list_archive_url":null,"date":"2017-09-06T06:33:32","subject":"Re: [ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow","submitter":{"id":72097,"url":"http://patchwork.ozlabs.org/api/people/72097/","name":"Patil, Harish","email":"Harish.Patil@cavium.com"},"content":"-----Original Message-----\nFrom: on behalf of Yuanhan Liu\n\nDate: Tuesday, September 5, 2017 at 2:22 AM\nTo: \"dev@openvswitch.org\" \nSubject: [ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow\n\n>Hi,\n>\n>Here is a joint work from Mellanox and Napatech, to enable the flow hw\n>offload with the DPDK generic flow interface (rte_flow).\n>\n>The basic idea is to associate the flow with a mark id (a unit32_t\n>number).\n>Later, we then get the flow directly from the mark id, bypassing the heavy\n>emc processing, including miniflow_extract.\n>\n>The association is done with CMAP in patch 1. It also reuses the flow\n>APIs introduced while adding the tc offloads. The emc bypassing is done\n>in patch 2. The flow offload is done in patch 4, which mainly does two\n>things:\n>\n>- translate the ovs match to DPDK rte flow patterns\n>- bind those patterns with a MARK action.\n>\n>Afterwards, the NIC will set the mark id in every pkt's mbuf when it\n>matches the flow. That's basically how we could get the flow directly\n>from the received mbuf.\n>\n>While testing with PHY-PHY forwarding with one core and one queue, I got\n>about 54% performance boost. For PHY-vhost forwarding, I got about 41%\n>performance boost. The reason it's lower than v1 is I added the logic\n>to get the correct tcp_flags, which examines all packets recieved.\n>\n>The major issue mentioned in last version is also workarounded: the\n>queue index is never set to 0 blindly anymore, but set to the rxq that\n>first receives the upcall pkt.\n>\n>Note that it's disabled by default, which can be enabled by:\n>\n> $ ovs-vsctl set Open_vSwitch . other_config:hw-offload=true\n>\n>\n>v2: - workaround the queue action issue\n> - fixed the tcp_flags being skipped issue, which also fixed the\n> build warnings\n> - fixed l2 patterns for Intel nic\n> - Converted some macros to functions\n> - did not hardcode the max number of flow/action\n> - rebased on top of the lastest code\n>\n>Thanks.\n>\n> --yliu\n>\n>\n>---\n>Finn Christensen (3):\n> netdev-dpdk: implement flow put with rte flow\n> netdev-dpdk: retry with queue action\n> netdev-dpdk: set FDIR config\n>\n>Shachar Beiser (1):\n> dpif-netdev: record rx queue id for the upcall\n>\n>Yuanhan Liu (4):\n> dpif-netdev: associate flow with a mark id\n> dpif-netdev: retrieve flow directly from the flow mark\n> netdev-dpdk: convert ufid to dpdk flow\n> netdev-dpdk: remove offloaded flow on deletion\n>\n> lib/dp-packet.h | 14 ++\n> lib/dpif-netdev.c | 132 +++++++++++--\n> lib/flow.c | 78 ++++++++\n> lib/flow.h | 1 +\n> lib/netdev-dpdk.c | 574\n>+++++++++++++++++++++++++++++++++++++++++++++++++++++-\n> lib/netdev.c | 1 +\n> lib/netdev.h | 7 +\n> 7 files changed, 795 insertions(+), 12 deletions(-)\n>\n>-- \n>2.7.4\n>\n\nHi all,\n\nCan you please confirm that you are supporting offloading of both the EMC\nflows and DPCLs (megaflows) here, i.e. OVS would skip hash table lookups\nin both the cases if UFID is provided in the MBUF. Assuming that is\ncorrect, when a match is found in dpcls, does OVS insert that new flow\nback into the EMC cache?\n\nThanks,\nHarish\n\n\n>","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","dev@openvswitch.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","ovs-dev@mail.linuxfoundation.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=openvswitch.org\n\t(client-ip=140.211.169.12; helo=mail.linuxfoundation.org;\n\tenvelope-from=ovs-dev-bounces@openvswitch.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=CAVIUMNETWORKS.onmicrosoft.com\n\theader.i=@CAVIUMNETWORKS.onmicrosoft.com header.b=\"TnQN4Icu\"; \n\tdkim-atps=neutral","spf=none (sender IP is )\n\tsmtp.mailfrom=Harish.Patil@cavium.com; "],"Received":["from mail.linuxfoundation.org (mail.linuxfoundation.org\n\t[140.211.169.12])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xnDLY2cPKz9s8J\n\tfor ;\n\tWed, 6 Sep 2017 16:33:40 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id BACC08A1;\n\tWed, 6 Sep 2017 06:33:37 +0000 (UTC)","from smtp1.linuxfoundation.org (smtp1.linux-foundation.org\n\t[172.17.192.35])\n\tby mail.linuxfoundation.org (Postfix) with ESMTPS id CB431722\n\tfor ; Wed, 6 Sep 2017 06:33:35 +0000 (UTC)","from NAM02-CY1-obe.outbound.protection.outlook.com\n\t(mail-cys01nam02on0057.outbound.protection.outlook.com\n\t[104.47.37.57])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id 292091E8\n\tfor ; Wed, 6 Sep 2017 06:33:35 +0000 (UTC)","from MWHPR07MB3184.namprd07.prod.outlook.com (10.172.96.142) by\n\tMWHPR07MB3584.namprd07.prod.outlook.com (10.164.192.149) with\n\tMicrosoft SMTP Server (version=TLS1_2,\n\tcipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id\n\t15.20.13.10; Wed, 6 Sep 2017 06:33:33 +0000","from MWHPR07MB3184.namprd07.prod.outlook.com ([10.172.96.142]) by\n\tMWHPR07MB3184.namprd07.prod.outlook.com ([10.172.96.142]) with\n\tmapi id 15.20.0013.018; Wed, 6 Sep 2017 06:33:33 +0000"],"X-Greylist":"whitelisted by SQLgrey-1.7.6","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com;\n\th=From:Date:Subject:Message-ID:Content-Type:MIME-Version;\n\tbh=Nowewnv97XKP9stIr4iAmnAYq6d8uyOqBFSuEd0WSV8=;\n\tb=TnQN4IcuyKtTnJHbitszRnpkfvMSIAUfXm5W669LvJ4MufD/YkO4EeXrZTtGn97W71b0He2YuLMfDTi0gAT9GBtRgaWcHs9gFOoapkM55SVXvZup5+7hwa/eyn6oqcSD+NmRYUzQymTYMnnnLyboxIZTWhju/Esc8MktAQ1HzuU=","From":"\"Patil, Harish\" ","To":"Yuanhan Liu , \"dev@openvswitch.org\"\n\t","Thread-Topic":"[ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow","Thread-Index":"AQHTJiis1qmE8mZPnEmWdPSqy/YW+aKm8nEA","Date":"Wed, 6 Sep 2017 06:33:32 +0000","Message-ID":"","References":"<1504603381-30071-1-git-send-email-yliu@fridaylinux.org>","In-Reply-To":"<1504603381-30071-1-git-send-email-yliu@fridaylinux.org>","Accept-Language":"en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","authentication-results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=openvswitch.org\n\t(client-ip=140.211.169.12; helo=mail.linuxfoundation.org;\n\tenvelope-from=ovs-dev-bounces@openvswitch.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=CAVIUMNETWORKS.onmicrosoft.com\n\theader.i=@CAVIUMNETWORKS.onmicrosoft.com header.b=\"TnQN4Icu\"; \n\tdkim-atps=neutral","spf=none (sender IP is )\n\tsmtp.mailfrom=Harish.Patil@cavium.com; "],"x-originating-ip":"[75.54.224.17]","x-ms-publictraffictype":"Email","x-microsoft-exchange-diagnostics":"1; MWHPR07MB3584;\n\t6:A1gHaLt79f5tTC6kBIN0MhcMRpQsvR1VTK8CSIsYCyIfB3LzzltfTc9DvdTHElNdPp9alwdF/o4aLg9Fg9c29zu3POJHFIWjLEX4ZjxlX2H1HsMp1DSXNK+1dxa/AUjrkhyJRjz3ZqUoDKIbplVvHuUIOqlOy9w8CvAW4tOoKHeBNkRDEnDGsB5soaTTrU5VE52srnO3iKmc6X6LVGpdYSpUkkdOd02uEHYJZ27DfMivbZdv3YBoim450faeCe8BQ4Al4Xwrp3e4xoxOVBEP5g1fc1PhR0/UsggjU0NAn7gqsaC1I8RtV9rx+dzo6PQeYr2K4YD2VEmCGe6LkpMsew==;\n\t5:l/h7U7cH5bQ4afRUWFmMnrHk72AN3+ABNUb/+ux/YGk99Qayw35IyTXRZZA+PSI4RqxUa1wcgHz4bfDZliMZUTBqGMKJEZozNTRMvJ1BYchp2S3a09VvaeqvTPt+BEJs7tACbvPwSa9DVyI26S5XvQ==;\n\t24:7XilnA8/VAe6i5wu7R1iNd0ABHQDOnAk9Up8/otqNNJ9rOAUGdMqrXrwghJHTRLLYt5I9iReujTHeJ6Dx7sR3NHsry/wr/I6vVzPHoMVUyk=;\n\t7:2seB1K4eSw+URrU5P2IX0+wHo91mSlCii44hIP16b3Oqr/oPJTjr6sUnxxz4j96I5i+MsK8cay7VjM888sFwwcZ2XEqDWV9HlEW9joE0cgWOQGRsfVvCX/bYMtYJvXrvw4OHU4nKK3O94S2j1TQ9L0tHjBSQiF31xGn8ThhGbzeM1UwmVb4K+XCWaZCgtvOi1uSUbGzagO5Sa1EPQSC3xVgtkaXc86yjTjjK20dOnQQ=","x-ms-exchange-antispam-srfa-diagnostics":"SSOS;","x-ms-office365-filtering-correlation-id":"6dfadf12-fbe4-4cae-684d-08d4f4f13218","x-microsoft-antispam":"UriScan:; BCL:0; PCL:0;\n\tRULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);\n\tSRVR:MWHPR07MB3584; ","x-ms-traffictypediagnostic":"MWHPR07MB3584:","x-exchange-antispam-report-test":"UriScan:(216315784871565);","x-microsoft-antispam-prvs":"","x-exchange-antispam-report-cfa-test":"BCL:0; PCL:0;\n\tRULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);\n\tSRVR:MWHPR07MB3584; BCL:0; PCL:0;\n\tRULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);\n\tSRVR:MWHPR07MB3584; ","x-forefront-prvs":"0422860ED4","x-forefront-antispam-report":"SFV:NSPM;\n\tSFS:(10009020)(6009001)(13464003)(189002)(377454003)(53754006)(199003)(72206003)(14454004)(106356001)(5660300001)(105586002)(97736004)(50986999)(66066001)(25786009)(8936002)(8676002)(4326008)(101416001)(7736002)(81166006)(76176999)(54356999)(2906002)(3846002)(2501003)(3280700002)(189998001)(102836003)(86362001)(6116002)(6436002)(2900100001)(36756003)(3660700001)(81156014)(99286003)(68736007)(2950100002)(77096006)(54906002)(6246003)(305945005)(53546010)(6512007)(229853002)(53936002)(6506006)(6486002)(478600001);\n\tDIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR07MB3584;\n\tH:MWHPR07MB3184.namprd07.prod.outlook.com; FPR:; SPF:None;\n\tPTR:InfoNoRecords; MX:1; A:1; LANG:en; ","received-spf":"None (protection.outlook.com: cavium.com does not designate\n\tpermitted sender hosts)","spamdiagnosticoutput":"1:99","spamdiagnosticmetadata":"NSPM","Content-ID":"","MIME-Version":"1.0","X-OriginatorOrg":"cavium.com","X-MS-Exchange-CrossTenant-originalarrivaltime":"06 Sep 2017 06:33:32.9119\n\t(UTC)","X-MS-Exchange-CrossTenant-fromentityheader":"Hosted","X-MS-Exchange-CrossTenant-id":"711e4ccf-2e9b-4bcf-a551-4094005b6194","X-MS-Exchange-Transport-CrossTenantHeadersStamped":"MWHPR07MB3584","X-Spam-Status":"No, score=0.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,\n\tRCVD_IN_DNSWL_NONE autolearn=disabled version=3.3.1","X-Spam-Checker-Version":"SpamAssassin 3.3.1 (2010-03-16) on\n\tsmtp1.linux-foundation.org","Subject":"Re: [ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow","X-BeenThere":"ovs-dev@openvswitch.org","X-Mailman-Version":"2.1.12","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"ovs-dev-bounces@openvswitch.org","Errors-To":"ovs-dev-bounces@openvswitch.org"}},{"id":1763838,"web_url":"http://patchwork.ozlabs.org/comment/1763838/","msgid":"","list_archive_url":null,"date":"2017-09-06T06:53:12","subject":"Re: [ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow","submitter":{"id":72305,"url":"http://patchwork.ozlabs.org/api/people/72305/","name":"Finn Christensen","email":"fc@napatech.com"},"content":"-----Original Message-----\nFrom: Patil, Harish [mailto:Harish.Patil@cavium.com] \nSent: 6. september 2017 08:34\nTo: Yuanhan Liu ; dev@openvswitch.org\nCc: Finn Christensen ; dball@vmware.com\nSubject: Re: [ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow\n\n\n\n-----Original Message-----\nFrom: on behalf of Yuanhan Liu \nDate: Tuesday, September 5, 2017 at 2:22 AM\nTo: \"dev@openvswitch.org\" \nSubject: [ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow\n\n>Hi,\n>\n>Here is a joint work from Mellanox and Napatech, to enable the flow hw \n>offload with the DPDK generic flow interface (rte_flow).\n>\n>The basic idea is to associate the flow with a mark id (a unit32_t \n>number).\n>Later, we then get the flow directly from the mark id, bypassing the \n>heavy emc processing, including miniflow_extract.\n>\n>The association is done with CMAP in patch 1. It also reuses the flow \n>APIs introduced while adding the tc offloads. The emc bypassing is done \n>in patch 2. The flow offload is done in patch 4, which mainly does two\n>things:\n>\n>- translate the ovs match to DPDK rte flow patterns\n>- bind those patterns with a MARK action.\n>\n>Afterwards, the NIC will set the mark id in every pkt's mbuf when it \n>matches the flow. That's basically how we could get the flow directly \n>from the received mbuf.\n>\n>While testing with PHY-PHY forwarding with one core and one queue, I \n>got about 54% performance boost. For PHY-vhost forwarding, I got about \n>41% performance boost. The reason it's lower than v1 is I added the \n>logic to get the correct tcp_flags, which examines all packets recieved.\n>\n>The major issue mentioned in last version is also workarounded: the \n>queue index is never set to 0 blindly anymore, but set to the rxq that \n>first receives the upcall pkt.\n>\n>Note that it's disabled by default, which can be enabled by:\n>\n> $ ovs-vsctl set Open_vSwitch . other_config:hw-offload=true\n>\n>\n>v2: - workaround the queue action issue\n> - fixed the tcp_flags being skipped issue, which also fixed the\n> build warnings\n> - fixed l2 patterns for Intel nic\n> - Converted some macros to functions\n> - did not hardcode the max number of flow/action\n> - rebased on top of the lastest code\n>\n>Thanks.\n>\n> --yliu\n>\n>\n>---\n>Finn Christensen (3):\n> netdev-dpdk: implement flow put with rte flow\n> netdev-dpdk: retry with queue action\n> netdev-dpdk: set FDIR config\n>\n>Shachar Beiser (1):\n> dpif-netdev: record rx queue id for the upcall\n>\n>Yuanhan Liu (4):\n> dpif-netdev: associate flow with a mark id\n> dpif-netdev: retrieve flow directly from the flow mark\n> netdev-dpdk: convert ufid to dpdk flow\n> netdev-dpdk: remove offloaded flow on deletion\n>\n> lib/dp-packet.h | 14 ++\n> lib/dpif-netdev.c | 132 +++++++++++--\n> lib/flow.c | 78 ++++++++\n> lib/flow.h | 1 +\n> lib/netdev-dpdk.c | 574\n>+++++++++++++++++++++++++++++++++++++++++++++++++++++-\n> lib/netdev.c | 1 +\n> lib/netdev.h | 7 +\n> 7 files changed, 795 insertions(+), 12 deletions(-)\n>\n>--\n>2.7.4\n>\n\nHi all,\n\nCan you please confirm that you are supporting offloading of both the EMC\nflows and DPCLs (megaflows) here, i.e. OVS would skip hash table lookups\nin both the cases if UFID is provided in the MBUF. Assuming that is\ncorrect, when a match is found in dpcls, does OVS insert that new flow\nback into the EMC cache?\n\nThanks,\nHarish\n\n[Finn]\nYes, you are correct. Once the megaflow is offloaded into NIC, using the flow UFID, \nthe EMC and megaflow cache (dpcls) is skipped when a UFID is received in mbuf. When \nreceiving these pre-classified packets the EMC is not needed. However, the initial packet\ncreating the megaflow (and then also creates the NIC rte flow), will be inserted into EMC.\nBut, new flows that would use the same megaflow, but would create a different EMC entry,\nwill not be inserted/created in EMC when offloaded by NIC.\n\n\n\n>","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","dev@openvswitch.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","ovs-dev@mail.linuxfoundation.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=openvswitch.org\n\t(client-ip=140.211.169.12; helo=mail.linuxfoundation.org;\n\tenvelope-from=ovs-dev-bounces@openvswitch.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=napatech.com header.i=@napatech.com\n\theader.b=\"llH3XSjB\"; dkim-atps=neutral"],"Received":["from mail.linuxfoundation.org (mail.linuxfoundation.org\n\t[140.211.169.12])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xnDnQ2C3Qz9sNd\n\tfor ;\n\tWed, 6 Sep 2017 16:53:28 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id C20E8ABB;\n\tWed, 6 Sep 2017 06:53:24 +0000 (UTC)","from smtp1.linuxfoundation.org (smtp1.linux-foundation.org\n\t[172.17.192.35])\n\tby mail.linuxfoundation.org (Postfix) with ESMTPS id E6565A81\n\tfor ; Wed, 6 Sep 2017 06:53:22 +0000 (UTC)","from mail01.napatech.com (mail01.napatech.com [188.120.77.121])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1910920C\n\tfor ; Wed, 6 Sep 2017 06:53:19 +0000 (UTC)","from cph-gen-exch02.napatech.com (10.240.1.84) by\n\tcph-gen-exch02.napatech.com (10.240.1.84) with Microsoft SMTP Server\n\t(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id\n\t15.1.1034.26; Wed, 6 Sep 2017 08:53:12 +0200","from cph-gen-exch02.napatech.com ([fe80::581:51a1:ac3f:84e]) by\n\tcph-gen-exch02.napatech.com ([fe80::581:51a1:ac3f:84e%12]) with mapi\n\tid 15.01.1034.026; Wed, 6 Sep 2017 08:53:12 +0200"],"X-Greylist":"domain auto-whitelisted by SQLgrey-1.7.6","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=napatech.com; i=@napatech.com; q=dns/txt; s=mar2017;\n\tt=1504680800; x=1536216800;\n\th=from:to:cc:subject:date:message-id:references:\n\tin-reply-to:content-transfer-encoding:mime-version;\n\tbh=b14E79bsOcns48lWTZDGrT4QWqThmRd3IdpjuA7xMks=;\n\tb=llH3XSjBheRBUKhMVi8OKS6EwDo3Hnz7PnxQk/F0hpvdluDg56RkRg60\n\txgeYnE88V5tqFWyrEG1OQWKTbnuMyVTy6151YqLfqCN6Hpf7xMvOwvCPE\n\tW/DHuKiRoJ10ZiIWNt6TUCbE2pPplugDjS78mmc8jEeKMW+3e0Ui8IEp8\n\tN6wLSQD3Sch/BYgd3eRd2EBjeL1xVQ4E1GXQftjqlys+wprAp9RVV1yeW\n\tgPgrhvGv43GXnQhRI7iLU0Uj+/hIcWbu4ZG13wEcAcwrnS4nTuRXqPD6K\n\tn1afW06PMwBYIqmY16TSffX25T4ZKhf6Ql2FPQ0H00D5PsQ+QBhlLBZ35 A==;","IronPort-PHdr":"9a23:JPoP6RfbA/nTNu3T8NVi6s9OlGMj4u6mDksu8pMizoh2WeGdxcW7Yh7h7PlgxGXEQZ/co6odzbGH4ua6CCdZuMvJmUtBWaQEbwUCh8QSkl5oK+++Imq/EsTXaTcnFt9JTl5v8iLzG0FUHMHjew+a+SXqvnYdFRrlKAV6OPn+FJLMgMSrzeCy/IDYbxlViDanb75/KBG7oR/PusQSjoduN7s9xxvUqXZUZupawn9lK0iOlBjm/Mew+5Bj8yVUu/0/8sNLTLv3caclQ7FGFToqK2866tHluhnFVguP+2ATUn4KnRpSAgjK9w/1U5HsuSbnrOV92S2aPcrrTbAoXDmp8qlmRAP0hCoBKjU063/chNBug61HoRKhvx1/zJDSYIGJL/p1Y6fRccoHSWZdQspdUipMCZ6+YYQSFeoMJeZWoZfgqVsSoxWwBgesC+HuyjBUiXH50rY30/g6HgHEwAAsA84CvXbSod7oNKkSS+e1zKzQwDvDbvNW3zH945XWfxAhu/GMXKlwcdbPxkkpDAPKkFOQopHiMjObyusAqG6b4PB4Ve21l24otR1+oji1ysgwjYnJg5sYx1bZ/it62IY4PcC0RFJhbdK6H5ZcqzuWO5ZsTs4hTGxkoDs2xqEctZKlcyUG1I4ryh7DZ/CdcYWE/ArvVOiPLjp7mH5ofbeyihax/ES9z+DxVtS430xXoidAiNbDqn4A1xLW58WERfZy4EGs0iuV2Q/J8OFLO0U0mLLeK54m37E/iIIesV/GHi/qgEX2i7KWdlk89uio9evnZrLmq4eZN4BuiwH+Nr4imsqlDuQgKAcOQ3aU9vi81LH54UL5R7BKguU3kqnfrp/aOdwWqrOlDwNPzIou5AqzAy273NgCnnQKI0pJeBedgIjoP1HOLur4DfC6g1m0njdk2+vLPrv7DZXVNHfDjKnucqp960JG1AUzytVf64pOCr4dOPLzRlPxtNvAAxAkLQO03f3qCNJl1owAX2KPHLSZMa3TsV+U+u0vI/OAZIgPuDbyeLAZ4KuktXYlmFtZNYmgx5oMaDrwStRvOUSCYTzUi8sAFU8BtxQ/Uemsg1qHB3obVmu7WaI14HkfCZ/uWZbHR52FjqaA0C6qGpxQe3AADUqDRzOgPYmJRd8LcC+UPNR+kyAPVf6mUYBrnUWiuRHSzKJqKPTP5SwEvpKl08J6sb79jxY3oBJ1CcLV+GGXTnpok2UTSjl+iK50iUp00l6f3KN4xfdfEIoAtLtyTg4mOMuEnKRBANfoV1eEJ4/RRQ==","X-IronPort-Anti-Spam-Filtered":"true","X-IronPort-Anti-Spam-Result":"A2HxAADOmq9Z/1QB8ApeGwEBAQMBAQEJAQEBFgEBAQMBAQEJAQEBhSgHg3CKIZISliiCEgqFPgIahFwYAQEBAQEBAQEBAQECgRCCMyQBgkABAQEBAyMRRQwEAgEIEQMBAQEDAiMDAgICMBQBCAgCBAENBQi5FYInizkBAQEBAQEBAQEBAQEBAQEBAQEBH4ENgh2DUIFjgyiEPoNKgmEFoHSUSIIchWeKd0iUNgICAgIJAhqBOR+BRncVhWABHIFndodogTKBDwEBAQ","X-IPAS-Result":"A2HxAADOmq9Z/1QB8ApeGwEBAQMBAQEJAQEBFgEBAQMBAQEJAQEBhSgHg3CKIZISliiCEgqFPgIahFwYAQEBAQEBAQEBAQECgRCCMyQBgkABAQEBAyMRRQwEAgEIEQMBAQEDAiMDAgICMBQBCAgCBAENBQi5FYInizkBAQEBAQEBAQEBAQEBAQEBAQEBH4ENgh2DUIFjgyiEPoNKgmEFoHSUSIIchWeKd0iUNgICAgIJAhqBOR+BRncVhWABHIFndodogTKBDwEBAQ","From":"Finn Christensen ","To":"\"Patil, Harish\" , Yuanhan Liu\n\t, \"dev@openvswitch.org\" ","Thread-Topic":"[ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow","Thread-Index":"AQHTJii1zjhlS/sxs0C3LJbJw2fqwqKnRkUAgAAjvMA=","Date":"Wed, 6 Sep 2017 06:53:12 +0000","Message-ID":"","References":"<1504603381-30071-1-git-send-email-yliu@fridaylinux.org>\n\t","In-Reply-To":"","Accept-Language":"da-DK, en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","x-originating-ip":"[10.240.50.72]","MIME-Version":"1.0","X-Spam-Status":"No, score=-2.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,\n\tDKIM_VALID_AU,RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD autolearn=disabled\n\tversion=3.3.1","X-Spam-Checker-Version":"SpamAssassin 3.3.1 (2010-03-16) on\n\tsmtp1.linux-foundation.org","Subject":"Re: [ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow","X-BeenThere":"ovs-dev@openvswitch.org","X-Mailman-Version":"2.1.12","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"ovs-dev-bounces@openvswitch.org","Errors-To":"ovs-dev-bounces@openvswitch.org"}},{"id":1764891,"web_url":"http://patchwork.ozlabs.org/comment/1764891/","msgid":"","list_archive_url":null,"date":"2017-09-07T18:52:49","subject":"Re: [ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow","submitter":{"id":72097,"url":"http://patchwork.ozlabs.org/api/people/72097/","name":"Patil, Harish","email":"Harish.Patil@cavium.com"},"content":"-----Original Message-----\r\nFrom: Finn Christensen \r\nDate: Tuesday, September 5, 2017 at 11:53 PM\r\nTo: Harish Patil , Yuanhan Liu\r\n, \"dev@openvswitch.org\" \r\nCc: \"dball@vmware.com\" \r\nSubject: RE: [ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow\r\n\r\n>\r\n>-----Original Message-----\r\n>From: Patil, Harish [mailto:Harish.Patil@cavium.com]\r\n>Sent: 6. september 2017 08:34\r\n>To: Yuanhan Liu ; dev@openvswitch.org\r\n>Cc: Finn Christensen ; dball@vmware.com\r\n>Subject: Re: [ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow\r\n>\r\n>\r\n>\r\n>-----Original Message-----\r\n>From: on behalf of Yuanhan Liu\r\n>\r\n>Date: Tuesday, September 5, 2017 at 2:22 AM\r\n>To: \"dev@openvswitch.org\" \r\n>Subject: [ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow\r\n>\r\n>>Hi,\r\n>>\r\n>>Here is a joint work from Mellanox and Napatech, to enable the flow hw\r\n>>offload with the DPDK generic flow interface (rte_flow).\r\n>>\r\n>>The basic idea is to associate the flow with a mark id (a unit32_t\r\n>>number).\r\n>>Later, we then get the flow directly from the mark id, bypassing the\r\n>>heavy emc processing, including miniflow_extract.\r\n>>\r\n>>The association is done with CMAP in patch 1. It also reuses the flow\r\n>>APIs introduced while adding the tc offloads. The emc bypassing is done\r\n>>in patch 2. The flow offload is done in patch 4, which mainly does two\r\n>>things:\r\n>>\r\n>>- translate the ovs match to DPDK rte flow patterns\r\n>>- bind those patterns with a MARK action.\r\n>>\r\n>>Afterwards, the NIC will set the mark id in every pkt's mbuf when it\r\n>>matches the flow. That's basically how we could get the flow directly\r\n>>from the received mbuf.\r\n>>\r\n>>While testing with PHY-PHY forwarding with one core and one queue, I\r\n>>got about 54% performance boost. For PHY-vhost forwarding, I got about\r\n>>41% performance boost. The reason it's lower than v1 is I added the\r\n>>logic to get the correct tcp_flags, which examines all packets recieved.\r\n>>\r\n>>The major issue mentioned in last version is also workarounded: the\r\n>>queue index is never set to 0 blindly anymore, but set to the rxq that\r\n>>first receives the upcall pkt.\r\n>>\r\n>>Note that it's disabled by default, which can be enabled by:\r\n>>\r\n>> $ ovs-vsctl set Open_vSwitch . other_config:hw-offload=true\r\n>>\r\n>>\r\n>>v2: - workaround the queue action issue\r\n>> - fixed the tcp_flags being skipped issue, which also fixed the\r\n>> build warnings\r\n>> - fixed l2 patterns for Intel nic\r\n>> - Converted some macros to functions\r\n>> - did not hardcode the max number of flow/action\r\n>> - rebased on top of the lastest code\r\n>>\r\n>>Thanks.\r\n>>\r\n>> --yliu\r\n>>\r\n>>\r\n>>---\r\n>>Finn Christensen (3):\r\n>> netdev-dpdk: implement flow put with rte flow\r\n>> netdev-dpdk: retry with queue action\r\n>> netdev-dpdk: set FDIR config\r\n>>\r\n>>Shachar Beiser (1):\r\n>> dpif-netdev: record rx queue id for the upcall\r\n>>\r\n>>Yuanhan Liu (4):\r\n>> dpif-netdev: associate flow with a mark id\r\n>> dpif-netdev: retrieve flow directly from the flow mark\r\n>> netdev-dpdk: convert ufid to dpdk flow\r\n>> netdev-dpdk: remove offloaded flow on deletion\r\n>>\r\n>> lib/dp-packet.h | 14 ++\r\n>> lib/dpif-netdev.c | 132 +++++++++++--\r\n>> lib/flow.c | 78 ++++++++\r\n>> lib/flow.h | 1 +\r\n>> lib/netdev-dpdk.c | 574\r\n>>+++++++++++++++++++++++++++++++++++++++++++++++++++++-\r\n>> lib/netdev.c | 1 +\r\n>> lib/netdev.h | 7 +\r\n>> 7 files changed, 795 insertions(+), 12 deletions(-)\r\n>>\r\n>>--\r\n>>2.7.4\r\n>>\r\n>\r\n>Hi all,\r\n>\r\n>Can you please confirm that you are supporting offloading of both the EMC\r\n>flows and DPCLs (megaflows) here, i.e. OVS would skip hash table lookups\r\n>in both the cases if UFID is provided in the MBUF. Assuming that is\r\n>correct, when a match is found in dpcls, does OVS insert that new flow\r\n>back into the EMC cache?\r\n>\r\n>Thanks,\r\n>Harish\r\n>\r\n>[Finn]\r\n>Yes, you are correct. Once the megaflow is offloaded into NIC, using the\r\n>flow UFID,\r\n>the EMC and megaflow cache (dpcls) is skipped when a UFID is received in\r\n>mbuf. When\r\n>receiving these pre-classified packets the EMC is not needed. However,\r\n>the initial packet\r\n>creating the megaflow (and then also creates the NIC rte flow), will be\r\n>inserted into EMC.\r\n\r\n[Harish] Thanks Finn for confirming the behavior.\r\n\r\n\r\n>But, new flows that would use the same megaflow, but would create a\r\n>different EMC entry,\r\n>will not be inserted/created in EMC when offloaded by NIC.\r\n\r\n[Harish I did not fully understand this part. Can you pls elaborate and\r\npossibly with an example?\r\n\r\n[Harish] I have another question:\r\nThere was a patch series (11/11) submitted regarding offloading dpcls from\r\nShachar Beiser.\r\n\r\n[ovs-dev] [PATCH 00/11] Data Path Classifier Offloading\r\n..\r\n..\r\n[ovs-dev] [PATCH 11/11] ovs/dp-cls: inserting rule to HW from\toffloading\r\nthread context.\r\n\r\n\r\nThis does not use RTE_FLOW filtering framework. I don’t know status of\r\nthis patch series.\r\nBut this is very similar to what is being achieved with your current patch\r\nseries using RTE_FLOW.\r\nWhich one will be accepted in the end in the mainline OVS branch?\r\n\r\nThanks,\r\nHarish\r\n>","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","dev@openvswitch.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","ovs-dev@mail.linuxfoundation.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=openvswitch.org\n\t(client-ip=140.211.169.12; helo=mail.linuxfoundation.org;\n\tenvelope-from=ovs-dev-bounces@openvswitch.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=CAVIUMNETWORKS.onmicrosoft.com\n\theader.i=@CAVIUMNETWORKS.onmicrosoft.com header.b=\"LMgQfkxh\"; \n\tdkim-atps=neutral","spf=none (sender IP is )\n\tsmtp.mailfrom=Harish.Patil@cavium.com; "],"Received":["from mail.linuxfoundation.org (mail.linuxfoundation.org\n\t[140.211.169.12])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xp8j7124Yz9sBW\n\tfor ;\n\tFri, 8 Sep 2017 04:52:58 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id A0A54A7F;\n\tThu, 7 Sep 2017 18:52:54 +0000 (UTC)","from smtp1.linuxfoundation.org (smtp1.linux-foundation.org\n\t[172.17.192.35])\n\tby mail.linuxfoundation.org (Postfix) with ESMTPS id 47C8C8E3\n\tfor ; Thu, 7 Sep 2017 18:52:53 +0000 (UTC)","from NAM02-CY1-obe.outbound.protection.outlook.com\n\t(mail-cys01nam02on0068.outbound.protection.outlook.com\n\t[104.47.37.68])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id 80D1AE5\n\tfor ; Thu, 7 Sep 2017 18:52:52 +0000 (UTC)","from MWHPR07MB3184.namprd07.prod.outlook.com (10.172.96.142) by\n\tMWHPR07MB2797.namprd07.prod.outlook.com (10.169.230.135) with\n\tMicrosoft SMTP Server (version=TLS1_2,\n\tcipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id\n\t15.20.35.12; Thu, 7 Sep 2017 18:52:50 +0000","from MWHPR07MB3184.namprd07.prod.outlook.com ([10.172.96.142]) by\n\tMWHPR07MB3184.namprd07.prod.outlook.com ([10.172.96.142]) with\n\tmapi id 15.20.0013.018; Thu, 7 Sep 2017 18:52:50 +0000"],"X-Greylist":"whitelisted by SQLgrey-1.7.6","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com;\n\th=From:Date:Subject:Message-ID:Content-Type:MIME-Version;\n\tbh=8JvICXbS4Du7yA/YUJOY51LEN9CiCmx8azjYY8TyUW8=;\n\tb=LMgQfkxhbMAGlvJ7b+yIvJoXsUvcPOITbwhnV7cyMbl4cGwfqX78mOOO9neCJ1JbZ3zQQAbVX/n6GHKgQTZq5ROjyv+mmm6Gixcke7bdSk8M5WkbSHVZZGMZ8RjpxTVZHk0kJEzEdYEfeClXQC+t28C5kHQ0C6UPuPvZ68zwoqs=","From":"\"Patil, Harish\" ","To":"Finn Christensen , Yuanhan Liu , \n\t\"dev@openvswitch.org\" ","Thread-Topic":"[ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow","Thread-Index":"AQHTJiis1qmE8mZPnEmWdPSqy/YW+aKm8nEAgAB62gCAAeYIgA==","Date":"Thu, 7 Sep 2017 18:52:49 +0000","Message-ID":"","References":"<1504603381-30071-1-git-send-email-yliu@fridaylinux.org>\n\t\n\t","In-Reply-To":"","Accept-Language":"en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","authentication-results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=openvswitch.org\n\t(client-ip=140.211.169.12; helo=mail.linuxfoundation.org;\n\tenvelope-from=ovs-dev-bounces@openvswitch.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=CAVIUMNETWORKS.onmicrosoft.com\n\theader.i=@CAVIUMNETWORKS.onmicrosoft.com header.b=\"LMgQfkxh\"; \n\tdkim-atps=neutral","spf=none (sender IP is )\n\tsmtp.mailfrom=Harish.Patil@cavium.com; "],"x-originating-ip":"[198.186.0.2]","x-ms-publictraffictype":"Email","x-microsoft-exchange-diagnostics":"1; MWHPR07MB2797;\n\t6:CKRYnW//R+tvLN1raRxuUOio+DBZUdukgD58FHgj1jL7MX5/6wOs63ovKVuJPpXAEfa83ApG8f/qHAsoge3y3CxQk/YpH0q0suW2mRBRn/vlWnKGGHNOhiL3JDGTdNwvXzTO/LAb4G1v56f4ySIDZHcyhj+PIhaRutxtmWyXrnshDMWxN5nK1ZCm8W4UbM29mf3u9Ivg/OVNXwCjqhRYoYFZBAnpebtbQ4zbs6j0Aib8tMNFJ+EEYf2Sb8xVIUkU6VhOY5nx5fdA8Kh/Kzu5HyMHlD5MhzrNmeo6GmcR+w++pdT5lYDR4SJZy1HCRCzOl8mGOFqrJ6RdLhAFGuOMLw==;\n\t5:KGf9jOxpdXU2af+YVMO+/WMyUOOpFtpZI8yb9S8+9WeQMzaA3lwTtDLE5uHs+BnCAtGzIKd9DyBnCnZ+KHNjDjVDAT6zZCptGt17ieKzeZCyHf0JUwfWQ5xEnBBjRc1pbK3o5zHaF9GUSMI2UzJPrg==;\n\t24:lCc8FPK/BNpqSTYrEEQpFHJsjBS/+faaSaaw5tN1VM5XUhLQbsIyS743fE7N1sSzH0Snxu789W6QuUBhbMojCLjYJWo5t/0Z7wR6DKSB1Sc=;\n\t7:I53kfzL1Ev0DqngjR84vreecJXl87VRE+xj+vJHzPW3sT94dpWOja4QBiLj86jRHUbnSvWlik6cMZLXvjlf420sfzy/U8WiouuP79dxm3eIO7Dm6DXDzaWWRCX7+UfyQk0/gv7MqlN6XUnCBGmRM6JC93pVmA2ydp2u3/ZD4vbP5+JsLiWnV1SZh/2wPDi8/gaCfTzrDjHcTwC7nyaoDxw3j9fXyfIrVTIDoH2222Cg=","x-ms-exchange-antispam-srfa-diagnostics":"SSOS;","x-ms-office365-filtering-correlation-id":"04d58c55-b2c3-457e-35a0-08d4f621a367","x-microsoft-antispam":"UriScan:; BCL:0; PCL:0;\n\tRULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);\n\tSRVR:MWHPR07MB2797; ","x-ms-traffictypediagnostic":"MWHPR07MB2797:","x-exchange-antispam-report-test":"UriScan:(61668805478150)(216315784871565);","x-microsoft-antispam-prvs":"","x-exchange-antispam-report-cfa-test":"BCL:0; PCL:0;\n\tRULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);\n\tSRVR:MWHPR07MB2797; BCL:0; PCL:0;\n\tRULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);\n\tSRVR:MWHPR07MB2797; ","x-forefront-prvs":"04238CD941","x-forefront-antispam-report":"SFV:NSPM;\n\tSFS:(10009020)(6009001)(13464003)(53754006)(189002)(377454003)(199003)(2906002)(76176999)(105586002)(54356999)(50986999)(66066001)(86362001)(36756003)(2950100002)(8936002)(8676002)(478600001)(81156014)(81166006)(106356001)(101416001)(229853002)(68736007)(53546010)(189998001)(6512007)(3846002)(7736002)(305945005)(72206003)(99286003)(4326008)(6116002)(3280700002)(2501003)(25786009)(14454004)(6436002)(6506006)(6486002)(53936002)(102836003)(3660700001)(6246003)(77096006)(2900100001)(5660300001)(97736004);\n\tDIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR07MB2797;\n\tH:MWHPR07MB3184.namprd07.prod.outlook.com; FPR:; SPF:None;\n\tPTR:InfoNoRecords; MX:1; A:1; LANG:en; ","received-spf":"None (protection.outlook.com: cavium.com does not designate\n\tpermitted sender hosts)","spamdiagnosticoutput":"1:99","spamdiagnosticmetadata":"NSPM","Content-ID":"<481BD666913BEE4CADC6DA40651328F7@namprd07.prod.outlook.com>","MIME-Version":"1.0","X-OriginatorOrg":"cavium.com","X-MS-Exchange-CrossTenant-originalarrivaltime":"07 Sep 2017 18:52:49.9855\n\t(UTC)","X-MS-Exchange-CrossTenant-fromentityheader":"Hosted","X-MS-Exchange-CrossTenant-id":"711e4ccf-2e9b-4bcf-a551-4094005b6194","X-MS-Exchange-Transport-CrossTenantHeadersStamped":"MWHPR07MB2797","X-Spam-Status":"No, score=0.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,\n\tRCVD_IN_DNSWL_NONE autolearn=disabled version=3.3.1","X-Spam-Checker-Version":"SpamAssassin 3.3.1 (2010-03-16) on\n\tsmtp1.linux-foundation.org","Subject":"Re: [ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow","X-BeenThere":"ovs-dev@openvswitch.org","X-Mailman-Version":"2.1.12","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Sender":"ovs-dev-bounces@openvswitch.org","Errors-To":"ovs-dev-bounces@openvswitch.org"}},{"id":1765037,"web_url":"http://patchwork.ozlabs.org/comment/1765037/","msgid":"<20170908015851.GD9736@yliu-home>","list_archive_url":null,"date":"2017-09-08T01:58:51","subject":"Re: [ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow","submitter":{"id":72215,"url":"http://patchwork.ozlabs.org/api/people/72215/","name":"Yuanhan Liu","email":"yliu@fridaylinux.org"},"content":"On Thu, Sep 07, 2017 at 06:52:49PM +0000, Patil, Harish wrote:\n> >Hi all,\n> >\n> >Can you please confirm that you are supporting offloading of both the EMC\n> >flows and DPCLs (megaflows) here, i.e. OVS would skip hash table lookups\n> >in both the cases if UFID is provided in the MBUF. Assuming that is\n> >correct, when a match is found in dpcls, does OVS insert that new flow\n> >back into the EMC cache?\n> >\n> >Thanks,\n> >Harish\n> >\n> >[Finn]\n> >Yes, you are correct. Once the megaflow is offloaded into NIC, using the\n> >flow UFID,\n> >the EMC and megaflow cache (dpcls) is skipped when a UFID is received in\n> >mbuf. When\n> >receiving these pre-classified packets the EMC is not needed. However,\n> >the initial packet\n> >creating the megaflow (and then also creates the NIC rte flow), will be\n> >inserted into EMC.\n> \n> [Harish] Thanks Finn for confirming the behavior.\n> \n> \n> >But, new flows that would use the same megaflow, but would create a\n> >different EMC entry,\n> >will not be inserted/created in EMC when offloaded by NIC.\n> \n> [Harish I did not fully understand this part. Can you pls elaborate and\n> possibly with an example?\n\nIt's megaflow cache being offloaded. And the EMC is skipped completely\nonce there are flow mark in the recved pkts. Thus, it doesn't matter\nwhether EMC will be inserted back.\n\nTalking about that, I probably need move the \"mark -> flow\" code to\ndpcls but not in emc_processing. Darrel, just let me know which one\nyou prefer.\n\n> [Harish] I have another question:\n> There was a patch series (11/11) submitted regarding offloading dpcls from\n> Shachar Beiser.\n> \n> [ovs-dev] [PATCH 00/11] Data Path Classifier Offloading\n> ..\n> ..\n> [ovs-dev] [PATCH 11/11] ovs/dp-cls: inserting rule to HW from\toffloading\n> thread context.\n> \n> \n> This does not use RTE_FLOW filtering framework. I don’t know status of\n> this patch series.\n> But this is very similar to what is being achieved with your current patch\n> series using RTE_FLOW.\n> Which one will be accepted in the end in the mainline OVS branch?\n\nAs it's been stated in the first sentence of my cover letter, it's a\njoint work from Mellanox and Napatech. Shachar (who is from Mellanox)\ndoes't have time to work on this project anymore, leaving me (who is\nalso from Mellanox) to continue the work. And then my choice was to\ncontinue it based on what Napatech already had, for a simple reason:\nit's simpler.\n\nOTOH, do you see anything missing in this patchset, comparing the one\nfrom Shachar?\n\n\t--yliu","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","dev@openvswitch.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","ovs-dev@mail.linuxfoundation.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=openvswitch.org\n\t(client-ip=140.211.169.12; helo=mail.linuxfoundation.org;\n\tenvelope-from=ovs-dev-bounces@openvswitch.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=fridaylinux-org.20150623.gappssmtp.com\n\theader.i=@fridaylinux-org.20150623.gappssmtp.com\n\theader.b=\"1kDT/moK\"; dkim-atps=neutral"],"Received":["from mail.linuxfoundation.org (mail.linuxfoundation.org\n\t[140.211.169.12])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xpL8n1btGz9sDB\n\tfor ;\n\tFri, 8 Sep 2017 11:59:05 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id 594D9ACC;\n\tFri, 8 Sep 2017 01:59:02 +0000 (UTC)","from smtp1.linuxfoundation.org (smtp1.linux-foundation.org\n\t[172.17.192.35])\n\tby mail.linuxfoundation.org (Postfix) with ESMTPS id 8BF92A91\n\tfor ; Fri, 8 Sep 2017 01:59:01 +0000 (UTC)","from mail-pg0-f51.google.com (mail-pg0-f51.google.com\n\t[74.125.83.51])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id 23018101\n\tfor ; Fri, 8 Sep 2017 01:59:01 +0000 (UTC)","by mail-pg0-f51.google.com with SMTP id m9so2488238pgd.3\n\tfor ; Thu, 07 Sep 2017 18:59:01 -0700 (PDT)","from yliu-home ([45.63.61.64]) by smtp.gmail.com with ESMTPSA id\n\ts8sm845844pgf.78.2017.09.07.18.58.57\n\t(version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);\n\tThu, 07 Sep 2017 18:58:59 -0700 (PDT)"],"X-Greylist":"whitelisted by SQLgrey-1.7.6","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=fridaylinux-org.20150623.gappssmtp.com; s=20150623;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:content-transfer-encoding:in-reply-to\n\t:user-agent; bh=SN0ajbajJFraA/3LOUU3hkefI9ieW32Qr/PgFMP+eqw=;\n\tb=1kDT/moKfcBc0rTtnSljge1zP403GJC+AgAGc2jiQ/il4N7QECBj55Fs6c0WRuJye8\n\tCYN2vz8UCr+kAHflHI8LS6o323Ha5d6zDBUBjxKePqw3/fCopmz2srk4fj7pEltSOlxf\n\tdMXIKi8wR/29mWU/bMSez2RMkGVD4b2hztopSjPSbVawi3hmk9LqC9QB3nhp5rm4vVGd\n\tMmIGgmbFB6yB2rp5U5n6GE+bbsrZR4rkkrG2GC5LPGIk7pVmXheHcbLsBPfqQPE+RLz4\n\t4KOj7Azu71PvWdKVOWOWXW6jJfH3UUG2A7dIEqDbzCmN2uDF+GUTsUIZbpQGMT7UhBcB\n\tJA9w==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:content-transfer-encoding\n\t:in-reply-to:user-agent;\n\tbh=SN0ajbajJFraA/3LOUU3hkefI9ieW32Qr/PgFMP+eqw=;\n\tb=HFIyM0vY0PPdTqmh0tgQhalFsgfCNBmI8lQU0uGbmbLdsnc0sqNo7PrLlLT/VtyHGl\n\t7ZuoD8pAFm7mGXLrzAMHjMOtc6PuXAzP9L/XSIQQSIBaVMYftSiY0CFMI38VScwNu6WV\n\tjH9zpj1+JO7LULVC+5SakGwg1LS92ICnIqS9WOv96boF0ZsvL/9f13CYX5m3+mCNRKL5\n\t/hXMu9Qs/WyI5rVXLqZX3TlO/E7HqfTSOTpOktaN8GbuU0PMYsZvll9kEPl/cmCNekFr\n\tg7C9OXkYZ2B/TzX7V36UH7R0cSJoXsHxVZCap6EnFqCxsvCVSxJfcAdc0ckjktkDX/mM\n\tRucA==","X-Gm-Message-State":"AHPjjUjgMFnk1yG6NQjJgw83d7RNh2rYP4BefagvL8P+arl6cG4ko/Ih\n\tRdp314P/dxlQAEYrmTM17w==","X-Google-Smtp-Source":"ADKCNb6kTjc3S+YYzeg4TrXxGK4wVyf9MyNMaS1JWX894aTsE+bIiHIKkhhyJDn2oR6Sc3W/X76EcA==","X-Received":"by 10.101.72.65 with SMTP id i1mr1473050pgs.184.1504835940563;\n\tThu, 07 Sep 2017 18:59:00 -0700 (PDT)","Date":"Fri, 8 Sep 2017 09:58:51 +0800","From":"Yuanhan Liu ","To":"\"Patil, Harish\" ","Message-ID":"<20170908015851.GD9736@yliu-home>","References":"<1504603381-30071-1-git-send-email-yliu@fridaylinux.org>\n\t\n\t\n\t","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"Mutt/1.5.24 (2015-08-30)","X-Spam-Status":"No, score=0.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,\n\tRCVD_IN_DNSWL_NONE,\n\tRCVD_IN_SORBS_SPAM autolearn=disabled version=3.3.1","X-Spam-Checker-Version":"SpamAssassin 3.3.1 (2010-03-16) on\n\tsmtp1.linux-foundation.org","Cc":"\"dev@openvswitch.org\" ","Subject":"Re: [ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow","X-BeenThere":"ovs-dev@openvswitch.org","X-Mailman-Version":"2.1.12","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Sender":"ovs-dev-bounces@openvswitch.org","Errors-To":"ovs-dev-bounces@openvswitch.org"}},{"id":1765595,"web_url":"http://patchwork.ozlabs.org/comment/1765595/","msgid":"<4F93F2C0-BE57-4754-B0EA-25F9B8A99C00@vmware.com>","list_archive_url":null,"date":"2017-09-08T19:29:48","subject":"Re: [ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow","submitter":{"id":68212,"url":"http://patchwork.ozlabs.org/api/people/68212/","name":"Darrell Ball","email":"dball@vmware.com"},"content":"Hi Yuanhan\r\n\r\nIn the dpdk public meeting, we requested Simon to also review this series to check\r\nthat it is sync with the HWOL for kernel with respect to one or two high level aspects.\r\nI had some comments related to coding standards for V2, but I’ll wait for you to respond\r\nto Simon’s comments before adding my own other comments, in order to avoid confusion.\r\n\r\nThanks Darrell\r\n \r\n\r\nOn 9/5/17, 2:22 AM, \"Yuanhan Liu\" wrote:\r\n\r\n Hi,\r\n \r\n Here is a joint work from Mellanox and Napatech, to enable the flow hw\r\n offload with the DPDK generic flow interface (rte_flow).\r\n \r\n The basic idea is to associate the flow with a mark id (a unit32_t number).\r\n Later, we then get the flow directly from the mark id, bypassing the heavy\r\n emc processing, including miniflow_extract.\r\n \r\n The association is done with CMAP in patch 1. It also reuses the flow\r\n APIs introduced while adding the tc offloads. The emc bypassing is done\r\n in patch 2. The flow offload is done in patch 4, which mainly does two\r\n things:\r\n \r\n - translate the ovs match to DPDK rte flow patterns\r\n - bind those patterns with a MARK action.\r\n \r\n Afterwards, the NIC will set the mark id in every pkt's mbuf when it\r\n matches the flow. That's basically how we could get the flow directly\r\n from the received mbuf.\r\n \r\n While testing with PHY-PHY forwarding with one core and one queue, I got\r\n about 54% performance boost. For PHY-vhost forwarding, I got about 41%\r\n performance boost. The reason it's lower than v1 is I added the logic\r\n to get the correct tcp_flags, which examines all packets recieved.\r\n \r\n The major issue mentioned in last version is also workarounded: the\r\n queue index is never set to 0 blindly anymore, but set to the rxq that\r\n first receives the upcall pkt.\r\n \r\n Note that it's disabled by default, which can be enabled by:\r\n \r\n $ ovs-vsctl set Open_vSwitch . other_config:hw-offload=true\r\n \r\n \r\n v2: - workaround the queue action issue\r\n - fixed the tcp_flags being skipped issue, which also fixed the\r\n build warnings\r\n - fixed l2 patterns for Intel nic\r\n - Converted some macros to functions\r\n - did not hardcode the max number of flow/action\r\n - rebased on top of the lastest code\r\n \r\n Thanks.\r\n \r\n --yliu\r\n \r\n \r\n ---\r\n Finn Christensen (3):\r\n netdev-dpdk: implement flow put with rte flow\r\n netdev-dpdk: retry with queue action\r\n netdev-dpdk: set FDIR config\r\n \r\n Shachar Beiser (1):\r\n dpif-netdev: record rx queue id for the upcall\r\n \r\n Yuanhan Liu (4):\r\n dpif-netdev: associate flow with a mark id\r\n dpif-netdev: retrieve flow directly from the flow mark\r\n netdev-dpdk: convert ufid to dpdk flow\r\n netdev-dpdk: remove offloaded flow on deletion\r\n \r\n lib/dp-packet.h | 14 ++\r\n lib/dpif-netdev.c | 132 +++++++++++--\r\n lib/flow.c | 78 ++++++++\r\n lib/flow.h | 1 +\r\n lib/netdev-dpdk.c | 574 +++++++++++++++++++++++++++++++++++++++++++++++++++++-\r\n lib/netdev.c | 1 +\r\n lib/netdev.h | 7 +\r\n 7 files changed, 795 insertions(+), 12 deletions(-)\r\n \r\n -- \r\n 2.7.4","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","dev@openvswitch.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","ovs-dev@mail.linuxfoundation.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=openvswitch.org\n\t(client-ip=140.211.169.12; helo=mail.linuxfoundation.org;\n\tenvelope-from=ovs-dev-bounces@openvswitch.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=onevmw.onmicrosoft.com\n\theader.i=@onevmw.onmicrosoft.com header.b=\"SeB006fT\"; \n\tdkim-atps=neutral","spf=none (sender IP is )\n\tsmtp.mailfrom=dball@vmware.com; "],"Received":["from mail.linuxfoundation.org (mail.linuxfoundation.org\n\t[140.211.169.12])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xpnTH1xclz9sRV\n\tfor ;\n\tSat, 9 Sep 2017 05:29:55 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id 1DCF8CB9;\n\tFri, 8 Sep 2017 19:29:53 +0000 (UTC)","from smtp1.linuxfoundation.org (smtp1.linux-foundation.org\n\t[172.17.192.35])\n\tby mail.linuxfoundation.org (Postfix) with ESMTPS id 6584DCB9\n\tfor ; Fri, 8 Sep 2017 19:29:52 +0000 (UTC)","from NAM01-BN3-obe.outbound.protection.outlook.com\n\t(mail-bn3nam01on0055.outbound.protection.outlook.com [104.47.33.55])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id ACF49442\n\tfor ; Fri, 8 Sep 2017 19:29:51 +0000 (UTC)","from BLUPR05MB611.namprd05.prod.outlook.com (10.141.204.27) by\n\tBLUPR05MB1905.namprd05.prod.outlook.com (10.162.215.155) with\n\tMicrosoft SMTP Server (version=TLS1_2,\n\tcipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id\n\t15.20.56.4; Fri, 8 Sep 2017 19:29:48 +0000","from BLUPR05MB611.namprd05.prod.outlook.com ([10.141.204.27]) by\n\tBLUPR05MB611.namprd05.prod.outlook.com ([10.141.204.27]) with mapi id\n\t15.20.0056.003; Fri, 8 Sep 2017 19:29:48 +0000"],"X-Greylist":"whitelisted by SQLgrey-1.7.6","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=onevmw.onmicrosoft.com; s=selector1-vmware-com;\n\th=From:Date:Subject:Message-ID:Content-Type:MIME-Version;\n\tbh=VeMZzWFj4Tx1Gsef53C7MvdIh8i+buWOCx0hiwlrgqs=;\n\tb=SeB006fTgT7H+zz7P8B1xu3IyipIWn7wfjylfulFPZ609Zz+SVgEBMl7Icr2szQYYI033lr3CSwkzktdDC4GLp6Y/03dHbAvudueFupDhybALevjzymOy7XwJtcsSLRFre4uyb3bUaEzDzV7dzZjliBRb/KnTHkOyqE4MAjc/Ec=","From":"Darrell Ball ","To":"Yuanhan Liu , \"dev@openvswitch.org\"\n\t","Thread-Topic":"[PATCH v2 0/8] OVS-DPDK flow offload with rte_flow","Thread-Index":"AQHTJiipBu7FvFt0oUWvIx2Z7IEtEqKq7/+A","Date":"Fri, 8 Sep 2017 19:29:48 +0000","Message-ID":"<4F93F2C0-BE57-4754-B0EA-25F9B8A99C00@vmware.com>","References":"<1504603381-30071-1-git-send-email-yliu@fridaylinux.org>","In-Reply-To":"<1504603381-30071-1-git-send-email-yliu@fridaylinux.org>","Accept-Language":"en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","user-agent":"Microsoft-MacOutlook/f.23.0.170610","x-originating-ip":"[73.162.236.45]","x-ms-publictraffictype":"Email","x-microsoft-exchange-diagnostics":"1; BLUPR05MB1905;\n\t20:2mg7Aw7Rhvh20ATkmX8mdtAy6aLDdLZyUHrdzQDxKwkJ2USppfxbKCpqDlyGus3kP+CCWLU6LRGS4XweB/wDuFrfYXtJ10ZotRbSHvFqCXiErEB3nFMGV9JZQ04lq2oI2B8kTcA+xj/Fm0rb4QNTvKGnEsi2TZvJeVrmt5kHvr8=","x-ms-exchange-antispam-srfa-diagnostics":"SSOS;","x-ms-office365-filtering-correlation-id":"57bae700-0a3c-4635-3a3c-08d4f6eff84a","x-microsoft-antispam":"UriScan:; BCL:0; PCL:0;\n\tRULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);\n\tSRVR:BLUPR05MB1905; ","x-ms-traffictypediagnostic":"BLUPR05MB1905:","authentication-results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=openvswitch.org\n\t(client-ip=140.211.169.12; helo=mail.linuxfoundation.org;\n\tenvelope-from=ovs-dev-bounces@openvswitch.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=onevmw.onmicrosoft.com\n\theader.i=@onevmw.onmicrosoft.com header.b=\"SeB006fT\"; \n\tdkim-atps=neutral","spf=none (sender IP is )\n\tsmtp.mailfrom=dball@vmware.com; "],"x-exchange-antispam-report-test":"UriScan:;","x-microsoft-antispam-prvs":"","x-exchange-antispam-report-cfa-test":"BCL:0; PCL:0;\n\tRULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123562025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);\n\tSRVR:BLUPR05MB1905; BCL:0; PCL:0;\n\tRULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);\n\tSRVR:BLUPR05MB1905; ","x-forefront-prvs":"04244E0DC5","x-forefront-antispam-report":"SFV:NSPM;\n\tSFS:(10009020)(6009001)(39860400002)(189002)(377454003)(199003)(24454002)(105586002)(97736004)(6506006)(33656002)(54906002)(6512007)(36756003)(6246003)(3280700002)(4001350100001)(50986999)(8676002)(53936002)(82746002)(76176999)(53546010)(478600001)(2906002)(101416001)(2950100002)(229853002)(2900100001)(8936002)(81166006)(77096006)(6436002)(189998001)(54356999)(5660300001)(99286003)(3660700001)(102836003)(3846002)(6116002)(7736002)(2501003)(6486002)(25786009)(66066001)(305945005)(83506001)(106356001)(68736007)(83716003)(86362001)(81156014)(4326008)(14454004);\n\tDIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB1905;\n\tH:BLUPR05MB611.namprd05.prod.outlook.com; FPR:; SPF:None;\n\tPTR:InfoNoRecords; MX:1; A:1; LANG:en; ","received-spf":"None (protection.outlook.com: vmware.com does not designate\n\tpermitted sender hosts)","spamdiagnosticoutput":"1:99","spamdiagnosticmetadata":"NSPM","Content-ID":"<92E6CF99087C9040AECE307611B61857@namprd05.prod.outlook.com>","MIME-Version":"1.0","X-OriginatorOrg":"vmware.com","X-MS-Exchange-CrossTenant-originalarrivaltime":"08 Sep 2017 19:29:48.6500\n\t(UTC)","X-MS-Exchange-CrossTenant-fromentityheader":"Hosted","X-MS-Exchange-CrossTenant-id":"b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0","X-MS-Exchange-Transport-CrossTenantHeadersStamped":"BLUPR05MB1905","X-Spam-Status":"No, score=0.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,\n\tRCVD_IN_DNSWL_NONE autolearn=disabled version=3.3.1","X-Spam-Checker-Version":"SpamAssassin 3.3.1 (2010-03-16) on\n\tsmtp1.linux-foundation.org","Subject":"Re: [ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow","X-BeenThere":"ovs-dev@openvswitch.org","X-Mailman-Version":"2.1.12","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Sender":"ovs-dev-bounces@openvswitch.org","Errors-To":"ovs-dev-bounces@openvswitch.org"}},{"id":1765962,"web_url":"http://patchwork.ozlabs.org/comment/1765962/","msgid":"<2EF2F5C0CC56984AA024D0B180335FCB4221DC02@IRSMSX102.ger.corp.intel.com>","list_archive_url":null,"date":"2017-09-10T16:12:47","subject":"Re: [ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow","submitter":{"id":67440,"url":"http://patchwork.ozlabs.org/api/people/67440/","name":"Chandran, Sugesh","email":"sugesh.chandran@intel.com"},"content":"Hi Yuanhan,\n\nThank you for sending out the patch series. \n\nWe are also looking into something similar to enable full offload in OVS-DPDK.\nIt is based on ' http://dpdk.org/ml/archives/dev/2017-September/074746.html' and some other rte_flow extension in DPDK.\n\nIt is noted that the patch series doesn't work very well for some of our requirements.\nPlease find below for the high level comments. I have also provided specific comments on the following patches.\n\n1) Looks to me the patch series is to enable/use just one functionality of NIC(mark action). In a multiple hardware environment it is necessary to have a feature discovery mechanism to define what needs to be installed in the hardware based on its capabilities, for eg: MARK+QUEUE, MARK only, number of supported flow entries, supported flow fields and etc. This is very important to support different hardware NICs and make flow install easy.\nIn our implementation we have a feature discovery at the OVS init. It will also populate the OVSDB to expose the device capability to higher management layers. The new table introduced in OVSDB is like below.\n\n \n

\n Hardware switching configuration and capabilities.\n

\n \n The name of hardware acceleration device.\n \n \n The integer device id of hardware accelerated NIC.\n \n \n The PCI ID of the hardware acceleration device. The broker id/PF id.\n \n \n The number of supported vhost ports in the hardware switch.\n \n
\n\nThe features column can be extended with more fields as necessary.\nIMO the proposed partial offload doesn't need populating the OVSDB, however its necessary to have some kind of feature discovery at init.\n\n2) I feel its better to keep the hardware offload functionalities in netdev as much as possible similar to kernel implementation. I see changes in upcall and dpif. \n\n3) The cost of flow install . PMDs are blocked when a hardware flow install is happening. Its an issue when there are lot of short lived flows are getting installed in the DP. One option to handle this would be move the flow install into revalidate. The advantage of this approach would be hardware offload would happen only when a flow is being used at least for sometime. Something like how revalidator thread handle the flow modify operation.\n\n4) AFAIK, these hardware programmability for a NIC/not for a specific port. i.e the FDIR/RSS hash configuration are device specific. This will be an issue if a NIC shared between kernel and DPDK drivers? \n\n\nRegards\n_Sugesh\n\n\n> -----Original Message-----\n> From: ovs-dev-bounces@openvswitch.org [mailto:ovs-dev-\n> bounces@openvswitch.org] On Behalf Of Yuanhan Liu\n> Sent: Tuesday, September 5, 2017 10:23 AM\n> To: dev@openvswitch.org\n> Subject: [ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow\n> \n> Hi,\n> \n> Here is a joint work from Mellanox and Napatech, to enable the flow hw\n> offload with the DPDK generic flow interface (rte_flow).\n> \n> The basic idea is to associate the flow with a mark id (a unit32_t number).\n> Later, we then get the flow directly from the mark id, bypassing the heavy\n> emc processing, including miniflow_extract.\n> \n> The association is done with CMAP in patch 1. It also reuses the flow APIs\n> introduced while adding the tc offloads. The emc bypassing is done in patch\n> 2. The flow offload is done in patch 4, which mainly does two\n> things:\n> \n> - translate the ovs match to DPDK rte flow patterns\n> - bind those patterns with a MARK action.\n> \n> Afterwards, the NIC will set the mark id in every pkt's mbuf when it matches\n> the flow. That's basically how we could get the flow directly from the\n> received mbuf.\n> \n> While testing with PHY-PHY forwarding with one core and one queue, I got\n> about 54% performance boost. For PHY-vhost forwarding, I got about 41%\n> performance boost. The reason it's lower than v1 is I added the logic to get\n> the correct tcp_flags, which examines all packets recieved.\n> \n> The major issue mentioned in last version is also workarounded: the queue\n> index is never set to 0 blindly anymore, but set to the rxq that first receives\n> the upcall pkt.\n> \n> Note that it's disabled by default, which can be enabled by:\n> \n> $ ovs-vsctl set Open_vSwitch . other_config:hw-offload=true\n> \n> \n> v2: - workaround the queue action issue\n> - fixed the tcp_flags being skipped issue, which also fixed the\n> build warnings\n> - fixed l2 patterns for Intel nic\n> - Converted some macros to functions\n> - did not hardcode the max number of flow/action\n> - rebased on top of the lastest code\n> \n> Thanks.\n> \n> --yliu\n> \n> \n> ---\n> Finn Christensen (3):\n> netdev-dpdk: implement flow put with rte flow\n> netdev-dpdk: retry with queue action\n> netdev-dpdk: set FDIR config\n> \n> Shachar Beiser (1):\n> dpif-netdev: record rx queue id for the upcall\n> \n> Yuanhan Liu (4):\n> dpif-netdev: associate flow with a mark id\n> dpif-netdev: retrieve flow directly from the flow mark\n> netdev-dpdk: convert ufid to dpdk flow\n> netdev-dpdk: remove offloaded flow on deletion\n> \n> lib/dp-packet.h | 14 ++\n> lib/dpif-netdev.c | 132 +++++++++++--\n> lib/flow.c | 78 ++++++++\n> lib/flow.h | 1 +\n> lib/netdev-dpdk.c | 574\n> +++++++++++++++++++++++++++++++++++++++++++++++++++++-\n> lib/netdev.c | 1 +\n> lib/netdev.h | 7 +\n> 7 files changed, 795 insertions(+), 12 deletions(-)\n> \n> --\n> 2.7.4\n> \n> _______________________________________________\n> dev mailing list\n> dev@openvswitch.org\n> https://mail.openvswitch.org/mailman/listinfo/ovs-dev","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","dev@openvswitch.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","ovs-dev@mail.linuxfoundation.org"],"Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=openvswitch.org\n\t(client-ip=140.211.169.12; helo=mail.linuxfoundation.org;\n\tenvelope-from=ovs-dev-bounces@openvswitch.org;\n\treceiver=)","Received":["from mail.linuxfoundation.org (mail.linuxfoundation.org\n\t[140.211.169.12])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xqx1V4Qs1z9s7c\n\tfor ;\n\tMon, 11 Sep 2017 02:13:17 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id CA4E49F0;\n\tSun, 10 Sep 2017 16:12:52 +0000 (UTC)","from smtp1.linuxfoundation.org (smtp1.linux-foundation.org\n\t[172.17.192.35])\n\tby mail.linuxfoundation.org (Postfix) with ESMTPS id 4D9439C0\n\tfor ; Sun, 10 Sep 2017 16:12:51 +0000 (UTC)","from mga01.intel.com (mga01.intel.com [192.55.52.88])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8847AE5\n\tfor ; Sun, 10 Sep 2017 16:12:50 +0000 (UTC)","from fmsmga003.fm.intel.com ([10.253.24.29])\n\tby fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t10 Sep 2017 09:12:50 -0700","from irsmsx109.ger.corp.intel.com ([163.33.3.23])\n\tby FMSMGA003.fm.intel.com with ESMTP; 10 Sep 2017 09:12:49 -0700","from irsmsx102.ger.corp.intel.com ([169.254.2.59]) by\n\tIRSMSX109.ger.corp.intel.com ([169.254.13.28]) with mapi id\n\t14.03.0319.002; Sun, 10 Sep 2017 17:12:48 +0100"],"X-Greylist":"domain auto-whitelisted by SQLgrey-1.7.6","X-ExtLoop1":"1","X-IronPort-AV":"E=Sophos;i=\"5.42,372,1500966000\"; d=\"scan'208\";a=\"898884546\"","From":"\"Chandran, Sugesh\" ","To":"Yuanhan Liu , \"dev@openvswitch.org\"\n\t","Thread-Topic":"[ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow","Thread-Index":"AQHTJijOgvfPmJ9h+UuHtoiz+CDsHaKuK+ug","Date":"Sun, 10 Sep 2017 16:12:47 +0000","Message-ID":"<2EF2F5C0CC56984AA024D0B180335FCB4221DC02@IRSMSX102.ger.corp.intel.com>","References":"<1504603381-30071-1-git-send-email-yliu@fridaylinux.org>","In-Reply-To":"<1504603381-30071-1-git-send-email-yliu@fridaylinux.org>","Accept-Language":"en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","x-titus-metadata-40":"eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNjhjNzliNWMtN2JlNi00MGQzLWJlMjUtMWM1OTE1Mjc2YjA1IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6ImJBd2dIVHVKa1FOclVBUWNjY3FVMWhEYVZOU3pxTWxpaDJiQm81WTZMSE09In0=","x-ctpclassification":"CTP_IC","dlp-product":"dlpe-windows","dlp-version":"11.0.0.116","dlp-reaction":"no-action","x-originating-ip":"[163.33.239.180]","MIME-Version":"1.0","X-Spam-Status":"No, score=-5.0 required=5.0 tests=RCVD_IN_DNSWL_HI,\n\tRP_MATCHES_RCVD autolearn=disabled version=3.3.1","X-Spam-Checker-Version":"SpamAssassin 3.3.1 (2010-03-16) on\n\tsmtp1.linux-foundation.org","Subject":"Re: [ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow","X-BeenThere":"ovs-dev@openvswitch.org","X-Mailman-Version":"2.1.12","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"ovs-dev-bounces@openvswitch.org","Errors-To":"ovs-dev-bounces@openvswitch.org"}},{"id":1766062,"web_url":"http://patchwork.ozlabs.org/comment/1766062/","msgid":"<20170911062151.GP9736@yliu-home>","list_archive_url":null,"date":"2017-09-11T06:21:51","subject":"Re: [ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow","submitter":{"id":72215,"url":"http://patchwork.ozlabs.org/api/people/72215/","name":"Yuanhan Liu","email":"yliu@fridaylinux.org"},"content":"I see. Thanks!\n\n\t--yliu\n\nOn Fri, Sep 08, 2017 at 07:29:48PM +0000, Darrell Ball wrote:\n> Hi Yuanhan\n> \n> In the dpdk public meeting, we requested Simon to also review this series to check\n> that it is sync with the HWOL for kernel with respect to one or two high level aspects.\n> I had some comments related to coding standards for V2, but I’ll wait for you to respond\n> to Simon’s comments before adding my own other comments, in order to avoid confusion.\n> \n> Thanks Darrell\n> \n> \n> On 9/5/17, 2:22 AM, \"Yuanhan Liu\" wrote:\n> \n> Hi,\n> \n> Here is a joint work from Mellanox and Napatech, to enable the flow hw\n> offload with the DPDK generic flow interface (rte_flow).\n> \n> The basic idea is to associate the flow with a mark id (a unit32_t number).\n> Later, we then get the flow directly from the mark id, bypassing the heavy\n> emc processing, including miniflow_extract.\n> \n> The association is done with CMAP in patch 1. It also reuses the flow\n> APIs introduced while adding the tc offloads. The emc bypassing is done\n> in patch 2. The flow offload is done in patch 4, which mainly does two\n> things:\n> \n> - translate the ovs match to DPDK rte flow patterns\n> - bind those patterns with a MARK action.\n> \n> Afterwards, the NIC will set the mark id in every pkt's mbuf when it\n> matches the flow. That's basically how we could get the flow directly\n> from the received mbuf.\n> \n> While testing with PHY-PHY forwarding with one core and one queue, I got\n> about 54% performance boost. For PHY-vhost forwarding, I got about 41%\n> performance boost. The reason it's lower than v1 is I added the logic\n> to get the correct tcp_flags, which examines all packets recieved.\n> \n> The major issue mentioned in last version is also workarounded: the\n> queue index is never set to 0 blindly anymore, but set to the rxq that\n> first receives the upcall pkt.\n> \n> Note that it's disabled by default, which can be enabled by:\n> \n> $ ovs-vsctl set Open_vSwitch . other_config:hw-offload=true\n> \n> \n> v2: - workaround the queue action issue\n> - fixed the tcp_flags being skipped issue, which also fixed the\n> build warnings\n> - fixed l2 patterns for Intel nic\n> - Converted some macros to functions\n> - did not hardcode the max number of flow/action\n> - rebased on top of the lastest code\n> \n> Thanks.\n> \n> --yliu\n> \n> \n> ---\n> Finn Christensen (3):\n> netdev-dpdk: implement flow put with rte flow\n> netdev-dpdk: retry with queue action\n> netdev-dpdk: set FDIR config\n> \n> Shachar Beiser (1):\n> dpif-netdev: record rx queue id for the upcall\n> \n> Yuanhan Liu (4):\n> dpif-netdev: associate flow with a mark id\n> dpif-netdev: retrieve flow directly from the flow mark\n> netdev-dpdk: convert ufid to dpdk flow\n> netdev-dpdk: remove offloaded flow on deletion\n> \n> lib/dp-packet.h | 14 ++\n> lib/dpif-netdev.c | 132 +++++++++++--\n> lib/flow.c | 78 ++++++++\n> lib/flow.h | 1 +\n> lib/netdev-dpdk.c | 574 +++++++++++++++++++++++++++++++++++++++++++++++++++++-\n> lib/netdev.c | 1 +\n> lib/netdev.h | 7 +\n> 7 files changed, 795 insertions(+), 12 deletions(-)\n> \n> -- \n> 2.7.4\n> \n> \n>","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","dev@openvswitch.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","ovs-dev@mail.linuxfoundation.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=openvswitch.org\n\t(client-ip=140.211.169.12; helo=mail.linuxfoundation.org;\n\tenvelope-from=ovs-dev-bounces@openvswitch.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=fridaylinux-org.20150623.gappssmtp.com\n\theader.i=@fridaylinux-org.20150623.gappssmtp.com\n\theader.b=\"ngZcfSC2\"; dkim-atps=neutral"],"Received":["from mail.linuxfoundation.org (mail.linuxfoundation.org\n\t[140.211.169.12])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xrHrr4kggz9s7g\n\tfor ;\n\tMon, 11 Sep 2017 16:22:04 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id 63FDCAE0;\n\tMon, 11 Sep 2017 06:22:02 +0000 (UTC)","from smtp1.linuxfoundation.org (smtp1.linux-foundation.org\n\t[172.17.192.35])\n\tby mail.linuxfoundation.org (Postfix) with ESMTPS id E0129A92\n\tfor ; Mon, 11 Sep 2017 06:22:00 +0000 (UTC)","from mail-pg0-f46.google.com (mail-pg0-f46.google.com\n\t[74.125.83.46])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id 41463E7\n\tfor ; Mon, 11 Sep 2017 06:22:00 +0000 (UTC)","by mail-pg0-f46.google.com with SMTP id t3so13773833pgt.0\n\tfor ; Sun, 10 Sep 2017 23:22:00 -0700 (PDT)","from yliu-home ([45.63.61.64]) by smtp.gmail.com with ESMTPSA id\n\tk73sm14997468pfg.81.2017.09.10.23.21.57\n\t(version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);\n\tSun, 10 Sep 2017 23:21:58 -0700 (PDT)"],"X-Greylist":"whitelisted by SQLgrey-1.7.6","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=fridaylinux-org.20150623.gappssmtp.com; s=20150623;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:content-transfer-encoding:in-reply-to\n\t:user-agent; bh=8gxqsA3M+V9R6zq5sqt/Q6paQQErBnsOwn7qqhtj2r4=;\n\tb=ngZcfSC23i4iSNHwmUVcfqPk2HISpu+aZRYtzGe8MGEylYQu7hDcpW48m+TEm6A8IG\n\tq203kN/c76jrYpvGXbVTT6JBiD5b525aDKIO+FLl6M1NlNBctsm3HIzes7F5hgnLaaQ1\n\tO6zxbaMHbTp4g+xFWVAW8K5ae5sdVm5TxcXHJi+V5iesKyfapIsKKQYNfO5JvsY03MmM\n\tI9YgHf1Kg0Xl8V1FdxNOj/L9ffBhznCl+fk5OiPxz0QhmRIlhDRZ78UNTvhnkq9fTHsL\n\taBvNu5O9orU+FBL376DzPHYTBhLrA7R3XRp3aIyKVRKfF9/wOOvl3tvgTIwJk6E1SFZw\n\tfiQA==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:content-transfer-encoding\n\t:in-reply-to:user-agent;\n\tbh=8gxqsA3M+V9R6zq5sqt/Q6paQQErBnsOwn7qqhtj2r4=;\n\tb=KrbaDqcYwq31XhMvaHf7Spdm63yA5C3ZmA/mP3iVlhYE+IG7EeTGyAvgZkj1v8r93n\n\tcdGZDOI3VfopE4V2gIOl8ZO2aenL/HIdc0LVk1eiyFsn0aKPWaP7wTgNCAOgHjP1JiKq\n\tr5japW4ESDRr/EDWrTajU3UCfE2Xgy0ZbRW1rIBm0DNMR+6L7O6fYsDrNLU5nVjLfdyc\n\tswkSizRHvfOTKYWSRcpklDU6GXpiHQGGn6taqNa+4hCAeUu3TomGQVFJLTExgF3oSvAI\n\tSk3nmTAu7PhjxveeVBc1ZmTxeL5wFsx1rXR6o3qH5DCEwC6PB5vj5qPSkQPJ/JQfpxfS\n\tbZog==","X-Gm-Message-State":"AHPjjUhfD+TNzuH0icw5y6zFOkKWv3Xh9uTUVxp5yS8GlKn7qHJO/SK9\n\tBw0gKCItVoEBCsby","X-Google-Smtp-Source":"ADKCNb6ZUXusddnmTseF7OyGCNysOC8AWsjzufMq+lVRaV1HCERiMPY//jYEuTWaFkNz/qt622vE0A==","X-Received":"by 10.99.186.91 with SMTP id l27mr10610496pgu.279.1505110919860; \n\tSun, 10 Sep 2017 23:21:59 -0700 (PDT)","Date":"Mon, 11 Sep 2017 14:21:51 +0800","From":"Yuanhan Liu ","To":"Darrell Ball ","Message-ID":"<20170911062151.GP9736@yliu-home>","References":"<1504603381-30071-1-git-send-email-yliu@fridaylinux.org>\n\t<4F93F2C0-BE57-4754-B0EA-25F9B8A99C00@vmware.com>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<4F93F2C0-BE57-4754-B0EA-25F9B8A99C00@vmware.com>","User-Agent":"Mutt/1.5.24 (2015-08-30)","X-Spam-Status":"No, score=0.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,\n\tRCVD_IN_DNSWL_NONE,\n\tRCVD_IN_SORBS_SPAM autolearn=disabled version=3.3.1","X-Spam-Checker-Version":"SpamAssassin 3.3.1 (2010-03-16) on\n\tsmtp1.linux-foundation.org","Cc":"\"dev@openvswitch.org\" ","Subject":"Re: [ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow","X-BeenThere":"ovs-dev@openvswitch.org","X-Mailman-Version":"2.1.12","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Sender":"ovs-dev-bounces@openvswitch.org","Errors-To":"ovs-dev-bounces@openvswitch.org"}},{"id":1766150,"web_url":"http://patchwork.ozlabs.org/comment/1766150/","msgid":"<20170911091136.GW9736@yliu-home>","list_archive_url":null,"date":"2017-09-11T09:11:36","subject":"Re: [ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow","submitter":{"id":72215,"url":"http://patchwork.ozlabs.org/api/people/72215/","name":"Yuanhan Liu","email":"yliu@fridaylinux.org"},"content":"On Sun, Sep 10, 2017 at 04:12:47PM +0000, Chandran, Sugesh wrote:\n> Hi Yuanhan,\n> \n> Thank you for sending out the patch series. \n\nHi Sugesh,\n\nThank you for taking your time to review it!\n\n\n> We are also looking into something similar to enable full offload in OVS-DPDK.\n\nGood to know!\n\n> It is based on ' http://dpdk.org/ml/archives/dev/2017-September/074746.html' and some other rte_flow extension in DPDK.\n\nI saw the patches, I will take some time to read it.\n\n> \n> It is noted that the patch series doesn't work very well for some of our requirements.\n> Please find below for the high level comments. I have also provided specific comments on the following patches.\n> \n> 1) Looks to me the patch series is to enable/use just one functionality of NIC(mark action). In a multiple hardware environment it is necessary to have a feature discovery mechanism to define what needs to be installed in the hardware based on its capabilities, for eg: MARK+QUEUE, MARK only, number of supported flow entries, supported flow fields and etc. This is very important to support different hardware NICs and make flow install easy.\n\nYes, you are right. I have also observed this issue while coding this\npatch.\n\n> In our implementation we have a feature discovery at the OVS init. It will also populate the OVSDB to expose the device capability to higher management layers. The new table introduced in OVSDB is like below.\n\nThe solution I want to go, however, is different though. I was thinking\nto introduce few DPDK rte_flow APIs and structs to define the NIC flow\ncapabilities.\n\nI think this would help long run, as the capabilitiy will be updated\nas the new features are added (when new versions are released). For the\nsolution you proposed, it won't allow DPDK work with multiple DPDK versions\n(assume they provides different rte flow capabilities).\n\n> \n>

\n> Hardware switching configuration and capabilities.\n>

\n> \n> The name of hardware acceleration device.\n> \n> \n> The integer device id of hardware accelerated NIC.\n> \n> \n> The PCI ID of the hardware acceleration device. The broker id/PF id.\n> \n> \n> The number of supported vhost ports in the hardware switch.\n> \n>
\n> \n> The features column can be extended with more fields as necessary.\n> IMO the proposed partial offload doesn't need populating the OVSDB, however its necessary to have some kind of feature discovery at init.\n> \n> 2) I feel its better to keep the hardware offload functionalities in netdev as much as possible similar to kernel implementation. I see changes in upcall and dpif. \n\nI agree with you. But unfortunately, due to some dirver or hardware\nlimitation, that's what I can get best.\n\n> 3) The cost of flow install . PMDs are blocked when a hardware flow install is happening. Its an issue when there are lot of short lived flows are getting installed in the DP.\n\nI wasn't aware of it. Thank you for letting me know that!\n\n> One option to handle this would be move the flow install into revalidate. The advantage of this approach would be hardware offload would happen only when a flow is being used at least for sometime. Something like how revalidator thread handle the flow modify operation.\n\nYes, it sounds workable. However, the MARK and QUEUE workaround won't\nwork then: we need record the rxq first. And again, I know the workaround\nis far from being perfect.\n\n> 4) AFAIK, these hardware programmability for a NIC/not for a specific port. i.e the FDIR/RSS hash configuration are device specific. This will be an issue if a NIC shared between kernel and DPDK drivers? \n\nThat might be NIC specific. What do you mean by sharing between kernel\nand DPDK? In most NICs I'm aware of, it's requried to unbind the kernel\ndriver first. Thus, it won't be shared. For Mellanox, the control unit\nis based on queues, thus it could be shared correctly.\n\n\t--yliu","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","dev@openvswitch.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","ovs-dev@mail.linuxfoundation.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=openvswitch.org\n\t(client-ip=140.211.169.12; helo=mail.linuxfoundation.org;\n\tenvelope-from=ovs-dev-bounces@openvswitch.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=fridaylinux-org.20150623.gappssmtp.com\n\theader.i=@fridaylinux-org.20150623.gappssmtp.com\n\theader.b=\"fOggU8JP\"; dkim-atps=neutral"],"Received":["from mail.linuxfoundation.org (mail.linuxfoundation.org\n\t[140.211.169.12])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xrMch0Swqz9s75\n\tfor ;\n\tMon, 11 Sep 2017 19:11:47 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id 3D107A67;\n\tMon, 11 Sep 2017 09:11:46 +0000 (UTC)","from smtp1.linuxfoundation.org (smtp1.linux-foundation.org\n\t[172.17.192.35])\n\tby mail.linuxfoundation.org (Postfix) with ESMTPS id BC9A2516\n\tfor ; Mon, 11 Sep 2017 09:11:45 +0000 (UTC)","from mail-pg0-f50.google.com (mail-pg0-f50.google.com\n\t[74.125.83.50])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2AACDA4\n\tfor ; Mon, 11 Sep 2017 09:11:45 +0000 (UTC)","by mail-pg0-f50.google.com with SMTP id d8so14279277pgt.4\n\tfor ; Mon, 11 Sep 2017 02:11:45 -0700 (PDT)","from yliu-home ([45.63.61.64]) by smtp.gmail.com with ESMTPSA id\n\tv186sm13840343pfb.51.2017.09.11.02.11.41\n\t(version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);\n\tMon, 11 Sep 2017 02:11:43 -0700 (PDT)"],"X-Greylist":"whitelisted by SQLgrey-1.7.6","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=fridaylinux-org.20150623.gappssmtp.com; s=20150623;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:in-reply-to:user-agent;\n\tbh=qDEjNh7o+ZVJBGPIRq4WQuRK+M4TjA7ZBu4BChzp7/g=;\n\tb=fOggU8JPnxUGNiwKF9qm6wnOT0aoB3f8uF8b9wgD4RZHczAcirm20dj0v9zAOFjGto\n\tBa/dQqLAsq21ZdjrB+JjAB1LHAmaudOcskumuquLlLSR4i/1p7mEN3AtHcNNCZJ+yaKv\n\tAtUhT/WRgnwU5ef49cW0W3KUqiIh7W5NxIGea2ZDfpqBpILBz4ZCNPspQAvWBpqMVqF4\n\t5uIUDqPLvKUUWhXBpoqg0yif3gS7DqYA7pm4Qd+f3y7GZFkHaaw1sULW9ukHhRh0Tb1O\n\trdIWySy+RzjmlpvlyeNKy3BAByJSwEb5nOuTKjGqKHJFHnpZKW/8ARTjw4cmPz0W1BaB\n\tzDJA==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:in-reply-to:user-agent;\n\tbh=qDEjNh7o+ZVJBGPIRq4WQuRK+M4TjA7ZBu4BChzp7/g=;\n\tb=qyJ66/EUYbdQQy0yGIDJhiQmRt1ButKiT3Y4lz6KNSgwJIAx210IlCH8LC9slc5wiF\n\t/osm9wLiHqSXRtLR/ixE5D9TXONxtwwOnXvhpwxuRTf0sTmVlIcEBtZim7/DHzkkN1Vm\n\tS+m6bge4qSnp+Dm84dYLTgT4KKC4HupS/7b77tLB2c/3VBIo6tuSHuh6nlkSnxTvml8u\n\tDcpYulmY4bef4HSVwj8m34j2fEikQO4y3nTi0pd79gU7b/nV5PJQ3GtO5DDtCTCMfQXV\n\tL/guRcJE4IF4VwP52v2An5ZiEdmRBL2k5XUnTf7f1gvdtr13kNPXxrxW7qWji9XoAIrH\n\tt99g==","X-Gm-Message-State":"AHPjjUii0+qgM1k9xc6D36k/g3aheQrI8gRGNabqaevT+8nmWFcp5yt6\n\txE5d6MFSoklNOzrE","X-Google-Smtp-Source":"ADKCNb6cKJSXDSu+8n9qBbOcOPBmApoQrWyyGFFADz68vDuvIUY3/gTi0YYEyzVD7H19QdnUI5V4iA==","X-Received":"by 10.99.6.76 with SMTP id 73mr11278882pgg.105.1505121104722;\n\tMon, 11 Sep 2017 02:11:44 -0700 (PDT)","Date":"Mon, 11 Sep 2017 17:11:36 +0800","From":"Yuanhan Liu ","To":"\"Chandran, Sugesh\" ","Message-ID":"<20170911091136.GW9736@yliu-home>","References":"<1504603381-30071-1-git-send-email-yliu@fridaylinux.org>\n\t<2EF2F5C0CC56984AA024D0B180335FCB4221DC02@IRSMSX102.ger.corp.intel.com>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<2EF2F5C0CC56984AA024D0B180335FCB4221DC02@IRSMSX102.ger.corp.intel.com>","User-Agent":"Mutt/1.5.24 (2015-08-30)","X-Spam-Status":"No, score=0.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,\n\tRCVD_IN_DNSWL_NONE autolearn=disabled version=3.3.1","X-Spam-Checker-Version":"SpamAssassin 3.3.1 (2010-03-16) on\n\tsmtp1.linux-foundation.org","Cc":"\"dev@openvswitch.org\" ","Subject":"Re: [ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow","X-BeenThere":"ovs-dev@openvswitch.org","X-Mailman-Version":"2.1.12","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"ovs-dev-bounces@openvswitch.org","Errors-To":"ovs-dev-bounces@openvswitch.org"}},{"id":1766191,"web_url":"http://patchwork.ozlabs.org/comment/1766191/","msgid":"<2EF2F5C0CC56984AA024D0B180335FCB4221E089@IRSMSX102.ger.corp.intel.com>","list_archive_url":null,"date":"2017-09-11T10:00:06","subject":"Re: [ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow","submitter":{"id":67440,"url":"http://patchwork.ozlabs.org/api/people/67440/","name":"Chandran, Sugesh","email":"sugesh.chandran@intel.com"},"content":"Regards\n_Sugesh\n\n\n> -----Original Message-----\n> From: Yuanhan Liu [mailto:yliu@fridaylinux.org]\n> Sent: Monday, September 11, 2017 10:12 AM\n> To: Chandran, Sugesh \n> Cc: dev@openvswitch.org\n> Subject: Re: [ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow\n> \n> On Sun, Sep 10, 2017 at 04:12:47PM +0000, Chandran, Sugesh wrote:\n> > Hi Yuanhan,\n> >\n> > Thank you for sending out the patch series.\n> \n> Hi Sugesh,\n> \n> Thank you for taking your time to review it!\n> \n> \n> > We are also looking into something similar to enable full offload in OVS-\n> DPDK.\n> \n> Good to know!\n> \n> > It is based on ' http://dpdk.org/ml/archives/dev/2017-\n> September/074746.html' and some other rte_flow extension in DPDK.\n> \n> I saw the patches, I will take some time to read it.\n[Sugesh]Sure.\n> \n> >\n> > It is noted that the patch series doesn't work very well for some of our\n> requirements.\n> > Please find below for the high level comments. I have also provided specific\n> comments on the following patches.\n> >\n> > 1) Looks to me the patch series is to enable/use just one functionality of\n> NIC(mark action). In a multiple hardware environment it is necessary to have\n> a feature discovery mechanism to define what needs to be installed in the\n> hardware based on its capabilities, for eg: MARK+QUEUE, MARK only,\n> number of supported flow entries, supported flow fields and etc. This is very\n> important to support different hardware NICs and make flow install easy.\n> \n> Yes, you are right. I have also observed this issue while coding this patch.\n[Sugesh] Ok.\n> \n> > In our implementation we have a feature discovery at the OVS init. It will\n> also populate the OVSDB to expose the device capability to higher\n> management layers. The new table introduced in OVSDB is like below.\n> \n> The solution I want to go, however, is different though. I was thinking to\n> introduce few DPDK rte_flow APIs and structs to define the NIC flow\n> capabilities.\n[Sugesh] technically rte_flow is for flow programming and not for device capabilities.\nAgain if DPDK can have such API in rte_flow. I think it should be fine.\n> \n> I think this would help long run, as the capabilitiy will be updated as the new\n> features are added (when new versions are released). For the solution you\n> proposed, it won't allow DPDK work with multiple DPDK versions (assume\n> they provides different rte flow capabilities).\n> \n> > \n> >

\n> > Hardware switching configuration and capabilities.\n> >

\n> > \n> > The name of hardware acceleration device.\n> > \n> > \n> > The integer device id of hardware accelerated NIC.\n> > \n> > \n> > The PCI ID of the hardware acceleration device. The broker id/PF id.\n> > \n> > \n> > The number of supported vhost ports in the hardware switch.\n> > \n> >
\n> >\n> > The features column can be extended with more fields as necessary.\n> > IMO the proposed partial offload doesn't need populating the OVSDB,\n> however its necessary to have some kind of feature discovery at init.\n> >\n> > 2) I feel its better to keep the hardware offload functionalities in netdev as\n> much as possible similar to kernel implementation. I see changes in upcall\n> and dpif.\n> \n> I agree with you. But unfortunately, due to some dirver or hardware\n> limitation, that's what I can get best.\n[Sugesh] Ok. \n> \n> > 3) The cost of flow install . PMDs are blocked when a hardware flow install\n> is happening. Its an issue when there are lot of short lived flows are getting\n> installed in the DP.\n> \n> I wasn't aware of it. Thank you for letting me know that!\n> \n[Sugesh] Ok\n> > One option to handle this would be move the flow install into revalidate.\n> The advantage of this approach would be hardware offload would happen\n> only when a flow is being used at least for sometime. Something like how\n> revalidator thread handle the flow modify operation.\n> \n> Yes, it sounds workable. However, the MARK and QUEUE workaround won't\n> work then: we need record the rxq first. And again, I know the workaround is\n> far from being perfect.\n> \n> > 4) AFAIK, these hardware programmability for a NIC/not for a specific port.\n> i.e the FDIR/RSS hash configuration are device specific. This will be an issue if\n> a NIC shared between kernel and DPDK drivers?\n> \n> That might be NIC specific. What do you mean by sharing between kernel\n> and DPDK? In most NICs I'm aware of, it's requried to unbind the kernel\n> driver first. Thus, it won't be shared. For Mellanox, the control unit is based\n> on queues, thus it could be shared correctly.\n[Sugesh] What I meant by that is, consider a case of NIC with 4*10G ports.\n2 ports bound to DPDK and 2 ports to kernel.\nIf I remember correctly XL710 NIC can support total 8k exact match flow entries in its\nFlow director. Similarly some other resources are also shared across all the ports in the NIC. \nNow how these resources are properly managed between\nKernel and DPDK. \n I agree that Mellanox NICs this should be fine, but not sure if it work on all\nthe NICs out there. This will make adverse effect on each other when making changes to any global configuration.\n> \n> \t--yliu","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","dev@openvswitch.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","ovs-dev@mail.linuxfoundation.org"],"Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=openvswitch.org\n\t(client-ip=140.211.169.12; helo=mail.linuxfoundation.org;\n\tenvelope-from=ovs-dev-bounces@openvswitch.org;\n\treceiver=)","Received":["from mail.linuxfoundation.org (mail.linuxfoundation.org\n\t[140.211.169.12])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xrNhX6XRvz9s1h\n\tfor ;\n\tMon, 11 Sep 2017 20:00:12 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id 1B911BBD;\n\tMon, 11 Sep 2017 10:00:11 +0000 (UTC)","from smtp1.linuxfoundation.org (smtp1.linux-foundation.org\n\t[172.17.192.35])\n\tby mail.linuxfoundation.org (Postfix) with ESMTPS id 77DB6B94\n\tfor ; Mon, 11 Sep 2017 10:00:10 +0000 (UTC)","from mga06.intel.com (mga06.intel.com [134.134.136.31])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7EF19D3\n\tfor ; Mon, 11 Sep 2017 10:00:09 +0000 (UTC)","from fmsmga001.fm.intel.com ([10.253.24.23])\n\tby orsmga104.jf.intel.com with ESMTP; 11 Sep 2017 03:00:08 -0700","from irsmsx107.ger.corp.intel.com ([163.33.3.99])\n\tby fmsmga001.fm.intel.com with ESMTP; 11 Sep 2017 03:00:07 -0700","from irsmsx102.ger.corp.intel.com ([169.254.2.59]) by\n\tIRSMSX107.ger.corp.intel.com ([169.254.10.65]) with mapi id\n\t14.03.0319.002; Mon, 11 Sep 2017 11:00:07 +0100"],"X-Greylist":"domain auto-whitelisted by SQLgrey-1.7.6","X-ExtLoop1":"1","X-IronPort-AV":"E=Sophos; i=\"5.42,377,1500966000\"; d=\"scan'208\";\n\ta=\"1193721200\"","From":"\"Chandran, Sugesh\" ","To":"Yuanhan Liu ","Thread-Topic":"[ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow","Thread-Index":"AQHTJijOgvfPmJ9h+UuHtoiz+CDsHaKuK+uggAEy7wCAABuZoA==","Date":"Mon, 11 Sep 2017 10:00:06 +0000","Message-ID":"<2EF2F5C0CC56984AA024D0B180335FCB4221E089@IRSMSX102.ger.corp.intel.com>","References":"<1504603381-30071-1-git-send-email-yliu@fridaylinux.org>\n\t<2EF2F5C0CC56984AA024D0B180335FCB4221DC02@IRSMSX102.ger.corp.intel.com>\n\t<20170911091136.GW9736@yliu-home>","In-Reply-To":"<20170911091136.GW9736@yliu-home>","Accept-Language":"en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","x-titus-metadata-40":"eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMjVjYjQ2ZTktMmRkMC00MmQ1LTlmZmItYzg1ZGY2MWIzYzk4IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6IlVybDd3SmhwR1ZkeW4yaVFkeUpSS2Nybk15T1puNFJDaWRsemZ1NkhCNVU9In0=","x-ctpclassification":"CTP_IC","dlp-product":"dlpe-windows","dlp-version":"11.0.0.116","dlp-reaction":"no-action","x-originating-ip":"[163.33.239.181]","MIME-Version":"1.0","X-Spam-Status":"No, score=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED,\n\tRP_MATCHES_RCVD autolearn=disabled version=3.3.1","X-Spam-Checker-Version":"SpamAssassin 3.3.1 (2010-03-16) on\n\tsmtp1.linux-foundation.org","Cc":"\"dev@openvswitch.org\" ","Subject":"Re: [ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow","X-BeenThere":"ovs-dev@openvswitch.org","X-Mailman-Version":"2.1.12","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"ovs-dev-bounces@openvswitch.org","Errors-To":"ovs-dev-bounces@openvswitch.org"}},{"id":1766203,"web_url":"http://patchwork.ozlabs.org/comment/1766203/","msgid":"<20170911102253.GC9736@yliu-home>","list_archive_url":null,"date":"2017-09-11T10:22:53","subject":"Re: [ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow","submitter":{"id":72215,"url":"http://patchwork.ozlabs.org/api/people/72215/","name":"Yuanhan Liu","email":"yliu@fridaylinux.org"},"content":"On Mon, Sep 11, 2017 at 10:00:06AM +0000, Chandran, Sugesh wrote:\n> > > In our implementation we have a feature discovery at the OVS init. It will\n> > also populate the OVSDB to expose the device capability to higher\n> > management layers. The new table introduced in OVSDB is like below.\n> > \n> > The solution I want to go, however, is different though. I was thinking to\n> > introduce few DPDK rte_flow APIs and structs to define the NIC flow\n> > capabilities.\n> [Sugesh] technically rte_flow is for flow programming and not for device capabilities.\n\nNot really. rte_flow is just a framework, it needs the underlaying NIC\nto do the real thing. Each NIC has different limitations (we have seen\nquite few of them). Thus, we need something like this.\n\nIf you think this way: device capabilities regarding to flow, it may\nmake more sense to you :)\n\n> Again if DPDK can have such API in rte_flow. I think it should be fine.\n\nGood! I will make a proposal to DPDK for v18.02 then.\n\n> > > 4) AFAIK, these hardware programmability for a NIC/not for a specific port.\n> > i.e the FDIR/RSS hash configuration are device specific. This will be an issue if\n> > a NIC shared between kernel and DPDK drivers?\n> > \n> > That might be NIC specific. What do you mean by sharing between kernel\n> > and DPDK? In most NICs I'm aware of, it's requried to unbind the kernel\n> > driver first. Thus, it won't be shared. For Mellanox, the control unit is based\n> > on queues, thus it could be shared correctly.\n> [Sugesh] What I meant by that is, consider a case of NIC with 4*10G ports.\n> 2 ports bound to DPDK and 2 ports to kernel.\n\nI see.\n\n> If I remember correctly XL710 NIC can support total 8k exact match flow entries in its\n> Flow director. Similarly some other resources are also shared across all the ports in the NIC. \n> Now how these resources are properly managed between\n> Kernel and DPDK. \n\nHonestly, I don't know. We may need testings/investigations.\n\n> I agree that Mellanox NICs this should be fine, but not sure if it work on all\n> the NICs out there. This will make adverse effect on each other when making changes to any global configuration.\n\nFor sure I agree we should make it work on as many nics as possible.\nAnd I think that's what this patchset trying to do.\n\n\t--yliu","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","dev@openvswitch.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","ovs-dev@mail.linuxfoundation.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=openvswitch.org\n\t(client-ip=140.211.169.12; helo=mail.linuxfoundation.org;\n\tenvelope-from=ovs-dev-bounces@openvswitch.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=fridaylinux-org.20150623.gappssmtp.com\n\theader.i=@fridaylinux-org.20150623.gappssmtp.com\n\theader.b=\"oxLSYyYM\"; dkim-atps=neutral"],"Received":["from mail.linuxfoundation.org (mail.linuxfoundation.org\n\t[140.211.169.12])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xrPCS5PPpz9sBd\n\tfor ;\n\tMon, 11 Sep 2017 20:23:32 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id 09499BE6;\n\tMon, 11 Sep 2017 10:23:08 +0000 (UTC)","from smtp1.linuxfoundation.org (smtp1.linux-foundation.org\n\t[172.17.192.35])\n\tby mail.linuxfoundation.org (Postfix) with ESMTPS id CC222BD0\n\tfor ; Mon, 11 Sep 2017 10:23:06 +0000 (UTC)","from mail-pg0-f44.google.com (mail-pg0-f44.google.com\n\t[74.125.83.44])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id DA2C2D3\n\tfor ; Mon, 11 Sep 2017 10:23:05 +0000 (UTC)","by mail-pg0-f44.google.com with SMTP id 188so14493830pgb.2\n\tfor ; Mon, 11 Sep 2017 03:23:05 -0700 (PDT)","from yliu-home ([45.63.61.64]) by smtp.gmail.com with ESMTPSA id\n\tn19sm16311437pfj.114.2017.09.11.03.23.01\n\t(version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);\n\tMon, 11 Sep 2017 03:23:04 -0700 (PDT)"],"X-Greylist":"whitelisted by SQLgrey-1.7.6","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=fridaylinux-org.20150623.gappssmtp.com; s=20150623;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:in-reply-to:user-agent;\n\tbh=F4v1O449ykzUFRUlEsDjYCHpm0ig5T5VBA9l/82nCEE=;\n\tb=oxLSYyYMBgIyg+LYF08zXoarp0dcdO+dSqpJ4YkjwdFqqOnQAJBEFZvajbuxVtcmK+\n\tDFdriGbBI91XIM65SoXHXRJr0c6nXPpWTdyIky20kw2ANSQiwN20TGrSWoNjjBzMUIUC\n\te3npKtAOj7thfaOQP2CmSrtz8jOb2QfztNR0q/p6Ri4xeTS+r0NlhF2c/UlhbW6sDi2i\n\tJDadMrB5abZpYB8j2MSqRwT3LRT3bQ9zAYjrXfcflvCobNaGQSj1pNDNuswtxLaNbVik\n\trfO0+7zVO3lWtkgtmQ9ABNk6m6iucaV9I2gPROuC1OCEmJZ6xJU//xnEeU8IIFdShRix\n\tE0QQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:in-reply-to:user-agent;\n\tbh=F4v1O449ykzUFRUlEsDjYCHpm0ig5T5VBA9l/82nCEE=;\n\tb=TGfR6s9yklHtMoZ5K8RQxhBHumnfblQbw56GHx7nvoh5OZdDqhgvDvBnAvRqwVh6Sr\n\t6qfeEpbirQsdVCWv4N526vcLspiIE+G1y165ezVGtifGrLJGOChtKw064Kc9MLWz1z8i\n\tDcnUVILd9LS8pX9d83FMyHz1wsuC3iPA6fEt96JYsZzRvrlIpsiGO8xAeUdv+HPML0zb\n\tdPYzq91wNTw+41NkipLJQmrv3juubdNEI8YGPgD6GHIDmmuPFn4jU4OJNYHMllqdXk/E\n\trrjAZlE/deQCew6eFhs+EcJq/kqu5Od6B/I7fBO60G8gZ7gR6AFM+CjSy++n6ItmoXrn\n\tJm/w==","X-Gm-Message-State":"AHPjjUiQyVkstz0SDh3hKcI+Ejh+s+UPEwvCfccu+YM9QOwrG8xBi352\n\tx+FjRqkLK5+LIc24","X-Google-Smtp-Source":"ADKCNb72C51YrUT3ApQG6p1DN0t8PFktMxZjxeb9MB9PYyHksdKmpZWgVP3Z/TUYlIZpmTU6L5ztlw==","X-Received":"by 10.99.109.196 with SMTP id\n\ti187mr11353615pgc.357.1505125385483; \n\tMon, 11 Sep 2017 03:23:05 -0700 (PDT)","Date":"Mon, 11 Sep 2017 18:22:53 +0800","From":"Yuanhan Liu ","To":"\"Chandran, Sugesh\" ","Message-ID":"<20170911102253.GC9736@yliu-home>","References":"<1504603381-30071-1-git-send-email-yliu@fridaylinux.org>\n\t<2EF2F5C0CC56984AA024D0B180335FCB4221DC02@IRSMSX102.ger.corp.intel.com>\n\t<20170911091136.GW9736@yliu-home>\n\t<2EF2F5C0CC56984AA024D0B180335FCB4221E089@IRSMSX102.ger.corp.intel.com>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<2EF2F5C0CC56984AA024D0B180335FCB4221E089@IRSMSX102.ger.corp.intel.com>","User-Agent":"Mutt/1.5.24 (2015-08-30)","X-Spam-Status":"No, score=0.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,\n\tRCVD_IN_DNSWL_NONE autolearn=disabled version=3.3.1","X-Spam-Checker-Version":"SpamAssassin 3.3.1 (2010-03-16) on\n\tsmtp1.linux-foundation.org","Cc":"\"dev@openvswitch.org\" ","Subject":"Re: [ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow","X-BeenThere":"ovs-dev@openvswitch.org","X-Mailman-Version":"2.1.12","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"ovs-dev-bounces@openvswitch.org","Errors-To":"ovs-dev-bounces@openvswitch.org"}},{"id":1766222,"web_url":"http://patchwork.ozlabs.org/comment/1766222/","msgid":"<2EF2F5C0CC56984AA024D0B180335FCB4221E159@IRSMSX102.ger.corp.intel.com>","list_archive_url":null,"date":"2017-09-11T11:04:27","subject":"Re: [ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow","submitter":{"id":67440,"url":"http://patchwork.ozlabs.org/api/people/67440/","name":"Chandran, Sugesh","email":"sugesh.chandran@intel.com"},"content":"Regards\n_Sugesh\n\n\n> -----Original Message-----\n> From: Yuanhan Liu [mailto:yliu@fridaylinux.org]\n> Sent: Monday, September 11, 2017 11:23 AM\n> To: Chandran, Sugesh \n> Cc: dev@openvswitch.org\n> Subject: Re: [ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow\n> \n> On Mon, Sep 11, 2017 at 10:00:06AM +0000, Chandran, Sugesh wrote:\n> > > > In our implementation we have a feature discovery at the OVS init.\n> > > > It will\n> > > also populate the OVSDB to expose the device capability to higher\n> > > management layers. The new table introduced in OVSDB is like below.\n> > >\n> > > The solution I want to go, however, is different though. I was\n> > > thinking to introduce few DPDK rte_flow APIs and structs to define\n> > > the NIC flow capabilities.\n> > [Sugesh] technically rte_flow is for flow programming and not for device\n> capabilities.\n> \n> Not really. rte_flow is just a framework, it needs the underlaying NIC to do\n> the real thing. Each NIC has different limitations (we have seen quite few of\n> them). Thus, we need something like this.\n> \n> If you think this way: device capabilities regarding to flow, it may make more\n> sense to you :)\n[Sugesh] For our use case , we are have more features to be considered/wanted to\nexpose. Those are not really a 'flow' attribute. Instead they are the device properties\nthat necessary to decide a flow is offload'able/not.\n\n> \n> > Again if DPDK can have such API in rte_flow. I think it should be fine.\n> \n> Good! I will make a proposal to DPDK for v18.02 then.\n[Sugesh] Also its worth looking at the new port representor\nmodel in DPDK. The reason being, we are planning to propose an extension to it\nfor exposing device capabilities for our use case :)\n\n> \n> > > > 4) AFAIK, these hardware programmability for a NIC/not for a specific\n> port.\n> > > i.e the FDIR/RSS hash configuration are device specific. This will\n> > > be an issue if a NIC shared between kernel and DPDK drivers?\n> > >\n> > > That might be NIC specific. What do you mean by sharing between\n> > > kernel and DPDK? In most NICs I'm aware of, it's requried to unbind\n> > > the kernel driver first. Thus, it won't be shared. For Mellanox, the\n> > > control unit is based on queues, thus it could be shared correctly.\n> > [Sugesh] What I meant by that is, consider a case of NIC with 4*10G ports.\n> > 2 ports bound to DPDK and 2 ports to kernel.\n> \n> I see.\n> \n> > If I remember correctly XL710 NIC can support total 8k exact match\n> > flow entries in its Flow director. Similarly some other resources are also\n> shared across all the ports in the NIC.\n> > Now how these resources are properly managed between Kernel and\n> DPDK.\n> \n> Honestly, I don't know. We may need testings/investigations.\n[Sugesh] yes.\n> \n> > I agree that Mellanox NICs this should be fine, but not sure if it\n> > work on all the NICs out there. This will make adverse effect on each other\n> when making changes to any global configuration.\n> \n> For sure I agree we should make it work on as many nics as possible.\n> And I think that's what this patchset trying to do.\n[Sugesh] Sure, Thank you!\n> \n> \t--yliu","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","dev@openvswitch.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","ovs-dev@mail.linuxfoundation.org"],"Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=openvswitch.org\n\t(client-ip=140.211.169.12; helo=mail.linuxfoundation.org;\n\tenvelope-from=ovs-dev-bounces@openvswitch.org;\n\treceiver=)","Received":["from mail.linuxfoundation.org (mail.linuxfoundation.org\n\t[140.211.169.12])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xrQ6w66PGz9sBd\n\tfor ;\n\tMon, 11 Sep 2017 21:04:39 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id 5BD43BF0;\n\tMon, 11 Sep 2017 11:04:36 +0000 (UTC)","from smtp1.linuxfoundation.org (smtp1.linux-foundation.org\n\t[172.17.192.35])\n\tby mail.linuxfoundation.org (Postfix) with ESMTPS id 7B2AAAF7\n\tfor ; Mon, 11 Sep 2017 11:04:35 +0000 (UTC)","from mga03.intel.com (mga03.intel.com [134.134.136.65])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id E77CF203\n\tfor ; Mon, 11 Sep 2017 11:04:34 +0000 (UTC)","from fmsmga004.fm.intel.com ([10.253.24.48])\n\tby orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t11 Sep 2017 04:04:30 -0700","from irsmsx104.ger.corp.intel.com ([163.33.3.159])\n\tby fmsmga004.fm.intel.com with ESMTP; 11 Sep 2017 04:04:29 -0700","from irsmsx102.ger.corp.intel.com ([169.254.2.59]) by\n\tIRSMSX104.ger.corp.intel.com ([163.33.3.159]) with mapi id\n\t14.03.0319.002; Mon, 11 Sep 2017 12:04:28 +0100"],"X-Greylist":"domain auto-whitelisted by SQLgrey-1.7.6","X-ExtLoop1":"1","X-IronPort-AV":"E=Sophos;i=\"5.42,377,1500966000\"; d=\"scan'208\";a=\"310272054\"","From":"\"Chandran, Sugesh\" ","To":"Yuanhan Liu ","Thread-Topic":"[ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow","Thread-Index":"AQHTJijOgvfPmJ9h+UuHtoiz+CDsHaKuK+uggAEy7wCAABuZoP//+FKAgAAZx0A=","Date":"Mon, 11 Sep 2017 11:04:27 +0000","Message-ID":"<2EF2F5C0CC56984AA024D0B180335FCB4221E159@IRSMSX102.ger.corp.intel.com>","References":"<1504603381-30071-1-git-send-email-yliu@fridaylinux.org>\n\t<2EF2F5C0CC56984AA024D0B180335FCB4221DC02@IRSMSX102.ger.corp.intel.com>\n\t<20170911091136.GW9736@yliu-home>\n\t<2EF2F5C0CC56984AA024D0B180335FCB4221E089@IRSMSX102.ger.corp.intel.com>\n\t<20170911102253.GC9736@yliu-home>","In-Reply-To":"<20170911102253.GC9736@yliu-home>","Accept-Language":"en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","x-titus-metadata-40":"eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYjNiNDE5N2QtZTBkZS00OTgyLTgyZjEtZjVmYmM1OGU2MjY2IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6IlN6TmRnZTJTOXNTdlQ2UEdyc2paZkEzcjlnaUtOZ25VaEIzSWVIQ2VoYXc9In0=","x-ctpclassification":"CTP_IC","dlp-product":"dlpe-windows","dlp-version":"11.0.0.116","dlp-reaction":"no-action","x-originating-ip":"[163.33.239.180]","MIME-Version":"1.0","X-Spam-Status":"No, score=-5.0 required=5.0 tests=RCVD_IN_DNSWL_HI,\n\tRP_MATCHES_RCVD autolearn=disabled version=3.3.1","X-Spam-Checker-Version":"SpamAssassin 3.3.1 (2010-03-16) on\n\tsmtp1.linux-foundation.org","Cc":"\"dev@openvswitch.org\" ","Subject":"Re: [ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow","X-BeenThere":"ovs-dev@openvswitch.org","X-Mailman-Version":"2.1.12","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"ovs-dev-bounces@openvswitch.org","Errors-To":"ovs-dev-bounces@openvswitch.org"}},{"id":1767451,"web_url":"http://patchwork.ozlabs.org/comment/1767451/","msgid":"","list_archive_url":null,"date":"2017-09-13T01:48:16","subject":"Re: [ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow","submitter":{"id":72097,"url":"http://patchwork.ozlabs.org/api/people/72097/","name":"Patil, Harish","email":"Harish.Patil@cavium.com"},"content":"-----Original Message-----\r\nFrom: Yuanhan Liu \r\nDate: Thursday, September 7, 2017 at 6:58 PM\r\nTo: Harish Patil \r\nCc: Finn Christensen , \"dev@openvswitch.org\"\r\n, \"dball@vmware.com\" \r\nSubject: Re: [ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow\r\n\r\n>On Thu, Sep 07, 2017 at 06:52:49PM +0000, Patil, Harish wrote:\r\n>> >Hi all,\r\n>> >\r\n>> >Can you please confirm that you are supporting offloading of both the\r\n>>EMC\r\n>> >flows and DPCLs (megaflows) here, i.e. OVS would skip hash table\r\n>>lookups\r\n>> >in both the cases if UFID is provided in the MBUF. Assuming that is\r\n>> >correct, when a match is found in dpcls, does OVS insert that new flow\r\n>> >back into the EMC cache?\r\n>> >\r\n>> >Thanks,\r\n>> >Harish\r\n>> >\r\n>> >[Finn]\r\n>> >Yes, you are correct. Once the megaflow is offloaded into NIC, using\r\n>>the\r\n>> >flow UFID,\r\n>> >the EMC and megaflow cache (dpcls) is skipped when a UFID is received\r\n>>in\r\n>> >mbuf. When\r\n>> >receiving these pre-classified packets the EMC is not needed. However,\r\n>> >the initial packet\r\n>> >creating the megaflow (and then also creates the NIC rte flow), will be\r\n>> >inserted into EMC.\r\n>> \r\n>> [Harish] Thanks Finn for confirming the behavior.\r\n>> \r\n>> \r\n>> >But, new flows that would use the same megaflow, but would create a\r\n>> >different EMC entry,\r\n>> >will not be inserted/created in EMC when offloaded by NIC.\r\n>> \r\n>> [Harish I did not fully understand this part. Can you pls elaborate and\r\n>> possibly with an example?\r\n>\r\n>It's megaflow cache being offloaded. And the EMC is skipped completely\r\n>once there are flow mark in the recved pkts. Thus, it doesn't matter\r\n>whether EMC will be inserted back.\r\n>\r\n>Talking about that, I probably need move the \"mark -> flow\" code to\r\n>dpcls but not in emc_processing. Darrel, just let me know which one\r\n>you prefer.\r\n>\r\n>> [Harish] I have another question:\r\n>> There was a patch series (11/11) submitted regarding offloading dpcls\r\n>>from\r\n>> Shachar Beiser.\r\n>> \r\n>> [ovs-dev] [PATCH 00/11] Data Path Classifier Offloading\r\n>> ..\r\n>> ..\r\n>> [ovs-dev] [PATCH 11/11] ovs/dp-cls: inserting rule to HW from\toffloading\r\n>> thread context.\r\n>> \r\n>> \r\n>> This does not use RTE_FLOW filtering framework. I don’t know status of\r\n>> this patch series.\r\n>> But this is very similar to what is being achieved with your current\r\n>>patch\r\n>> series using RTE_FLOW.\r\n>> Which one will be accepted in the end in the mainline OVS branch?\r\n>\r\n>As it's been stated in the first sentence of my cover letter, it's a\r\n>joint work from Mellanox and Napatech. Shachar (who is from Mellanox)\r\n>does't have time to work on this project anymore, leaving me (who is\r\n>also from Mellanox) to continue the work. And then my choice was to\r\n>continue it based on what Napatech already had, for a simple reason:\r\n>it's simpler.\r\n>\r\n>OTOH, do you see anything missing in this patchset, comparing the one\r\n>from Shachar?\r\n>\r\n>\t--yliu\r\n\r\n[Harish] Thanks for clarifying this. So that’s fine.\r\nSince I saw two independent patch series I was not sure what happened to\r\nthe one Shachar posted.\r\nThe only difference I saw was that the current patch uses rte_flow and the\r\nearlier used legacy filtering framework.\r\nAnyway its clear to me now, thanks.\r\n\r\n\r\n\r\n>","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","dev@openvswitch.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","ovs-dev@mail.linuxfoundation.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=openvswitch.org\n\t(client-ip=140.211.169.12; helo=mail.linuxfoundation.org;\n\tenvelope-from=ovs-dev-bounces@openvswitch.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=CAVIUMNETWORKS.onmicrosoft.com\n\theader.i=@CAVIUMNETWORKS.onmicrosoft.com header.b=\"M+yw5FQl\"; \n\tdkim-atps=neutral","spf=none (sender IP is )\n\tsmtp.mailfrom=Harish.Patil@cavium.com; "],"Received":["from mail.linuxfoundation.org (mail.linuxfoundation.org\n\t[140.211.169.12])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xsPh80v5Nz9t30\n\tfor ;\n\tWed, 13 Sep 2017 11:48:23 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id 3E052A91;\n\tWed, 13 Sep 2017 01:48:21 +0000 (UTC)","from smtp1.linuxfoundation.org (smtp1.linux-foundation.org\n\t[172.17.192.35])\n\tby mail.linuxfoundation.org (Postfix) with ESMTPS id 3E14FA48\n\tfor ; Wed, 13 Sep 2017 01:48:20 +0000 (UTC)","from NAM02-CY1-obe.outbound.protection.outlook.com\n\t(mail-cys01nam02on0040.outbound.protection.outlook.com\n\t[104.47.37.40])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id 60E09124\n\tfor ; Wed, 13 Sep 2017 01:48:19 +0000 (UTC)","from MWHPR07MB3184.namprd07.prod.outlook.com (10.172.96.142) by\n\tMWHPR07MB2832.namprd07.prod.outlook.com (10.169.230.146) with\n\tMicrosoft SMTP Server (version=TLS1_2,\n\tcipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id\n\t15.20.56.11; Wed, 13 Sep 2017 01:48:16 +0000","from MWHPR07MB3184.namprd07.prod.outlook.com ([10.172.96.142]) by\n\tMWHPR07MB3184.namprd07.prod.outlook.com ([10.172.96.142]) with\n\tmapi id 15.20.0035.021; Wed, 13 Sep 2017 01:48:16 +0000"],"X-Greylist":"whitelisted by SQLgrey-1.7.6","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com;\n\th=From:Date:Subject:Message-ID:Content-Type:MIME-Version;\n\tbh=BaVsq2+Wqif2643qYestKKckOXmNtlD/nzcOaRLpckQ=;\n\tb=M+yw5FQlmtJHEhQPyuzqTw6vuqCoJ5DTj8DZiJlE5SlVXpP7W9lBTTftHRR0RY23aO9VUuwC28/IhZRuYeHtwED9nmlRvQb4yS8j6WwE7FXbqK0FYjRQjoFSc9qk60Zfm7y3RxPG08o+NwaMkhgQsU7dMZk9gVfXq35zo6ESVyY=","From":"\"Patil, Harish\" ","To":"Yuanhan Liu ","Thread-Topic":"[ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow","Thread-Index":"AQHTJiis1qmE8mZPnEmWdPSqy/YW+aKm8nEAgAB62gCAAeYIgIAA7GSAgAdjVgA=","Date":"Wed, 13 Sep 2017 01:48:16 +0000","Message-ID":"","References":"<1504603381-30071-1-git-send-email-yliu@fridaylinux.org>\n\t\n\t\n\t\n\t<20170908015851.GD9736@yliu-home>","In-Reply-To":"<20170908015851.GD9736@yliu-home>","Accept-Language":"en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","authentication-results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=openvswitch.org\n\t(client-ip=140.211.169.12; helo=mail.linuxfoundation.org;\n\tenvelope-from=ovs-dev-bounces@openvswitch.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=CAVIUMNETWORKS.onmicrosoft.com\n\theader.i=@CAVIUMNETWORKS.onmicrosoft.com header.b=\"M+yw5FQl\"; \n\tdkim-atps=neutral","spf=none (sender IP is )\n\tsmtp.mailfrom=Harish.Patil@cavium.com; "],"x-originating-ip":"[198.186.0.2]","x-ms-publictraffictype":"Email","x-microsoft-exchange-diagnostics":"1; MWHPR07MB2832;\n\t6:QeJhYTmwnPbXyf/xQXMxFSip/KhxZq6IyCwBlDPMw2bE2Wy4eMcuQ9Fy+Qa1sVsGbhQ8p3+l3GXQtKyb29cZYdj9dyufNkdMPfzVr92s0ndqbxYivw/n+t5wsKc73xwk1zRXyR61dL4KsJMvA5Op2D1oRapAToBWIRDnZLmHmd8W+edP/fHTyzLQtUL/rMYMtjZiN+RewoHD+9XcKKdACboTp/WUBz3aQ5y4lWB/lRAHXm+gHMjR94RyzJtWpOcgl79Wo5BjZQbWQjBXNg7/Jq/GZ/MxlNZIcIJTjE8fTAQ16cqrib02vd6zF8kMSP7ttSxO2XBmjsFrFfCPaNaD2g==;\n\t5:eF+kCl4iGwEN/vlDYwEC6vKzMXKUpF7NKM6Le05KKeai478Obr9LKHupgblcCf/7jSrwXD8JpFfA+IDxFDZW1S3QrZET1Dj5IHNibi6D8Vd3bYOSjKxupzzJX0xTpkmJCj8YksuZufh4abm4mFfhQA==;\n\t24:2nNzXWQBk0Vmv8zZsS1DTRUDiP1NBYzCxjjnvJCtBzp5UQO24IGK1CjLoXxAenS1FMgdib/7+q+6SYCR5LIc9vWwEHM3VjuQcmFZJkXdYIM=;\n\t7:C/6qqotskb7bMYmjFRQJa+6jROexGxH3vAFar2X/Z047vtb9pphqYL9c9pS+8ZvJJ5uVlG/TeBBvkpiWeMHuzo6zHtdgmYO4egLQInNcYsdH0omzSe/+uBpX/uVOywO/BAn0IFzE4nUq3HXO5UETW4rdQm7cmnmMhqGO0Wpw3vLLyNSlphifpZm8aM8S8LlavlvaoMmXXYpMVFmVkOeNEc22qLajawFo1InT54cNUKo=","x-ms-exchange-antispam-srfa-diagnostics":"SSOS;","x-ms-office365-filtering-correlation-id":"042d506b-29d3-4ea0-00b8-08d4fa4980d9","x-microsoft-antispam":"UriScan:; BCL:0; PCL:0;\n\tRULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);\n\tSRVR:MWHPR07MB2832; ","x-ms-traffictypediagnostic":"MWHPR07MB2832:","x-exchange-antispam-report-test":"UriScan:(61668805478150)(216315784871565);","x-microsoft-antispam-prvs":"","x-exchange-antispam-report-cfa-test":"BCL:0; PCL:0;\n\tRULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6041248)(20161123560025)(20161123558100)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);\n\tSRVR:MWHPR07MB2832; BCL:0; PCL:0;\n\tRULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);\n\tSRVR:MWHPR07MB2832; ","x-forefront-prvs":"042957ACD7","x-forefront-antispam-report":"SFV:NSPM;\n\tSFS:(10009020)(6009001)(346002)(366002)(376002)(377454003)(199003)(53754006)(24454002)(13464003)(189002)(68736007)(189998001)(478600001)(54356999)(2906002)(50986999)(76176999)(3660700001)(105586002)(25786009)(106356001)(5660300001)(93886005)(2900100001)(101416001)(3280700002)(229853002)(72206003)(97736004)(14454004)(53546010)(36756003)(6246003)(3846002)(2950100002)(6916009)(81166006)(6116002)(102836003)(81156014)(6436002)(8936002)(77096006)(66066001)(6506006)(99286003)(4326008)(7736002)(53936002)(6512007)(305945005)(8676002)(54906002)(6486002)(86362001)(110136004)(316002);\n\tDIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR07MB2832;\n\tH:MWHPR07MB3184.namprd07.prod.outlook.com; FPR:; SPF:None;\n\tPTR:InfoNoRecords; A:1; MX:1; LANG:en; ","received-spf":"None (protection.outlook.com: cavium.com does not designate\n\tpermitted sender hosts)","spamdiagnosticoutput":"1:99","spamdiagnosticmetadata":"NSPM","Content-ID":"","MIME-Version":"1.0","X-OriginatorOrg":"cavium.com","X-MS-Exchange-CrossTenant-originalarrivaltime":"13 Sep 2017 01:48:16.6406\n\t(UTC)","X-MS-Exchange-CrossTenant-fromentityheader":"Hosted","X-MS-Exchange-CrossTenant-id":"711e4ccf-2e9b-4bcf-a551-4094005b6194","X-MS-Exchange-Transport-CrossTenantHeadersStamped":"MWHPR07MB2832","X-Spam-Status":"No, score=0.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,\n\tRCVD_IN_DNSWL_NONE autolearn=disabled version=3.3.1","X-Spam-Checker-Version":"SpamAssassin 3.3.1 (2010-03-16) on\n\tsmtp1.linux-foundation.org","Cc":"\"dev@openvswitch.org\" ","Subject":"Re: [ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow","X-BeenThere":"ovs-dev@openvswitch.org","X-Mailman-Version":"2.1.12","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Sender":"ovs-dev-bounces@openvswitch.org","Errors-To":"ovs-dev-bounces@openvswitch.org"}},{"id":1767542,"web_url":"http://patchwork.ozlabs.org/comment/1767542/","msgid":"","list_archive_url":null,"date":"2017-09-13T04:14:48","subject":"Re: [ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow","submitter":{"id":68212,"url":"http://patchwork.ozlabs.org/api/people/68212/","name":"Darrell Ball","email":"dball@vmware.com"},"content":"On 9/7/17, 6:59 PM, \"Yuanhan Liu\" wrote:\r\n\r\n On Thu, Sep 07, 2017 at 06:52:49PM +0000, Patil, Harish wrote:\r\n > >Hi all,\r\n > >\r\n > >Can you please confirm that you are supporting offloading of both the EMC\r\n > >flows and DPCLs (megaflows) here, i.e. OVS would skip hash table lookups\r\n > >in both the cases if UFID is provided in the MBUF. Assuming that is\r\n > >correct, when a match is found in dpcls, does OVS insert that new flow\r\n > >back into the EMC cache?\r\n > >\r\n > >Thanks,\r\n > >Harish\r\n > >\r\n > >[Finn]\r\n > >Yes, you are correct. Once the megaflow is offloaded into NIC, using the\r\n > >flow UFID,\r\n > >the EMC and megaflow cache (dpcls) is skipped when a UFID is received in\r\n > >mbuf. When\r\n > >receiving these pre-classified packets the EMC is not needed. However,\r\n > >the initial packet\r\n > >creating the megaflow (and then also creates the NIC rte flow), will be\r\n > >inserted into EMC.\r\n > \r\n > [Harish] Thanks Finn for confirming the behavior.\r\n > \r\n > \r\n > >But, new flows that would use the same megaflow, but would create a\r\n > >different EMC entry,\r\n > >will not be inserted/created in EMC when offloaded by NIC.\r\n > \r\n > [Harish I did not fully understand this part. Can you pls elaborate and\r\n > possibly with an example?\r\n \r\n It's megaflow cache being offloaded. And the EMC is skipped completely\r\n once there are flow mark in the recved pkts. Thus, it doesn't matter\r\n whether EMC will be inserted back.\r\n \r\n Talking about that, I probably need move the \"mark -> flow\" code to\r\n dpcls but not in emc_processing. Darrel, just let me know which one\r\n you prefer.\r\n\r\n[Darrell] sorry, too many e-mails.\r\n I had some related comments to share, but yes.\r\n Probably fast_path_processing().\r\n\r\n\r\n \r\n > [Harish] I have another question:\r\n > There was a patch series (11/11) submitted regarding offloading dpcls from\r\n > Shachar Beiser.\r\n > \r\n > [ovs-dev] [PATCH 00/11] Data Path Classifier Offloading\r\n > ..\r\n > ..\r\n > [ovs-dev] [PATCH 11/11] ovs/dp-cls: inserting rule to HW from\toffloading\r\n > thread context.\r\n > \r\n > \r\n > This does not use RTE_FLOW filtering framework. I don’t know status of\r\n > this patch series.\r\n > But this is very similar to what is being achieved with your current patch\r\n > series using RTE_FLOW.\r\n > Which one will be accepted in the end in the mainline OVS branch?\r\n \r\n As it's been stated in the first sentence of my cover letter, it's a\r\n joint work from Mellanox and Napatech. Shachar (who is from Mellanox)\r\n does't have time to work on this project anymore, leaving me (who is\r\n also from Mellanox) to continue the work. And then my choice was to\r\n continue it based on what Napatech already had, for a simple reason:\r\n it's simpler.\r\n \r\n OTOH, do you see anything missing in this patchset, comparing the one\r\n from Shachar?\r\n \r\n \t--yliu","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","dev@openvswitch.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","ovs-dev@mail.linuxfoundation.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=openvswitch.org\n\t(client-ip=140.211.169.12; helo=mail.linuxfoundation.org;\n\tenvelope-from=ovs-dev-bounces@openvswitch.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=onevmw.onmicrosoft.com\n\theader.i=@onevmw.onmicrosoft.com header.b=\"PKN8AZQH\"; \n\tdkim-atps=neutral","spf=none (sender IP is )\n\tsmtp.mailfrom=dball@vmware.com; "],"Received":["from mail.linuxfoundation.org (mail.linuxfoundation.org\n\t[140.211.169.12])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xsSxF5KzYz9sPt\n\tfor ;\n\tWed, 13 Sep 2017 14:14:56 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id 4E29EACA;\n\tWed, 13 Sep 2017 04:14:54 +0000 (UTC)","from smtp1.linuxfoundation.org (smtp1.linux-foundation.org\n\t[172.17.192.35])\n\tby mail.linuxfoundation.org (Postfix) with ESMTPS id C652DAB2\n\tfor ; Wed, 13 Sep 2017 04:14:52 +0000 (UTC)","from NAM03-DM3-obe.outbound.protection.outlook.com\n\t(mail-dm3nam03on0086.outbound.protection.outlook.com [104.47.41.86])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0720C180\n\tfor ; Wed, 13 Sep 2017 04:14:51 +0000 (UTC)","from BLUPR05MB611.namprd05.prod.outlook.com (10.141.204.27) by\n\tBLUPR05MB053.namprd05.prod.outlook.com (10.255.210.139) with\n\tMicrosoft SMTP Server (version=TLS1_2,\n\tcipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id\n\t15.20.56.4; Wed, 13 Sep 2017 04:14:48 +0000","from BLUPR05MB611.namprd05.prod.outlook.com ([10.141.204.27]) by\n\tBLUPR05MB611.namprd05.prod.outlook.com ([10.141.204.27]) with mapi id\n\t15.20.0056.010; Wed, 13 Sep 2017 04:14:48 +0000"],"X-Greylist":"whitelisted by SQLgrey-1.7.6","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=onevmw.onmicrosoft.com; s=selector1-vmware-com;\n\th=From:Date:Subject:Message-ID:Content-Type:MIME-Version;\n\tbh=ZYFZZs6BoE5X1KuWucuG+5B5UCUGEkKG2Ii6qZYzfu0=;\n\tb=PKN8AZQHABD/XDXvN2TFgOCe/14vN7vvvLTUizCd5QFah/Dfpfys3hkn1FlYJYssRfZ82AZvE9VA9M3eTXChTKrvd0ktdVIWyFyuNmYG0ZkHnTShey8kN3qoYTzAzOBCpSWZ7BSitBphCgnFszKQbQ5AHw8ZQ0A/RUz9erymwzg=","From":"Darrell Ball ","To":"Yuanhan Liu , \"Patil, Harish\"\n\t","Thread-Topic":"[ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow","Thread-Index":"AQHTJiipBu7FvFt0oUWvIx2Z7IEtEqKnZ8wAgAAFfwCAAltkgIAAdwiAgAeMSoA=","Date":"Wed, 13 Sep 2017 04:14:48 +0000","Message-ID":"","References":"<1504603381-30071-1-git-send-email-yliu@fridaylinux.org>\n\t\n\t\n\t\n\t<20170908015851.GD9736@yliu-home>","In-Reply-To":"<20170908015851.GD9736@yliu-home>","Accept-Language":"en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","user-agent":"Microsoft-MacOutlook/f.25.0.170815","authentication-results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=openvswitch.org\n\t(client-ip=140.211.169.12; helo=mail.linuxfoundation.org;\n\tenvelope-from=ovs-dev-bounces@openvswitch.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=onevmw.onmicrosoft.com\n\theader.i=@onevmw.onmicrosoft.com header.b=\"PKN8AZQH\"; \n\tdkim-atps=neutral","spf=none (sender IP is )\n\tsmtp.mailfrom=dball@vmware.com; "],"x-originating-ip":"[73.162.236.45]","x-ms-publictraffictype":"Email","x-microsoft-exchange-diagnostics":"1; BLUPR05MB053;\n\t20:kwTs1PBCMGRN8MZ+nW6+KwcsZPeFMympbiZfKS56ZAUe7aJ3YcQEWnVDcOM22jxPS5Xuk/SKlvhpI7N2f8FVqw5elghDikTb6rUIpoxnJ0QFbRKe6iLsK05xRT8Wgb4oHJJMPp5VmSqO7U/TpERC2kfA9s/NnEfL1oVtw29927M=","x-ms-exchange-antispam-srfa-diagnostics":"SSOS;","x-ms-office365-filtering-correlation-id":"abba0b4d-774b-4562-f5a0-08d4fa5df922","x-microsoft-antispam":"UriScan:; BCL:0; PCL:0;\n\tRULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);\n\tSRVR:BLUPR05MB053; ","x-ms-traffictypediagnostic":"BLUPR05MB053:","x-exchange-antispam-report-test":"UriScan:;","x-microsoft-antispam-prvs":"","x-exchange-antispam-report-cfa-test":"BCL:0; PCL:0;\n\tRULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(6041248)(20161123555025)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);\n\tSRVR:BLUPR05MB053; BCL:0; PCL:0;\n\tRULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);\n\tSRVR:BLUPR05MB053; ","x-forefront-prvs":"042957ACD7","x-forefront-antispam-report":"SFV:NSPM;\n\tSFS:(10009020)(6009001)(366002)(39860400002)(376002)(346002)(189002)(199003)(24454002)(53754006)(377454003)(86362001)(93886005)(53546010)(50986999)(68736007)(76176999)(54356999)(101416001)(305945005)(7736002)(6246003)(5660300001)(478600001)(105586002)(99286003)(6512007)(54906002)(53936002)(106356001)(4326008)(82746002)(33656002)(8676002)(81156014)(81166006)(8936002)(36756003)(97736004)(6436002)(2900100001)(4001350100001)(189998001)(77096006)(83506001)(66066001)(83716003)(316002)(2906002)(6486002)(25786009)(229853002)(3280700002)(6506006)(3846002)(14454004)(102836003)(6116002)(3660700001)(2950100002);\n\tDIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB053;\n\tH:BLUPR05MB611.namprd05.prod.outlook.com; FPR:; SPF:None;\n\tPTR:InfoNoRecords; MX:1; A:1; LANG:en; ","received-spf":"None (protection.outlook.com: vmware.com does not designate\n\tpermitted sender hosts)","spamdiagnosticoutput":"1:99","spamdiagnosticmetadata":"NSPM","Content-ID":"","MIME-Version":"1.0","X-OriginatorOrg":"vmware.com","X-MS-Exchange-CrossTenant-originalarrivaltime":"13 Sep 2017 04:14:48.3240\n\t(UTC)","X-MS-Exchange-CrossTenant-fromentityheader":"Hosted","X-MS-Exchange-CrossTenant-id":"b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0","X-MS-Exchange-Transport-CrossTenantHeadersStamped":"BLUPR05MB053","X-Spam-Status":"No, score=0.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,\n\tRCVD_IN_DNSWL_NONE autolearn=disabled version=3.3.1","X-Spam-Checker-Version":"SpamAssassin 3.3.1 (2010-03-16) on\n\tsmtp1.linux-foundation.org","Cc":"\"dev@openvswitch.org\" ","Subject":"Re: [ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow","X-BeenThere":"ovs-dev@openvswitch.org","X-Mailman-Version":"2.1.12","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Sender":"ovs-dev-bounces@openvswitch.org","Errors-To":"ovs-dev-bounces@openvswitch.org"}}]