[{"id":1765514,"web_url":"http://patchwork.ozlabs.org/comment/1765514/","msgid":"<20170908164831.GG7356@vergenet.net>","list_archive_url":null,"date":"2017-09-08T16:48:32","subject":"Re: [ovs-dev] [PATCH v2 5/8] dpif-netdev: record rx queue id for\n\tthe upcall","submitter":{"id":64714,"url":"http://patchwork.ozlabs.org/api/people/64714/","name":"Simon Horman","email":"simon.horman@netronome.com"},"content":"On Tue, Sep 05, 2017 at 05:22:58PM +0800, Yuanhan Liu wrote:\n> From: Shachar Beiser \n> \n> For the DPDK flow offload, which basically just binds a MARK action to\n> a flow, the MARK is required to be used together with a QUEUE action for\n> the most NICs I'm aware of. The QUEUE action then needs a queue index,\n> which is not given in the flow content.\n> \n> Here we record the rx queue while recieving the pkts to solve above issue.\n> \n> Co-authored-by: Yuanhan Liu \n> Signed-off-by: Shachar Beiser \n> Signed-off-by: Yuanhan Liu \n\nThis seems fine to me but I do not feel that I am in a position to\ngive it a formal review.","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=netronome-com.20150623.gappssmtp.com\n\theader.i=@netronome-com.20150623.gappssmtp.com\n\theader.b=\"OgLpRoBr\"; 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 3xpjxC6fLJz9s7h\n\tfor ;\n\tSat, 9 Sep 2017 02:50:23 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id 35135BE0;\n\tFri, 8 Sep 2017 16:48:35 +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 6D869BD1\n\tfor ; Fri, 8 Sep 2017 16:48:34 +0000 (UTC)","from mail-wm0-f43.google.com (mail-wm0-f43.google.com\n\t[74.125.82.43])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5153A469\n\tfor ; Fri, 8 Sep 2017 16:48:33 +0000 (UTC)","by mail-wm0-f43.google.com with SMTP id f145so7350607wme.0\n\tfor ; Fri, 08 Sep 2017 09:48:33 -0700 (PDT)","from vergenet.net (53.red-80-24-208.staticip.rima-tde.net.\n\t[80.24.208.53]) by smtp.gmail.com with ESMTPSA id\n\to22sm2161619wrc.65.2017.09.08.09.48.30\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tFri, 08 Sep 2017 09:48:31 -0700 (PDT)"],"X-Greylist":"whitelisted by SQLgrey-1.7.6","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=netronome-com.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=ZyRGTdq/UDrjgIyzEJBHoCQ5Zl6Ii3erDI/t7P32UU0=;\n\tb=OgLpRoBra+FZ5Ke+IcG2+KiCjUGw/WF8HJoya1Ua1sBfKjjsihfBfX1NTDM+3KWx3n\n\tHh9jNr9wHwlYbOvhgUx5hgvuegSG/hR2RdqtMHQoedsLijgjPytxRD6EM9Z08Nmvf68t\n\t4dEfQP+LxSNaRt/cj8TRBXWdOq/CNDQGGCXy9zdomNXKfhMUfBtc3sqak01pHdYflX3v\n\tG37Wn9bF2MnuewmLmP/eKH8cMHXCN5RivKu/1ZrMpAzneo7XTL1+CKXYJE0iMpmQbTL9\n\tgMBhOiYB6/vjW3yO3EGjoJwrywj8enxhKo/SxcGJyJ7s+PS/8CKshSBn0G5pPIdQTOjM\n\tU+SA==","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=ZyRGTdq/UDrjgIyzEJBHoCQ5Zl6Ii3erDI/t7P32UU0=;\n\tb=Eh6lZ5mETLWsEYfbJX+vWYYnzG+KcKkfuAJWoUyTBEiRwSCyqrmDDKtcdeMscEVdjX\n\tSC8pdSyjU4wMVqK7xEc5bt5JG/8CBfnMaQ1aE4HrA6pXcL6vZNnvcUuJQ9MHqXhC39mU\n\tmTyT6XU6Jdfly7+56quFP/NgH3ajK0E1n7/GqWO9MG4C5nPPm0JzN4qw5+EZGHsw+Z2a\n\ttMka1fbG0fe3K045fFUmakEQsh/rnYEjRMJr3N32EiqxNBaBH7A5ZlDOthAh61niXPGw\n\tt92G/yz+rnOSYKzU68QquylMrsVtoLJUVKg2Aq6TuD5q6Z/f5vIaOjFZyfWyVahJwnaj\n\tBdbw==","X-Gm-Message-State":"AHPjjUiTtVZBHTm6chRbfxFgE9syfPTkXpYEGpV2yhecBOHBrfimiTEk\n\t0YtnaSYSgkQp9BWz","X-Google-Smtp-Source":"ADKCNb4ZvxHiDrOxspa3vPM1XIQJqvOpEfz000q2KPMo4wHzn3GxHjhCB+tpZ0Sgi3UiMMIEkMAL+w==","X-Received":"by 10.28.144.202 with SMTP id s193mr2072560wmd.74.1504889311934; \n\tFri, 08 Sep 2017 09:48:31 -0700 (PDT)","Date":"Fri, 8 Sep 2017 18:48:32 +0200","From":"Simon Horman ","To":"Yuanhan Liu ","Message-ID":"<20170908164831.GG7356@vergenet.net>","References":"<1504603381-30071-1-git-send-email-yliu@fridaylinux.org>\n\t<1504603381-30071-6-git-send-email-yliu@fridaylinux.org>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<1504603381-30071-6-git-send-email-yliu@fridaylinux.org>","User-Agent":"Mutt/1.5.23 (2014-03-12)","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 5/8] dpif-netdev: record rx queue id for\n\tthe upcall","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":1765970,"web_url":"http://patchwork.ozlabs.org/comment/1765970/","msgid":"<2EF2F5C0CC56984AA024D0B180335FCB4221DC55@IRSMSX102.ger.corp.intel.com>","list_archive_url":null,"date":"2017-09-10T16:40:10","subject":"Re: [ovs-dev] [PATCH v2 5/8] dpif-netdev: record rx queue id for\n\tthe\tupcall","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: 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 5/8] dpif-netdev: record rx queue id for the\n> upcall\n> \n> From: Shachar Beiser \n> \n> For the DPDK flow offload, which basically just binds a MARK action to a flow,\n> the MARK is required to be used together with a QUEUE action for the most\n> NICs I'm aware of. The QUEUE action then needs a queue index, which is not\n> given in the flow content.\n[Sugesh] Looks to me this is again another hardware specific req.\nThis could have impact on RSS hash distribution and queue redistribution across pmds\nat runtime.\n\n> \n> Here we record the rx queue while recieving the pkts to solve above issue.\n> \n> Co-authored-by: Yuanhan Liu \n> Signed-off-by: Shachar Beiser \n> Signed-off-by: Yuanhan Liu \n> ---\n> lib/dp-packet.h | 1 +\n> lib/dpif-netdev.c | 14 +++++++++-----\n> lib/netdev.c | 1 +\n> lib/netdev.h | 1 +\n> 4 files changed, 12 insertions(+), 5 deletions(-)\n> \n> diff --git a/lib/dp-packet.h b/lib/dp-packet.h index a7a062f..479a734 100644\n> --- a/lib/dp-packet.h\n> +++ b/lib/dp-packet.h\n> @@ -709,6 +709,7 @@ enum { NETDEV_MAX_BURST = 32 }; /* Maximum\n> number packets in a batch. */ struct dp_packet_batch {\n> size_t count;\n> bool trunc; /* true if the batch needs truncate. */\n> + int rxq;\n> struct dp_packet *packets[NETDEV_MAX_BURST]; };\n> \n> diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c index a95b8d4..3099c73\n> 100644\n> --- a/lib/dpif-netdev.c\n> +++ b/lib/dpif-netdev.c\n> @@ -2474,7 +2474,8 @@ out:\n> static struct dp_netdev_flow *\n> dp_netdev_flow_add(struct dp_netdev_pmd_thread *pmd,\n> struct match *match, const ovs_u128 *ufid,\n> - const struct nlattr *actions, size_t actions_len)\n> + const struct nlattr *actions, size_t actions_len,\n> + int rxq)\n> OVS_REQUIRES(pmd->flow_mutex)\n> {\n> struct dp_netdev_flow *flow;\n> @@ -2527,6 +2528,7 @@ dp_netdev_flow_add(struct\n> dp_netdev_pmd_thread *pmd,\n> dp_netdev_alloc_flow_mark(pmd, &info.flow_mark)) {\n> struct dp_netdev_port *port;\n> port = dp_netdev_lookup_port(pmd->dp, in_port);\n> + info.rxq = rxq;\n> if (netdev_flow_put(port->netdev, match,\n> CONST_CAST(struct nlattr *, actions),\n> actions_len, ufid, &info, NULL) == 0) { @@ -2607,7 +2609,7 @@\n> flow_put_on_pmd(struct dp_netdev_pmd_thread *pmd,\n> if (put->flags & DPIF_FP_CREATE) {\n> if (cmap_count(&pmd->flow_table) < MAX_FLOWS) {\n> dp_netdev_flow_add(pmd, match, ufid, put->actions,\n> - put->actions_len);\n> + put->actions_len, -1);\n> error = 0;\n> } else {\n> error = EFBIG;\n> @@ -2635,6 +2637,7 @@ flow_put_on_pmd(struct dp_netdev_pmd_thread\n> *pmd,\n> in_port = netdev_flow->flow.in_port.odp_port;\n> port = dp_netdev_lookup_port(pmd->dp, in_port);\n> info.flow_mark = netdev_flow->mark;\n> + info.rxq = -1;\n> ret = netdev_flow_put(port->netdev, match,\n> CONST_CAST(struct nlattr *,\n> put->actions), @@ -5026,7 +5029,7 @@\n> handle_packet_upcall(struct dp_netdev_pmd_thread *pmd,\n> struct dp_packet *packet,\n> const struct netdev_flow_key *key,\n> struct ofpbuf *actions, struct ofpbuf *put_actions,\n> - int *lost_cnt, long long now)\n> + int *lost_cnt, long long now, int rxq)\n[Sugesh] IMHO its not really good practice to change the default packet processing path for\nsome specific hardware offload. Rxq doesn't have any meaning for handling the packets in normal path.\n\nWhy cant install flow on all the configured queues for a specific inport? Flow handling is per port, not per queue.\nThis will assure the packets will have mark even after the rss hash distribution. \n\nThis comment points to my previous suggestion to keep the flows per port than pmd. This will also take care\nscenarios like queue rescheduling across pmds, changing number of queues in a port.\n\n> {\n> struct ofpbuf *add_actions;\n> struct dp_packet_batch b;\n> @@ -5082,7 +5085,8 @@ handle_packet_upcall(struct\n> dp_netdev_pmd_thread *pmd,\n> if (OVS_LIKELY(!netdev_flow)) {\n> netdev_flow = dp_netdev_flow_add(pmd, &match, &ufid,\n> add_actions->data,\n> - add_actions->size);\n> + add_actions->size,\n> + rxq);\n> }\n> ovs_mutex_unlock(&pmd->flow_mutex);\n> emc_probabilistic_insert(pmd, key, netdev_flow); @@ -5152,7 +5156,7\n> @@ fast_path_processing(struct dp_netdev_pmd_thread *pmd,\n> \n> miss_cnt++;\n> handle_packet_upcall(pmd, packets[i], &keys[i], &actions,\n> - &put_actions, &lost_cnt, now);\n> + &put_actions, &lost_cnt, now,\n> + packets_->rxq);\n> }\n> \n> ofpbuf_uninit(&actions);\n> diff --git a/lib/netdev.c b/lib/netdev.c index b4e570b..c9b7019 100644\n> --- a/lib/netdev.c\n> +++ b/lib/netdev.c\n> @@ -700,6 +700,7 @@ netdev_rxq_recv(struct netdev_rxq *rx, struct\n> dp_packet_batch *batch)\n> \n> retval = rx->netdev->netdev_class->rxq_recv(rx, batch);\n> if (!retval) {\n> + batch->rxq = rx->queue_id;\n> COVERAGE_INC(netdev_received);\n> } else {\n> batch->count = 0;\n> diff --git a/lib/netdev.h b/lib/netdev.h index 2003165..28ad39d 100644\n> --- a/lib/netdev.h\n> +++ b/lib/netdev.h\n> @@ -194,6 +194,7 @@ struct offload_info {\n> * it will be in the pkt meta data.\n> */\n> uint32_t flow_mark;\n> + int rxq;\n> };\n> struct dpif_class;\n> struct netdev_flow_dump;\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 3xqxcy2ph5z9s0Z\n\tfor ;\n\tMon, 11 Sep 2017 02:40:34 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id 0294AAA6;\n\tSun, 10 Sep 2017 16:40:32 +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 4F65AA91\n\tfor ; Sun, 10 Sep 2017 16:40:30 +0000 (UTC)","from mga06.intel.com (mga06.intel.com [134.134.136.31])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9661741D\n\tfor ; Sun, 10 Sep 2017 16:40:29 +0000 (UTC)","from orsmga005.jf.intel.com ([10.7.209.41])\n\tby orsmga104.jf.intel.com with ESMTP; 10 Sep 2017 09:40:29 -0700","from irsmsx106.ger.corp.intel.com ([163.33.3.31])\n\tby orsmga005.jf.intel.com with ESMTP; 10 Sep 2017 09:40:11 -0700","from irsmsx102.ger.corp.intel.com ([169.254.2.59]) by\n\tIRSMSX106.ger.corp.intel.com ([169.254.8.36]) with mapi id\n\t14.03.0319.002; Sun, 10 Sep 2017 17:40:10 +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=\"147587085\"","From":"\"Chandran, Sugesh\" ","To":"Yuanhan Liu , \"dev@openvswitch.org\"\n\t","Thread-Topic":"[ovs-dev] [PATCH v2 5/8] dpif-netdev: record rx queue id for\n\tthe\tupcall","Thread-Index":"AQHTJilEB7Uh5Hv5GkatX2W2Q9Ym+aKuJM7Q","Date":"Sun, 10 Sep 2017 16:40:10 +0000","Message-ID":"<2EF2F5C0CC56984AA024D0B180335FCB4221DC55@IRSMSX102.ger.corp.intel.com>","References":"<1504603381-30071-1-git-send-email-yliu@fridaylinux.org>\n\t<1504603381-30071-6-git-send-email-yliu@fridaylinux.org>","In-Reply-To":"<1504603381-30071-6-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":"eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYjFhZWJkMzItNGNjYi00OTczLWJmZjctZWY5MDUwZmJmYzU4IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6IlZFVXFXOCs3aW1nT25RXC9cL3BERHhnNGE3bDJ3eUduRmRkQngwTlBqRGxnRT0ifQ==","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=-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","Subject":"Re: [ovs-dev] [PATCH v2 5/8] dpif-netdev: record rx queue id for\n\tthe\tupcall","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":1766128,"web_url":"http://patchwork.ozlabs.org/comment/1766128/","msgid":"<20170911083234.GU9736@yliu-home>","list_archive_url":null,"date":"2017-09-11T08:32:35","subject":"Re: [ovs-dev] [PATCH v2 5/8] dpif-netdev: record rx queue id for\n\tthe upcall","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:40:10PM +0000, Chandran, Sugesh wrote:\n> \n> \n> Regards\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 5/8] dpif-netdev: record rx queue id for the\n> > upcall\n> > \n> > From: Shachar Beiser \n> > \n> > For the DPDK flow offload, which basically just binds a MARK action to a flow,\n> > the MARK is required to be used together with a QUEUE action for the most\n> > NICs I'm aware of. The QUEUE action then needs a queue index, which is not\n> > given in the flow content.\n> [Sugesh] Looks to me this is again another hardware specific req.\n> This could have impact on RSS hash distribution and queue redistribution across pmds\n> at runtime.\n\nIf you have read my earlier version, you should have seen similar concerns\nfrom me.\n\n[...]\n> > handle_packet_upcall(struct dp_netdev_pmd_thread *pmd,\n> > struct dp_packet *packet,\n> > const struct netdev_flow_key *key,\n> > struct ofpbuf *actions, struct ofpbuf *put_actions,\n> > - int *lost_cnt, long long now)\n> > + int *lost_cnt, long long now, int rxq)\n> [Sugesh] IMHO its not really good practice to change the default packet processing path for\n> some specific hardware offload. Rxq doesn't have any meaning for handling the packets in normal path.\n\nThe same: some concerns I have already expressed before. Unfortunately,\nwe didn't come up with something better.\n\n> Why cant install flow on all the configured queues for a specific inport? Flow handling is per port, not per queue.\n> This will assure the packets will have mark even after the rss hash distribution. \n\nLike how? The QUEUE action only accepts one queue index. Setting it to\nmany times will only let the last one take effect. The another possiblity\nI'm aware of is with the RTE_FLOW_ACTION_TYPE_RSS, which, unfortunately,\nis only supported by Mellanox in DPDK. Yet again, I was told it's not\nfunctional well.\n\nAlso, even it could work, I think it still would be probematic. I'm\nthinking what might happen for following case.\n\nAssume there is a 5-tuple flow. According to the initial RSS setting by\nOVS, all pkts match that flow would be ended up being recieved from one\nqueue only. If we re-do RSS settings on it, if the RSS settings are the\nsame, the behaviour might be the same. If not, those pkts which are\nsupposed to be distributed to one queue only might be distributed to\nmany queues.\n\nIs it a valid concern?\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=\"1NJaveAy\"; 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 3xrLlh5zjpz9s83\n\tfor ;\n\tMon, 11 Sep 2017 18:32:48 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id 83391AF3;\n\tMon, 11 Sep 2017 08:32:45 +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 654129F0\n\tfor ; Mon, 11 Sep 2017 08:32:44 +0000 (UTC)","from mail-pf0-f182.google.com (mail-pf0-f182.google.com\n\t[209.85.192.182])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id D52F318F\n\tfor ; Mon, 11 Sep 2017 08:32:43 +0000 (UTC)","by mail-pf0-f182.google.com with SMTP id e1so13031410pfk.1\n\tfor ; Mon, 11 Sep 2017 01:32:43 -0700 (PDT)","from yliu-home ([45.63.61.64]) by smtp.gmail.com with ESMTPSA id\n\tm21sm2278247pgn.60.2017.09.11.01.32.40\n\t(version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);\n\tMon, 11 Sep 2017 01:32:42 -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=G9pMVDMntnyR8KtzeiJ3fJDW38cwWz0PmIX1jdHq20I=;\n\tb=1NJaveAyU46nMbMMVbftQgdNwJ6p9kgntA6KqnleKCiYu3G7VUQf5Z2qcT+hQkiLfZ\n\tpp0pNHIIScPwIeM+hMcwCHrG3cpzjHXvUpgcQe6B7xnx6+WDj159z2vG+TQJfb3pUoNw\n\t5C7HJ9MMkXKU4+D8c6WWJmoHAoRRlXx8d/VnaX+jzuThzu/G9fFtqOnmi1D1p+x91Rh+\n\tUIqyEidcTKPdqNdGw1zPp+n2Es51ns7WuZmtVngt99IwrLSfXsbR8NK/MZCuEoZMfnj2\n\t+Ujryaw8jkyx5m0U7YaURyjY1ta2oAAISREQdAfwFGbjmipn5NUMdY2HZbGiQbgGEGEV\n\topTA==","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=G9pMVDMntnyR8KtzeiJ3fJDW38cwWz0PmIX1jdHq20I=;\n\tb=AsUh50gYfv7Tz1YyRLyiGdhpEFaOK8ZGjB8157sTHIwuKTqn26brnQseJT4FobV5pa\n\tgMiYRdsi9w3Q4UKYs//KNwGsLnVwcIPn1Zo4Ew5JFHvAzT8btk7Avcn6kGfDhxrcnefx\n\tGniB/1VgEeEG3Ap1nHP+PE4/kCMXjAKkLR8zfUplxGz2JU6LEc+HTRtRjZoZv5glpqba\n\tCXa/LW5vOSezAIokn+W9GUmOQZAUh1NQe5iAii+mJqJ/7mZ/oZyZT7Lm06P/VPGSR/Ga\n\tnEpgjx2j8vjhgqYHS/BQmFBcBsEW2aotdggwl9a5RJxzxYmyMZ0++jw4JjYASR9Eht88\n\tXMDQ==","X-Gm-Message-State":"AHPjjUgX2k2kiWdoaWsunLfnLHqv15EKD+1Ba9aZg/seZG2RS1pRoaeS\n\t456EPz7TOPZfFUltliif/A==","X-Google-Smtp-Source":"ADKCNb5IZl7IveGAF4cdkOCDwnzfwM45wH40u/gT7F0WdTNAu4tHqjKzlrpoino5f0+BvRkGP81OZg==","X-Received":"by 10.84.133.193 with SMTP id f59mr13192757plf.224.1505118763484;\n\tMon, 11 Sep 2017 01:32:43 -0700 (PDT)","Date":"Mon, 11 Sep 2017 16:32:35 +0800","From":"Yuanhan Liu ","To":"\"Chandran, Sugesh\" ","Message-ID":"<20170911083234.GU9736@yliu-home>","References":"<1504603381-30071-1-git-send-email-yliu@fridaylinux.org>\n\t<1504603381-30071-6-git-send-email-yliu@fridaylinux.org>\n\t<2EF2F5C0CC56984AA024D0B180335FCB4221DC55@IRSMSX102.ger.corp.intel.com>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<2EF2F5C0CC56984AA024D0B180335FCB4221DC55@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 5/8] dpif-netdev: record rx queue id for\n\tthe upcall","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":1766183,"web_url":"http://patchwork.ozlabs.org/comment/1766183/","msgid":"<2EF2F5C0CC56984AA024D0B180335FCB4221E068@IRSMSX102.ger.corp.intel.com>","list_archive_url":null,"date":"2017-09-11T09:49:52","subject":"Re: [ovs-dev] [PATCH v2 5/8] dpif-netdev: record rx queue id for\n\tthe upcall","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 9:33 AM\n> To: Chandran, Sugesh \n> Cc: dev@openvswitch.org\n> Subject: Re: [ovs-dev] [PATCH v2 5/8] dpif-netdev: record rx queue id for the\n> upcall\n> \n> On Sun, Sep 10, 2017 at 04:40:10PM +0000, Chandran, Sugesh wrote:\n> >\n> >\n> > Regards\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 5/8] dpif-netdev: record rx queue id\n> > > for the upcall\n> > >\n> > > From: Shachar Beiser \n> > >\n> > > For the DPDK flow offload, which basically just binds a MARK action\n> > > to a flow, the MARK is required to be used together with a QUEUE\n> > > action for the most NICs I'm aware of. The QUEUE action then needs a\n> > > queue index, which is not given in the flow content.\n> > [Sugesh] Looks to me this is again another hardware specific req.\n> > This could have impact on RSS hash distribution and queue\n> > redistribution across pmds at runtime.\n> \n> If you have read my earlier version, you should have seen similar concerns\n> from me.\n[Sugesh] I feel this has to be addressed properly to make this feature work on all the cases.\n\n> \n> [...]\n> > > handle_packet_upcall(struct dp_netdev_pmd_thread *pmd,\n> > > struct dp_packet *packet,\n> > > const struct netdev_flow_key *key,\n> > > struct ofpbuf *actions, struct ofpbuf *put_actions,\n> > > - int *lost_cnt, long long now)\n> > > + int *lost_cnt, long long now, int rxq)\n> > [Sugesh] IMHO its not really good practice to change the default\n> > packet processing path for some specific hardware offload. Rxq doesn't\n> have any meaning for handling the packets in normal path.\n> \n> The same: some concerns I have already expressed before. Unfortunately,\n> we didn't come up with something better.\n> \n> > Why cant install flow on all the configured queues for a specific inport?\n> Flow handling is per port, not per queue.\n> > This will assure the packets will have mark even after the rss hash\n> distribution.\n> \n> Like how? The QUEUE action only accepts one queue index. Setting it to\n> many times will only let the last one take effect. The another possiblity I'm\n> aware of is with the RTE_FLOW_ACTION_TYPE_RSS, which, unfortunately, is\n> only supported by Mellanox in DPDK. Yet again, I was told it's not functional\n> well.\n[Sugesh] Hmm. I got it what you meant. Flow director has an option called\npassthrough. This will allow to use RSS hash on packet after the filter.\nIf I remember correctly this has been in supported in XL710 all the time.\nThis will allow to program the flow without any queue index. If there is a\nfunctionality issue to configure the MARK action properly, it has to be fixed in\nDPDK than doing a workaround in OVS. \n> \n> Also, even it could work, I think it still would be probematic. I'm thinking what\n> might happen for following case.\n> \n> Assume there is a 5-tuple flow. According to the initial RSS setting by OVS, all\n> pkts match that flow would be ended up being recieved from one queue\n> only. If we re-do RSS settings on it, if the RSS settings are the same, the\n> behaviour might be the same. If not, those pkts which are supposed to be\n[Sugesh] When a user changes number of queues, RSS setting might change.\nAlso in the current design, when a queue get pinned to different PMD at run time, \nThe mark details may loose as its on the PMD struct.\n> distributed to one queue only might be distributed to many queues.\n> \n> Is it a valid concern?\n[Sugesh] I feel there will be performance and scalability issues if we wanted to program\na flow for a queue ID. Hence I prefer to have flow programming without queue specific information.\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 3xrNSl14Bpz9s7G\n\tfor ;\n\tMon, 11 Sep 2017 19:49:58 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id 117EAB7C;\n\tMon, 11 Sep 2017 09:49:57 +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 669CCB76\n\tfor ; Mon, 11 Sep 2017 09:49:55 +0000 (UTC)","from mga07.intel.com (mga07.intel.com [134.134.136.100])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id D05DDA4\n\tfor ; Mon, 11 Sep 2017 09:49:54 +0000 (UTC)","from orsmga004.jf.intel.com ([10.7.209.38])\n\tby orsmga105.jf.intel.com with ESMTP; 11 Sep 2017 02:49:54 -0700","from irsmsx151.ger.corp.intel.com ([163.33.192.59])\n\tby orsmga004.jf.intel.com with ESMTP; 11 Sep 2017 02:49:53 -0700","from irsmsx102.ger.corp.intel.com ([169.254.2.59]) by\n\tIRSMSX151.ger.corp.intel.com ([169.254.4.108]) with mapi id\n\t14.03.0319.002; Mon, 11 Sep 2017 10:49:52 +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=\"127527173\"","From":"\"Chandran, Sugesh\" ","To":"Yuanhan Liu ","Thread-Topic":"[ovs-dev] [PATCH v2 5/8] dpif-netdev: record rx queue id for\n\tthe upcall","Thread-Index":"AQHTKtiYYGFlrjoO6kyLvPYZTXLAdaKvZAmw","Date":"Mon, 11 Sep 2017 09:49:52 +0000","Message-ID":"<2EF2F5C0CC56984AA024D0B180335FCB4221E068@IRSMSX102.ger.corp.intel.com>","References":"<1504603381-30071-1-git-send-email-yliu@fridaylinux.org>\n\t<1504603381-30071-6-git-send-email-yliu@fridaylinux.org>\n\t<2EF2F5C0CC56984AA024D0B180335FCB4221DC55@IRSMSX102.ger.corp.intel.com>\n\t<20170911083234.GU9736@yliu-home>","In-Reply-To":"<20170911083234.GU9736@yliu-home>","Accept-Language":"en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","x-titus-metadata-40":"eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMTJhZWE5NTgtMDczMS00MmZhLWJkZGYtYjQ5OTI0MTgzOTJmIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6IjJKVUdONXY5ekJkVWpZUmNLeXNvcnk2VWtuZWpqaUYwUjlNcXZ4UEdYYnM9In0=","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 5/8] dpif-netdev: record rx queue id for\n\tthe upcall","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":1766198,"web_url":"http://patchwork.ozlabs.org/comment/1766198/","msgid":"<20170911101203.GA9736@yliu-home>","list_archive_url":null,"date":"2017-09-11T10:12:03","subject":"Re: [ovs-dev] [PATCH v2 5/8] dpif-netdev: record rx queue id for\n\tthe upcall","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 09:49:52AM +0000, Chandran, Sugesh wrote:\n> > > > For the DPDK flow offload, which basically just binds a MARK action\n> > > > to a flow, the MARK is required to be used together with a QUEUE\n> > > > action for the most NICs I'm aware of. The QUEUE action then needs a\n> > > > queue index, which is not given in the flow content.\n> > > [Sugesh] Looks to me this is again another hardware specific req.\n> > > This could have impact on RSS hash distribution and queue\n> > > redistribution across pmds at runtime.\n> > \n> > If you have read my earlier version, you should have seen similar concerns\n> > from me.\n> [Sugesh] I feel this has to be addressed properly to make this feature work on all the cases.\n\nAgreed.\n\n> > > > handle_packet_upcall(struct dp_netdev_pmd_thread *pmd,\n> > > > struct dp_packet *packet,\n> > > > const struct netdev_flow_key *key,\n> > > > struct ofpbuf *actions, struct ofpbuf *put_actions,\n> > > > - int *lost_cnt, long long now)\n> > > > + int *lost_cnt, long long now, int rxq)\n> > > [Sugesh] IMHO its not really good practice to change the default\n> > > packet processing path for some specific hardware offload. Rxq doesn't\n> > have any meaning for handling the packets in normal path.\n> > \n> > The same: some concerns I have already expressed before. Unfortunately,\n> > we didn't come up with something better.\n> > \n> > > Why cant install flow on all the configured queues for a specific inport?\n> > Flow handling is per port, not per queue.\n> > > This will assure the packets will have mark even after the rss hash\n> > distribution.\n> > \n> > Like how? The QUEUE action only accepts one queue index. Setting it to\n> > many times will only let the last one take effect. The another possiblity I'm\n> > aware of is with the RTE_FLOW_ACTION_TYPE_RSS, which, unfortunately, is\n> > only supported by Mellanox in DPDK. Yet again, I was told it's not functional\n> > well.\n> [Sugesh] Hmm. I got it what you meant. Flow director has an option called\n> passthrough. This will allow to use RSS hash on packet after the filter.\n> If I remember correctly this has been in supported in XL710 all the time.\n> This will allow to program the flow without any queue index.\n\nGood to know. However, if you git grep it, you will see that only i40e\nand tap have this support.\n\n> If there is a\n> functionality issue to configure the MARK action properly, it has to be fixed in\n> DPDK than doing a workaround in OVS. \n\nAgain, can't agree more on this. But the truth/fact is that it's not an\neasy task to fix DPDK. For Mellanox, I don't know exactly how many parts\nneed to be fixed (something like DPDK PMD, libibvers, kernel, etc). For\nothers, it might just be a hardware limitation.\n\nIt's even harder (if not impossible) to fix most (if not all) DPDK pmds\nhas rte flow support.\n\nEven if we could do that, it may take years to finish that. At least, \nI see no related tasks from DPDK v17.11.\n\n> > Also, even it could work, I think it still would be probematic. I'm thinking what\n> > might happen for following case.\n> > \n> > Assume there is a 5-tuple flow. According to the initial RSS setting by OVS, all\n> > pkts match that flow would be ended up being recieved from one queue\n> > only. If we re-do RSS settings on it, if the RSS settings are the same, the\n> > behaviour might be the same. If not, those pkts which are supposed to be\n> [Sugesh] When a user changes number of queues, RSS setting might change.\n> Also in the current design, when a queue get pinned to different PMD at run time, \n> The mark details may loose as its on the PMD struct.\n> > distributed to one queue only might be distributed to many queues.\n> > \n> > Is it a valid concern?\n> [Sugesh] I feel there will be performance and scalability issues if we wanted to program\n> a flow for a queue ID. Hence I prefer to have flow programming without queue specific information.\n\nTrue me, I also really want to get rid of the queue action, just if we have\ngood options.\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=\"QXvDKndJ\"; 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 3xrNyd63d8z9sBd\n\tfor ;\n\tMon, 11 Sep 2017 20:12:25 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id EFBCCBC6;\n\tMon, 11 Sep 2017 10:12: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 36949A64\n\tfor ; Mon, 11 Sep 2017 10:12:21 +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 518E0D3\n\tfor ; Mon, 11 Sep 2017 10:12:20 +0000 (UTC)","by mail-pg0-f51.google.com with SMTP id v66so14443477pgb.5\n\tfor ; Mon, 11 Sep 2017 03:12:20 -0700 (PDT)","from yliu-home ([45.63.61.64]) by smtp.gmail.com with ESMTPSA id\n\tx189sm14701993pfx.188.2017.09.11.03.12.16\n\t(version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);\n\tMon, 11 Sep 2017 03:12:18 -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=3ME+j9ju6KXvpoLEx3UMKOUREORBp88MSetpXn6S7pc=;\n\tb=QXvDKndJv+Lc1HqpPRmJ2bpwKheoIdyx5ZfmeR/mvslw9q0lKviZU14dbJc/ejuB6X\n\tcXllzq35Mv939sqGJ4cbRoIddmU9e4zujol5piWHbcJc0YotZ+ypLkNuYst/THXaMwXE\n\tw0fvxhcj3HJYy7iRA0ZpBqAvSeY/Mp/UDrOtY8P3P6uGQNG3atUdXZWsL8bqbksruBo9\n\tCOfWyJTgM1vFvRdXa9iT6E4uPRW0ZQfLtA0WvRowCqvbM8XyFmkIgk+k31+Hh1ePVk7/\n\tRTaBCZbrE61I5WCZp1ahnWmy5EbVvHSB3eMJHYQSNC6PGqtKcUuVcJjOJRSGZbPkr7tw\n\ttn6Q==","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=3ME+j9ju6KXvpoLEx3UMKOUREORBp88MSetpXn6S7pc=;\n\tb=hIhXWmEdtKCPZAw7bE652R4riW5y56q8Qq3M5hUig2rPaOXlHLEOCO3wTmq0tVBCNp\n\tM6xevxmXHyJb2umdQQulwlh2jlZRUZESu6JaVLc60eB1a4GHF7mbDdGy/gD660ZURnZU\n\tQxDsaenJaQ9u14iZG8JNT5++YPsF6gIs+4fvNwoSIorQaEQ5e1Hdkw6kFndRgfy8pf8f\n\t1kymvuS2FIH9xl2yLET0WnWdoAmhr1gceBR86rYsPGJXp2dEWz9k5TkAirMROJQVjpK5\n\tHZgyXPRqUpX8qaWCChdQMqRPCFNi5PjloqIqgFHNxko+BK/DxkpbM5whB2bYl5qlknyH\n\tIMSw==","X-Gm-Message-State":"AHPjjUhYQvMovSQvGg25MZ09LhH18hYgHykXpT+UeSENOe0ObvmaDTtZ\n\tr6cKh+wX/RSubhaZiQOuPA==","X-Google-Smtp-Source":"ADKCNb6wvKIdwUpm+FuWleyxWf9HjHF/+dg6j5SDjabnLl02Nvea/Yfc3uwj/oJZVfbUzeXFDKEo1Q==","X-Received":"by 10.84.210.67 with SMTP id z61mr12933991plh.125.1505124739933; \n\tMon, 11 Sep 2017 03:12:19 -0700 (PDT)","Date":"Mon, 11 Sep 2017 18:12:03 +0800","From":"Yuanhan Liu ","To":"\"Chandran, Sugesh\" ","Message-ID":"<20170911101203.GA9736@yliu-home>","References":"<1504603381-30071-1-git-send-email-yliu@fridaylinux.org>\n\t<1504603381-30071-6-git-send-email-yliu@fridaylinux.org>\n\t<2EF2F5C0CC56984AA024D0B180335FCB4221DC55@IRSMSX102.ger.corp.intel.com>\n\t<20170911083234.GU9736@yliu-home>\n\t<2EF2F5C0CC56984AA024D0B180335FCB4221E068@IRSMSX102.ger.corp.intel.com>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<2EF2F5C0CC56984AA024D0B180335FCB4221E068@IRSMSX102.ger.corp.intel.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 5/8] dpif-netdev: record rx queue id for\n\tthe upcall","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":1766293,"web_url":"http://patchwork.ozlabs.org/comment/1766293/","msgid":"<2EF2F5C0CC56984AA024D0B180335FCB4221F242@IRSMSX102.ger.corp.intel.com>","list_archive_url":null,"date":"2017-09-11T12:57:44","subject":"Re: [ovs-dev] [PATCH v2 5/8] dpif-netdev: record rx queue id for\n\tthe upcall","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:12 AM\n> To: Chandran, Sugesh \n> Cc: dev@openvswitch.org\n> Subject: Re: [ovs-dev] [PATCH v2 5/8] dpif-netdev: record rx queue id for the\n> upcall\n> \n> On Mon, Sep 11, 2017 at 09:49:52AM +0000, Chandran, Sugesh wrote:\n> > > > > For the DPDK flow offload, which basically just binds a MARK\n> > > > > action to a flow, the MARK is required to be used together with\n> > > > > a QUEUE action for the most NICs I'm aware of. The QUEUE action\n> > > > > then needs a queue index, which is not given in the flow content.\n> > > > [Sugesh] Looks to me this is again another hardware specific req.\n> > > > This could have impact on RSS hash distribution and queue\n> > > > redistribution across pmds at runtime.\n> > >\n> > > If you have read my earlier version, you should have seen similar\n> > > concerns from me.\n> > [Sugesh] I feel this has to be addressed properly to make this feature work\n> on all the cases.\n> \n> Agreed.\n> \n> > > > > handle_packet_upcall(struct dp_netdev_pmd_thread *pmd,\n> > > > > struct dp_packet *packet,\n> > > > > const struct netdev_flow_key *key,\n> > > > > struct ofpbuf *actions, struct ofpbuf *put_actions,\n> > > > > - int *lost_cnt, long long now)\n> > > > > + int *lost_cnt, long long now, int rxq)\n> > > > [Sugesh] IMHO its not really good practice to change the default\n> > > > packet processing path for some specific hardware offload. Rxq\n> > > > doesn't\n> > > have any meaning for handling the packets in normal path.\n> > >\n> > > The same: some concerns I have already expressed before.\n> > > Unfortunately, we didn't come up with something better.\n> > >\n> > > > Why cant install flow on all the configured queues for a specific inport?\n> > > Flow handling is per port, not per queue.\n> > > > This will assure the packets will have mark even after the rss\n> > > > hash\n> > > distribution.\n> > >\n> > > Like how? The QUEUE action only accepts one queue index. Setting it\n> > > to many times will only let the last one take effect. The another\n> > > possiblity I'm aware of is with the RTE_FLOW_ACTION_TYPE_RSS, which,\n> > > unfortunately, is only supported by Mellanox in DPDK. Yet again, I\n> > > was told it's not functional well.\n> > [Sugesh] Hmm. I got it what you meant. Flow director has an option called\n> > passthrough. This will allow to use RSS hash on packet after the filter.\n> > If I remember correctly this has been in supported in XL710 all the time.\n> > This will allow to program the flow without any queue index.\n> \n> Good to know. However, if you git grep it, you will see that only i40e and tap\n> have this support.\n[Sugesh] Yes, you are right. \n> \n> > If there is a\n> > functionality issue to configure the MARK action properly, it has to\n> > be fixed in DPDK than doing a workaround in OVS.\n> \n> Again, can't agree more on this. But the truth/fact is that it's not an easy task\n> to fix DPDK. For Mellanox, I don't know exactly how many parts need to be\n> fixed (something like DPDK PMD, libibvers, kernel, etc). For others, it might\n> just be a hardware limitation.\n> \n> It's even harder (if not impossible) to fix most (if not all) DPDK pmds has rte\n> flow support.\n> \n> Even if we could do that, it may take years to finish that. At least, I see no\n> related tasks from DPDK v17.11.\n[Sugesh] Ok. IMO making changes in DPDK is cleaner and avoid lot of extra\nwork in OVS\n> \n> > > Also, even it could work, I think it still would be probematic. I'm\n> > > thinking what might happen for following case.\n> > >\n> > > Assume there is a 5-tuple flow. According to the initial RSS setting\n> > > by OVS, all pkts match that flow would be ended up being recieved\n> > > from one queue only. If we re-do RSS settings on it, if the RSS\n> > > settings are the same, the behaviour might be the same. If not,\n> > > those pkts which are supposed to be\n> > [Sugesh] When a user changes number of queues, RSS setting might\n> change.\n> > Also in the current design, when a queue get pinned to different PMD\n> > at run time, The mark details may loose as its on the PMD struct.\n> > > distributed to one queue only might be distributed to many queues.\n> > >\n> > > Is it a valid concern?\n> > [Sugesh] I feel there will be performance and scalability issues if we\n> > wanted to program a flow for a queue ID. Hence I prefer to have flow\n> programming without queue specific information.\n> \n> True me, I also really want to get rid of the queue action, just if we have good\n> options.\n\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 3xrSdY6RsCz9s7B\n\tfor ;\n\tMon, 11 Sep 2017 22:57:52 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id 897A9A84;\n\tMon, 11 Sep 2017 12:57:49 +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 682FC2C\n\tfor ; Mon, 11 Sep 2017 12:57:48 +0000 (UTC)","from mga09.intel.com (mga09.intel.com [134.134.136.24])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id CF31612A\n\tfor ; Mon, 11 Sep 2017 12:57:47 +0000 (UTC)","from fmsmga003.fm.intel.com ([10.253.24.29])\n\tby orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t11 Sep 2017 05:57:47 -0700","from irsmsx153.ger.corp.intel.com ([163.33.192.75])\n\tby FMSMGA003.fm.intel.com with ESMTP; 11 Sep 2017 05:57:46 -0700","from irsmsx102.ger.corp.intel.com ([169.254.2.59]) by\n\tIRSMSX153.ger.corp.intel.com ([169.254.9.34]) with mapi id\n\t14.03.0319.002; Mon, 11 Sep 2017 13:57:45 +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=\"899100703\"","From":"\"Chandran, Sugesh\" ","To":"Yuanhan Liu ","Thread-Topic":"[ovs-dev] [PATCH v2 5/8] dpif-netdev: record rx queue id for\n\tthe upcall","Thread-Index":"AQHTKtiYYGFlrjoO6kyLvPYZTXLAdaKvZAmwgAACVYCAAD448A==","Date":"Mon, 11 Sep 2017 12:57:44 +0000","Message-ID":"<2EF2F5C0CC56984AA024D0B180335FCB4221F242@IRSMSX102.ger.corp.intel.com>","References":"<1504603381-30071-1-git-send-email-yliu@fridaylinux.org>\n\t<1504603381-30071-6-git-send-email-yliu@fridaylinux.org>\n\t<2EF2F5C0CC56984AA024D0B180335FCB4221DC55@IRSMSX102.ger.corp.intel.com>\n\t<20170911083234.GU9736@yliu-home>\n\t<2EF2F5C0CC56984AA024D0B180335FCB4221E068@IRSMSX102.ger.corp.intel.com>\n\t<20170911101203.GA9736@yliu-home>","In-Reply-To":"<20170911101203.GA9736@yliu-home>","Accept-Language":"en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","x-titus-metadata-40":"eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNDg5ODNjYzItYjRiZi00NmZjLTlhMDItMGMwODg0OWFhN2ZlIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6IlJqeXQ1VGExNmtSRGlJNjV1VVVZZm5melYxek5hTUZmUzhtWjJ5QndnOWs9In0=","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 5/8] dpif-netdev: record rx queue id for\n\tthe upcall","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":1767520,"web_url":"http://patchwork.ozlabs.org/comment/1767520/","msgid":"<67AC6E04-1A63-492C-A7D2-667D02A3376E@vmware.com>","list_archive_url":null,"date":"2017-09-13T03:04:05","subject":"Re: [ovs-dev] [PATCH v2 5/8] dpif-netdev: record rx queue id for\n\tthe upcall","submitter":{"id":68212,"url":"http://patchwork.ozlabs.org/api/people/68212/","name":"Darrell Ball","email":"dball@vmware.com"},"content":"On 9/11/17, 5:58 AM, \"ovs-dev-bounces@openvswitch.org on behalf of Chandran, Sugesh\" wrote:\n\n \n \n Regards\n _Sugesh\n \n \n > -----Original Message-----\n > From: Yuanhan Liu [mailto:yliu@fridaylinux.org]\n > Sent: Monday, September 11, 2017 11:12 AM\n > To: Chandran, Sugesh \n > Cc: dev@openvswitch.org\n > Subject: Re: [ovs-dev] [PATCH v2 5/8] dpif-netdev: record rx queue id for the\n > upcall\n > \n > On Mon, Sep 11, 2017 at 09:49:52AM +0000, Chandran, Sugesh wrote:\n > > > > > For the DPDK flow offload, which basically just binds a MARK\n > > > > > action to a flow, the MARK is required to be used together with\n > > > > > a QUEUE action for the most NICs I'm aware of. The QUEUE action\n > > > > > then needs a queue index, which is not given in the flow content.\n > > > > [Sugesh] Looks to me this is again another hardware specific req.\n > > > > This could have impact on RSS hash distribution and queue\n > > > > redistribution across pmds at runtime.\n > > >\n > > > If you have read my earlier version, you should have seen similar\n > > > concerns from me.\n > > [Sugesh] I feel this has to be addressed properly to make this feature work\n > on all the cases.\n > \n > Agreed.\n > \n > > > > > handle_packet_upcall(struct dp_netdev_pmd_thread *pmd,\n > > > > > struct dp_packet *packet,\n > > > > > const struct netdev_flow_key *key,\n > > > > > struct ofpbuf *actions, struct ofpbuf *put_actions,\n > > > > > - int *lost_cnt, long long now)\n > > > > > + int *lost_cnt, long long now, int rxq)\n > > > > [Sugesh] IMHO its not really good practice to change the default\n > > > > packet processing path for some specific hardware offload. Rxq\n > > > > doesn't\n > > > have any meaning for handling the packets in normal path.\n > > >\n > > > The same: some concerns I have already expressed before.\n > > > Unfortunately, we didn't come up with something better.\n > > >\n > > > > Why cant install flow on all the configured queues for a specific inport?\n > > > Flow handling is per port, not per queue.\n > > > > This will assure the packets will have mark even after the rss\n > > > > hash\n > > > distribution.\n > > >\n > > > Like how? The QUEUE action only accepts one queue index. Setting it\n > > > to many times will only let the last one take effect. The another\n > > > possiblity I'm aware of is with the RTE_FLOW_ACTION_TYPE_RSS, which,\n > > > unfortunately, is only supported by Mellanox in DPDK. Yet again, I\n > > > was told it's not functional well.\n > > [Sugesh] Hmm. I got it what you meant. Flow director has an option called\n > > passthrough. This will allow to use RSS hash on packet after the filter.\n > > If I remember correctly this has been in supported in XL710 all the time.\n > > This will allow to program the flow without any queue index.\n > \n > Good to know. However, if you git grep it, you will see that only i40e and tap\n > have this support.\n [Sugesh] Yes, you are right. \n > \n > > If there is a\n > > functionality issue to configure the MARK action properly, it has to\n > > be fixed in DPDK than doing a workaround in OVS.\n > \n > Again, can't agree more on this. But the truth/fact is that it's not an easy task\n > to fix DPDK. For Mellanox, I don't know exactly how many parts need to be\n > fixed (something like DPDK PMD, libibvers, kernel, etc). For others, it might\n > just be a hardware limitation.\n > \n > It's even harder (if not impossible) to fix most (if not all) DPDK pmds has rte\n > flow support.\n > \n > Even if we could do that, it may take years to finish that. At least, I see no\n > related tasks from DPDK v17.11.\n [Sugesh] Ok. IMO making changes in DPDK is cleaner and avoid lot of extra\n work in OVS\n\n[Darrell] The queue action workaround (for Intel and Mellanox nics) has been discussed\nextensively in the first version of the patchset and the last 2 dpdk public meetings.\nNobody likes it.\nThere are some other mitigating options discussed already.\n\nI am not sure it is feasible to wait for the underlying support to come, assuming it does.\nHowever, some requests for enhancements could be made in parallel.\n\n\n > \n > > > Also, even it could work, I think it still would be probematic. I'm\n > > > thinking what might happen for following case.\n > > >\n > > > Assume there is a 5-tuple flow. According to the initial RSS setting\n > > > by OVS, all pkts match that flow would be ended up being recieved\n > > > from one queue only. If we re-do RSS settings on it, if the RSS\n > > > settings are the same, the behaviour might be the same. If not,\n > > > those pkts which are supposed to be\n > > [Sugesh] When a user changes number of queues, RSS setting might\n > change.\n > > Also in the current design, when a queue get pinned to different PMD\n > > at run time, The mark details may loose as its on the PMD struct.\n > > > distributed to one queue only might be distributed to many queues.\n > > >\n > > > Is it a valid concern?\n > > [Sugesh] I feel there will be performance and scalability issues if we\n > > wanted to program a flow for a queue ID. Hence I prefer to have flow\n > programming without queue specific information.\n > \n > True me, I also really want to get rid of the queue action, just if we have good\n > options.\n \n > \n > \t--yliu\n _______________________________________________\n dev mailing list\n dev@openvswitch.org\n https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=gCgqKWT7TG8YtKH-bHF0kxNELaOVnFKHw1Sib8s65fA&s=3wZntu-3h8pDivrsLzclYWqjCu4KaDztj2taArziDTc&e=","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=\"Kb1orPZw\"; \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 3xsRMf57Mvz9t39\n\tfor ;\n\tWed, 13 Sep 2017 13:04:13 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id 5D0B48F5;\n\tWed, 13 Sep 2017 03:04:09 +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 98A69516\n\tfor ; Wed, 13 Sep 2017 03:04:08 +0000 (UTC)","from NAM02-CY1-obe.outbound.protection.outlook.com\n\t(mail-cys01nam02on0051.outbound.protection.outlook.com\n\t[104.47.37.51])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id B8BF01CE\n\tfor ; Wed, 13 Sep 2017 03:04:07 +0000 (UTC)","from BLUPR05MB611.namprd05.prod.outlook.com (10.141.204.27) by\n\tBLUPR05MB372.namprd05.prod.outlook.com (10.141.25.154) with Microsoft\n\tSMTP 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 03:04:05 +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 03:04:05 +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=fgiqdJHidHRIaQCvdGLPLW1xWlpCQN5GQ0DDcCSZ58g=;\n\tb=Kb1orPZwNPVCfz1yae7qxIBPKLu62pb85KA6WV2ZW4z2b18ERK6i8tHA5CRzuAWuilclUjlbCcCLnEOL5OAKphFZU4+n7KNYmNKf4sanZ5968OGCSv0Ma0+dN1otNi9ufodTkZM+pBO/M7P7/UxnHKy7rhOBh72oPAy5jPBPsi4=","From":"Darrell Ball ","To":"\"Chandran, Sugesh\" , Yuanhan Liu\n\t","Thread-Topic":"[ovs-dev] [PATCH v2 5/8] dpif-netdev: record rx queue id for\n\tthe upcall","Thread-Index":"AQHTKtiWdG9TnVZoHEKov5V56tLpZ6KvcO8AgAAGM4CAAC5LAIACCXOA","Date":"Wed, 13 Sep 2017 03:04:05 +0000","Message-ID":"<67AC6E04-1A63-492C-A7D2-667D02A3376E@vmware.com>","References":"<1504603381-30071-1-git-send-email-yliu@fridaylinux.org>\n\t<1504603381-30071-6-git-send-email-yliu@fridaylinux.org>\n\t<2EF2F5C0CC56984AA024D0B180335FCB4221DC55@IRSMSX102.ger.corp.intel.com>\n\t<20170911083234.GU9736@yliu-home>\n\t<2EF2F5C0CC56984AA024D0B180335FCB4221E068@IRSMSX102.ger.corp.intel.com>\n\t<20170911101203.GA9736@yliu-home>\n\t<2EF2F5C0CC56984AA024D0B180335FCB4221F242@IRSMSX102.ger.corp.intel.com>","In-Reply-To":"<2EF2F5C0CC56984AA024D0B180335FCB4221F242@IRSMSX102.ger.corp.intel.com>","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=\"Kb1orPZw\"; \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; BLUPR05MB372;\n\t20:0Flk8LBPIn9WXXsmJtalETvMXqAi4Ei3wXYXNPQqHQqmIeHZlTo47oymsl4KjD02evJNvKC5OQuoj6/ZBuqhX0/586iHxACUKh2osiBuEhAG0zlZerXvOW6Uem/P6LjD8Ov9GuYoRixlSK+LKJHECdcozrQPBhkJayWTWB5NOSA=","x-ms-exchange-antispam-srfa-diagnostics":"SSOS;","x-ms-office365-filtering-correlation-id":"19e2f71e-f9b1-49e2-4354-08d4fa541852","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:BLUPR05MB372; ","x-ms-traffictypediagnostic":"BLUPR05MB372:","x-exchange-antispam-report-test":"UriScan:(10436049006162)(216315784871565)(228905959029699); ","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)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123560025)(20161123564025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);\n\tSRVR:BLUPR05MB372; BCL:0; PCL:0;\n\tRULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);\n\tSRVR:BLUPR05MB372; ","x-forefront-prvs":"042957ACD7","x-forefront-antispam-report":"SFV:NSPM;\n\tSFS:(10009020)(6009001)(39860400002)(376002)(346002)(366002)(377454003)(189002)(13464003)(24454002)(199003)(53546010)(54356999)(50986999)(76176999)(97736004)(2950100002)(6486002)(77096006)(229853002)(966005)(478600001)(68736007)(82746002)(4001350100001)(6506006)(316002)(6436002)(83716003)(83506001)(5660300001)(86362001)(575784001)(66066001)(2906002)(101416001)(36756003)(8936002)(3660700001)(3280700002)(189998001)(93886005)(14454004)(7736002)(2900100001)(6512007)(33656002)(25786009)(81156014)(81166006)(4326008)(8676002)(53936002)(105586002)(305945005)(99286003)(6306002)(6246003)(6116002)(102836003)(106356001)(3846002);\n\tDIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB372;\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 03:04:05.5823\n\t(UTC)","X-MS-Exchange-CrossTenant-fromentityheader":"Hosted","X-MS-Exchange-CrossTenant-id":"b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0","X-MS-Exchange-Transport-CrossTenantHeadersStamped":"BLUPR05MB372","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 5/8] dpif-netdev: record rx queue id for\n\tthe upcall","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":1768957,"web_url":"http://patchwork.ozlabs.org/comment/1768957/","msgid":"<20170915062417.GG2050@yliu-home>","list_archive_url":null,"date":"2017-09-15T06:24:17","subject":"Re: [ovs-dev] [PATCH v2 5/8] dpif-netdev: record rx queue id for\n\tthe upcall","submitter":{"id":72215,"url":"http://patchwork.ozlabs.org/api/people/72215/","name":"Yuanhan Liu","email":"yliu@fridaylinux.org"},"content":"On Wed, Sep 13, 2017 at 03:04:05AM +0000, Darrell Ball wrote:\n> [Sugesh] Yes, you are right. \n> > \n> > > If there is a\n> > > functionality issue to configure the MARK action properly, it has to\n> > > be fixed in DPDK than doing a workaround in OVS.\n> > \n> > Again, can't agree more on this. But the truth/fact is that it's not an easy task\n> > to fix DPDK. For Mellanox, I don't know exactly how many parts need to be\n> > fixed (something like DPDK PMD, libibvers, kernel, etc). For others, it might\n> > just be a hardware limitation.\n> > \n> > It's even harder (if not impossible) to fix most (if not all) DPDK pmds has rte\n> > flow support.\n> > \n> > Even if we could do that, it may take years to finish that. At least, I see no\n> > related tasks from DPDK v17.11.\n> [Sugesh] Ok. IMO making changes in DPDK is cleaner and avoid lot of extra\n> work in OVS\n> \n> [Darrell] The queue action workaround (for Intel and Mellanox nics) has been discussed\n> extensively in the first version of the patchset and the last 2 dpdk public meetings.\n> Nobody likes it.\n> There are some other mitigating options discussed already.\n> \n> I am not sure it is feasible to wait for the underlying support to come, assuming it does.\n> However, some requests for enhancements could be made in parallel.\n\nAgreed, I think that's the best we could get so far.\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=\"SPzMOXJA\"; 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 3xtljr2Bv9z9ryQ\n\tfor ;\n\tFri, 15 Sep 2017 16:24:31 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id 6420E8FF;\n\tFri, 15 Sep 2017 06:24:27 +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 03B8882\n\tfor ; Fri, 15 Sep 2017 06:24:26 +0000 (UTC)","from mail-pf0-f172.google.com (mail-pf0-f172.google.com\n\t[209.85.192.172])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id 90B477C\n\tfor ; Fri, 15 Sep 2017 06:24:25 +0000 (UTC)","by mail-pf0-f172.google.com with SMTP id n24so958015pfk.5\n\tfor ; Thu, 14 Sep 2017 23:24:25 -0700 (PDT)","from yliu-home ([45.63.61.64]) by smtp.gmail.com with ESMTPSA id\n\ts76sm568058pfj.119.2017.09.14.23.24.22\n\t(version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);\n\tThu, 14 Sep 2017 23:24:23 -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=Yjpz5a1JP7o+SD5f+lIjKza/2VfCT+kf+r9mXBoHA18=;\n\tb=SPzMOXJA4Up9bukkaGJAnMIL3PwHLKF1H4rK5I9EfakFp3Z3ty3Syetlg0G4cCgUP/\n\tFVRQ+mGahBkFOcIVZVVrn3ZcwyQE9RKQzadd2EbzUq/lX+A3fKVWQI94ZBhL56n/nbQR\n\txAg7xXLvVdqImHX1FecZpkciP/U/d/rWg2/3p16gftdyo4qc91J3o+vFN8YdT+v/dlU7\n\tOX+j5deNAY2UR3WwTaI/D5hgXb6ELWD1aQStgKqjctrkHHI45Nc/mKQDHop0H0sZ2tO+\n\tbYcJ+HIVZXb1nZf0UEt5lQnubza9gphUsu9Z86HtcQJrxqyN65Zvd/WDkedwi1L452+/\n\t629A==","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=Yjpz5a1JP7o+SD5f+lIjKza/2VfCT+kf+r9mXBoHA18=;\n\tb=q4h62/E1Hf8LD5Z9J+GiCEDT+H13aRjOlVC94QFsEh9Ck/KBKLSt6wlDqIsXWDMvRM\n\tyeVJkpYvgG0x8NpVTuiF6uuaisBm2nzoYQUJaS1VwRKAfRwwleOWsJNcUHdI9FjbRiIU\n\tH+nI5gXsBEYcSmXJ9UKN5BVKvaVCwhN+5XVJWWD5807nwhpZZiN7CNpvYHOljX14gjCw\n\t45deePNK700LFMpGSeRZvHXsqWuahGxGjIel4JgD2cbll4ScfqxAlC+WqToPrKCPARth\n\ttGNH+Ird9FXG73q+i6mzxJTxSpD8oKdgrczxZg8kWOUIrYqwTG+cOSB/aeX9UWAQeBCq\n\tS9YA==","X-Gm-Message-State":"AHPjjUjQQKBYalW9qAxflVDqS58M1ReRDG36FrbRp4Q3I/KRwewdyxYl\n\tTnkr+0i5VPGQHCtyRqUTpQ==","X-Google-Smtp-Source":"ADKCNb7acNneBQ5kyVidM1i63XhItVojhWHOsEofW9FofLCqNlVwDyRB/qI+iIOCI8rKec/LMD+7Jg==","X-Received":"by 10.98.252.216 with SMTP id\n\te207mr23566930pfh.306.1505456665147; \n\tThu, 14 Sep 2017 23:24:25 -0700 (PDT)","Date":"Fri, 15 Sep 2017 14:24:17 +0800","From":"Yuanhan Liu ","To":"Darrell Ball ","Message-ID":"<20170915062417.GG2050@yliu-home>","References":"<1504603381-30071-1-git-send-email-yliu@fridaylinux.org>\n\t<1504603381-30071-6-git-send-email-yliu@fridaylinux.org>\n\t<2EF2F5C0CC56984AA024D0B180335FCB4221DC55@IRSMSX102.ger.corp.intel.com>\n\t<20170911083234.GU9736@yliu-home>\n\t<2EF2F5C0CC56984AA024D0B180335FCB4221E068@IRSMSX102.ger.corp.intel.com>\n\t<20170911101203.GA9736@yliu-home>\n\t<2EF2F5C0CC56984AA024D0B180335FCB4221F242@IRSMSX102.ger.corp.intel.com>\n\t<67AC6E04-1A63-492C-A7D2-667D02A3376E@vmware.com>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<67AC6E04-1A63-492C-A7D2-667D02A3376E@vmware.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 5/8] dpif-netdev: record rx queue id for\n\tthe upcall","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"}}]