[{"id":1760011,"web_url":"http://patchwork.ozlabs.org/comment/1760011/","msgid":"<87wp5l7560.fsf@stressinduktion.org>","list_archive_url":null,"date":"2017-08-30T09:53:27","subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","submitter":{"id":18284,"url":"http://patchwork.ozlabs.org/api/people/18284/","name":"Hannes Frederic Sowa","email":"hannes@stressinduktion.org"},"content":"Hello,\n\nYi Yang writes:\n\n[...]\n\n> +struct ovs_key_nsh {\n> +\tu8 flags;\n> +\tu8 ttl;\n> +\tu8 mdtype;\n> +\tu8 np;\n> +\t__be32 path_hdr;\n> +\t__be32 context[NSH_MD1_CONTEXT_SIZE];\n> +};\n> +\n> struct sw_flow_key {\n> \tu8 tun_opts[IP_TUNNEL_OPTS_MAX];\n> \tu8 tun_opts_len;\n> @@ -144,6 +154,7 @@ struct sw_flow_key {\n> \t\t\t};\n> \t\t} ipv6;\n> \t};\n> +\tstruct ovs_key_nsh nsh; /* network service header */\n> \tstruct {\n> \t\t/* Connection tracking fields not packed above. */\n> \t\tstruct {\n\nDoes it makes sense to keep the context headers as part of the flow?\nWhat is the reasoning behind it? With mdtype 2 headers this might either\nnot work very well or will increase sw_flow_key size causing slowdowns\nfor all protocols.\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=stressinduktion.org\n\theader.i=@stressinduktion.org header.b=\"kSDxels4\"; \n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=messagingengine.com\n\theader.i=@messagingengine.com header.b=\"qMv0Ts+N\"; \n\tdkim-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 3xj1Jr5rxxz9t0F\n\tfor ;\n\tWed, 30 Aug 2017 20:02:36 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id 230259E8;\n\tWed, 30 Aug 2017 10:02:34 +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 1A056955\n\tfor ; Wed, 30 Aug 2017 10:02:33 +0000 (UTC)","from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com\n\t[66.111.4.26])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4E76FB0\n\tfor ; Wed, 30 Aug 2017 10:02:32 +0000 (UTC)","from compute7.internal (compute7.nyi.internal [10.202.2.47])\n\tby mailout.nyi.internal (Postfix) with ESMTP id 92A6C21B4E;\n\tWed, 30 Aug 2017 05:53:30 -0400 (EDT)","from frontend2 ([10.202.2.161])\n\tby compute7.internal (MEProxy); Wed, 30 Aug 2017 05:53:30 -0400","from z.localhost.stressinduktion.org (unknown [217.192.177.51])\n\tby mail.messagingengine.com (Postfix) with ESMTPA id 471EF248E6;\n\tWed, 30 Aug 2017 05:53:29 -0400 (EDT)"],"X-Greylist":"delayed 00:09:01 by SQLgrey-1.7.6","DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed; d=\n\tstressinduktion.org; h=cc:content-type:date:from:in-reply-to\n\t:message-id:mime-version:references:subject:to:x-me-sender\n\t:x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=YReBdnhaB00Sw6XB/V\n\t+r4x6C7XsSyTWxi7qYjYRyQnA=; b=kSDxels4YEyivt7ywP1kkOr+eLdhJsUkpy\n\t2p4qlmcv1IvUeJdIlelqnWFr1FXuudVMm7nLEkqGyPM652zAx5EV3jyi6NHV9CVN\n\t5hmYmDNZSMRL7JdBowvX6QC9yZtUH/gpKJhkxKb/IQQmSC3uo0jZShJOgFMzYMNC\n\trC1Zku+JAUAh7BOA0wXzFw5tj80XAMPw4FqeNKyiLER7czYRwA01KR8Wvyl3PVx9\n\tUnOhmkd6sJikuiiBtjDtKWU4LYnlObx+7hfezBl2jDIXe3MoEirnVvDpbCafdVw3\n\tImX1YAs6V7YstOsjgjSE66EPkg+3OgSSrH40rsOhzKFXXJng8Krg==","v=1; a=rsa-sha256; c=relaxed/relaxed; d=\n\tmessagingengine.com; h=cc:content-type:date:from:in-reply-to\n\t:message-id:mime-version:references:subject:to:x-me-sender\n\t:x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=YReBdnhaB00Sw6XB/V\n\t+r4x6C7XsSyTWxi7qYjYRyQnA=; b=qMv0Ts+NGVl8qG9V2rQWwOkIhR2+pbMIuf\n\te6fmSdJliAas+vO2Dayl88h8imDUwv2q67BWdL/ZsvK/WUs/R/AuBH22g8kN1ijD\n\t+q7iPrqkbHIGlvr30cy6+iRfjyS+TbWmPkF/rRFb+zkg2GtdzcvQouQUQSc5MBY2\n\tjiO84JyoUEzPuA/1QBge1x6epROQV4dquuFvoXFOXeNyK3WB3oX108srWNG3Ig77\n\tcvZwatMjpA4VKxZz7kg3vslAPsOfNCeHDv44KVFXBahMHpitV3+LQREKeSjCcmY5\n\tCQVE/FHX6XofT6Yiti9o/4CGJy4E2Cti2X7WmaRP95UAzlsZAJQw=="],"X-ME-Sender":"","X-Sasl-enc":"Z/YTFcJtyCwHT5C2ey8S402USizOiVWcRxJky9K1FU0Y 1504086810","From":"Hannes Frederic Sowa ","To":"Yi Yang ","References":"<1503670805-31051-1-git-send-email-yi.y.yang@intel.com>\n\t<1503670805-31051-4-git-send-email-yi.y.yang@intel.com>","Date":"Wed, 30 Aug 2017 11:53:27 +0200","In-Reply-To":"<1503670805-31051-4-git-send-email-yi.y.yang@intel.com> (Yi\n\tYang's message of \"Fri, 25 Aug 2017 22:20:05 +0800\")","Message-ID":"<87wp5l7560.fsf@stressinduktion.org>","User-Agent":"Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)","MIME-Version":"1.0","X-Spam-Status":"No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,\n\tDKIM_VALID_AU,RCVD_IN_DNSWL_LOW 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, netdev@vger.kernel.org, jbenc@redhat.com, e@erig.me","Subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","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":1760080,"web_url":"http://patchwork.ozlabs.org/comment/1760080/","msgid":"<4B1BB321037C0849AAE171801564DFA6888FAED3@IRSMSX107.ger.corp.intel.com>","list_archive_url":null,"date":"2017-08-30T11:36:17","subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable\n\tNSH\tsupport","submitter":{"id":68763,"url":"http://patchwork.ozlabs.org/api/people/68763/","name":"Mooney, Sean K","email":"sean.k.mooney@intel.com"},"content":"> -----Original Message-----\n> From: ovs-dev-bounces@openvswitch.org [mailto:ovs-dev-\n> bounces@openvswitch.org] On Behalf Of Hannes Frederic Sowa\n> Sent: Wednesday, August 30, 2017 10:53 AM\n> To: Yang, Yi Y \n> Cc: dev@openvswitch.org; netdev@vger.kernel.org; jbenc@redhat.com;\n> e@erig.me\n> Subject: Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n> support\n> \n> Hello,\n> \n> Yi Yang writes:\n> \n> [...]\n> \n> > +struct ovs_key_nsh {\n> > +\tu8 flags;\n> > +\tu8 ttl;\n> > +\tu8 mdtype;\n> > +\tu8 np;\n> > +\t__be32 path_hdr;\n> > +\t__be32 context[NSH_MD1_CONTEXT_SIZE]; };\n> > +\n> > struct sw_flow_key {\n> > \tu8 tun_opts[IP_TUNNEL_OPTS_MAX];\n> > \tu8 tun_opts_len;\n> > @@ -144,6 +154,7 @@ struct sw_flow_key {\n> > \t\t\t};\n> > \t\t} ipv6;\n> > \t};\n> > +\tstruct ovs_key_nsh nsh; /* network service header */\n> > \tstruct {\n> > \t\t/* Connection tracking fields not packed above. */\n> > \t\tstruct {\n> \n> Does it makes sense to keep the context headers as part of the flow?\n> What is the reasoning behind it? With mdtype 2 headers this might\n> either not work very well or will increase sw_flow_key size causing\n> slowdowns for all protocols.\n[Mooney, Sean K] \nHaving the nsh context headers in the flow is quite useful\nIt would allow loadblancing on values stored in the context headers\nOr other use. I belive odl previously used context header 4 to store a\nFlow id so this could potentialy be used with the multipath action to have ovs\nChoose between several possible next hops in the chain.\n\nAnother example of where this is usefull is branching chains.\nif I assume that both the classifier and\nService function forwarder are collocated in ovs on the host, and is send\nA packet to a firewall service function which tags the packet as suspicious\nVia setting a context header metadata field to 1, I as the sdn controller can\nInstall a high priority rule that will reclassify the packet as part of as separate\nService function chain the will prefer dpi on the packet before returning it to\nThe original chain if demand not a threat.\n\nSo while a sff dose not in general have to be able to match on the context header\nIf I assume I want to use ovs to implenet a classifier or service function(e.g. loadblancer)\nThe its desirable to be able to both match on the context headers in md type1 and also be able\nTo set them(this is something classifies and service fuction are allowed to do).\n> \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 3xj3P846ZNz9sQl\n\tfor ;\n\tWed, 30 Aug 2017 21:36:27 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id 4D500901;\n\tWed, 30 Aug 2017 11:36:23 +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 742D6900\n\tfor ; Wed, 30 Aug 2017 11:36:21 +0000 (UTC)","from mga09.intel.com (mga09.intel.com [134.134.136.24])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id E9684134\n\tfor ; Wed, 30 Aug 2017 11:36:20 +0000 (UTC)","from orsmga003.jf.intel.com ([10.7.209.27])\n\tby orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t30 Aug 2017 04:36:20 -0700","from irsmsx105.ger.corp.intel.com ([163.33.3.28])\n\tby orsmga003.jf.intel.com with ESMTP; 30 Aug 2017 04:36:18 -0700","from irsmsx107.ger.corp.intel.com ([169.254.10.65]) by\n\tirsmsx105.ger.corp.intel.com ([169.254.7.75]) with mapi id\n\t14.03.0319.002; Wed, 30 Aug 2017 12:36:18 +0100"],"X-Greylist":"domain auto-whitelisted by SQLgrey-1.7.6","X-ExtLoop1":"1","X-IronPort-AV":"E=Sophos; i=\"5.41,448,1498546800\"; d=\"scan'208\";\n\ta=\"1009229143\"","From":"\"Mooney, Sean K\" ","To":"Hannes Frederic Sowa , \"Yang, Yi Y\"\n\t","Thread-Topic":"[ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","Thread-Index":"AQHTIXcmYjgp5aXlqkqoAsc+wGy2SqKcvW9Q","Date":"Wed, 30 Aug 2017 11:36:17 +0000","Message-ID":"<4B1BB321037C0849AAE171801564DFA6888FAED3@IRSMSX107.ger.corp.intel.com>","References":"<1503670805-31051-1-git-send-email-yi.y.yang@intel.com>\n\t<1503670805-31051-4-git-send-email-yi.y.yang@intel.com>\n\t<87wp5l7560.fsf@stressinduktion.org>","In-Reply-To":"<87wp5l7560.fsf@stressinduktion.org>","Accept-Language":"en-IE, en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","x-titus-metadata-40":"eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZDFmODk0MGMtOWFmMi00MTA4LWI4MjgtMjkwOGViY2Q3ODg0IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6IkFYSDYzbUE0a1QxMHBOYTBZOWdMY0lrbE1HNFluYkVyWmorMURsc0VZT289In0=","x-ctpclassification":"CTP_IC","x-originating-ip":"[163.33.239.182]","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\" ,\n\t\"netdev@vger.kernel.org\" ,\n\t\"e@erig.me\" , \"jbenc@redhat.com\" ","Subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable\n\tNSH\tsupport","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":1760273,"web_url":"http://patchwork.ozlabs.org/comment/1760273/","msgid":"<87inh56q8u.fsf@stressinduktion.org>","list_archive_url":null,"date":"2017-08-30T15:15:45","subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","submitter":{"id":18284,"url":"http://patchwork.ozlabs.org/api/people/18284/","name":"Hannes Frederic Sowa","email":"hannes@stressinduktion.org"},"content":"\"Mooney, Sean K\" writes:\n\n>> -----Original Message-----\n>> From: ovs-dev-bounces@openvswitch.org [mailto:ovs-dev-\n>> bounces@openvswitch.org] On Behalf Of Hannes Frederic Sowa\n>> Sent: Wednesday, August 30, 2017 10:53 AM\n>> To: Yang, Yi Y \n>> Cc: dev@openvswitch.org; netdev@vger.kernel.org; jbenc@redhat.com;\n>> e@erig.me\n>> Subject: Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n>> support\n>> \n>> Hello,\n>> \n>> Yi Yang writes:\n>> \n>> [...]\n>> \n>> > +struct ovs_key_nsh {\n>> > +\tu8 flags;\n>> > +\tu8 ttl;\n>> > +\tu8 mdtype;\n>> > +\tu8 np;\n>> > +\t__be32 path_hdr;\n>> > +\t__be32 context[NSH_MD1_CONTEXT_SIZE]; };\n>> > +\n>> > struct sw_flow_key {\n>> > \tu8 tun_opts[IP_TUNNEL_OPTS_MAX];\n>> > \tu8 tun_opts_len;\n>> > @@ -144,6 +154,7 @@ struct sw_flow_key {\n>> > \t\t\t};\n>> > \t\t} ipv6;\n>> > \t};\n>> > +\tstruct ovs_key_nsh nsh; /* network service header */\n>> > \tstruct {\n>> > \t\t/* Connection tracking fields not packed above. */\n>> > \t\tstruct {\n>> \n>> Does it makes sense to keep the context headers as part of the flow?\n>> What is the reasoning behind it? With mdtype 2 headers this might\n>> either not work very well or will increase sw_flow_key size causing\n>> slowdowns for all protocols.\n> [Mooney, Sean K]\n> Having the nsh context headers in the flow is quite useful It would\n> allow loadblancing on values stored in the context headers Or other\n> use. I belive odl previously used context header 4 to store a Flow id\n> so this could potentialy be used with the multipath action to have ovs\n> Choose between several possible next hops in the chain.\n\nIn OVS, masks are a list(!) for matching. How can this work for\ndifferent paths that might require different masks? If they can't be\nunified you even get exact matches. Thus, for OVS the context should not\nbe part of the flow.\n\n> Another example of where this is usefull is branching chains. if I\n> assume that both the classifier and Service function forwarder are\n> collocated in ovs on the host, and is send A packet to a firewall\n> service function which tags the packet as suspicious Via setting a\n> context header metadata field to 1, I as the sdn controller can\n> Install a high priority rule that will reclassify the packet as part\n> of as separate Service function chain the will prefer dpi on the\n> packet before returning it to The original chain if demand not a\n> threat.\n\nYou can do that with different path id's, too?\n\n> So while a sff dose not in general have to be able to match on the\n> context header If I assume I want to use ovs to implenet a classifier\n> or service function(e.g. loadblancer) The its desirable to be able to\n> both match on the context headers in md type1 and also be able To set\n> them(this is something classifies and service fuction are allowed to\n> do).\n\nI don't think it is practical at all?","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=stressinduktion.org\n\theader.i=@stressinduktion.org header.b=\"lEnORrYa\"; \n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=messagingengine.com\n\theader.i=@messagingengine.com header.b=\"HprsJaoo\"; \n\tdkim-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 3xj8GL384hz9sN7\n\tfor ;\n\tThu, 31 Aug 2017 01:15:53 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id C25D3B16;\n\tWed, 30 Aug 2017 15:15:51 +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 16B02B10\n\tfor ; Wed, 30 Aug 2017 15:15:51 +0000 (UTC)","from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com\n\t[66.111.4.28])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id 04FC63F5\n\tfor ; Wed, 30 Aug 2017 15:15:49 +0000 (UTC)","from compute7.internal (compute7.nyi.internal [10.202.2.47])\n\tby mailout.nyi.internal (Postfix) with ESMTP id 03BE720A96;\n\tWed, 30 Aug 2017 11:15:49 -0400 (EDT)","from frontend1 ([10.202.2.160])\n\tby compute7.internal (MEProxy); Wed, 30 Aug 2017 11:15:49 -0400","from z.localhost.stressinduktion.org (unknown [217.192.177.51])\n\tby mail.messagingengine.com (Postfix) with ESMTPA id 567407F9BC;\n\tWed, 30 Aug 2017 11:15:47 -0400 (EDT)"],"X-Greylist":"from auto-whitelisted by SQLgrey-1.7.6","DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed; d=\n\tstressinduktion.org; h=cc:content-type:date:from:in-reply-to\n\t:message-id:mime-version:references:subject:to:x-me-sender\n\t:x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=XWQhasp7XgfxvQJeaq\n\t8WYgTTYixk/BpI+YU7+EnDR8M=; b=lEnORrYaSAe72yiQ7E8vIqkGQxbxFH8dzj\n\t2SzUgMbnRTau8H4b2Q7Gpf5d/YdJFMROduLbiOOtRce2mMvBEab/b7AXUShI2vUM\n\tKfa6raMV28lCvv0aBDpamLGHTUlNntrn1QSWZrMb4YuJ78W4ZaxkEmKKOXMe43fN\n\tnPHFiXPpszL/XIS0VpIdr0AgrMuYOuswGh/wQiYh8kj+5zk9GBhqjcrtrlIi4tbK\n\t8pMm+pf9p2z5gfc8NDv49H/Mw2KgrpxssTgk4sq+jvPiCnewId/htyNkCZ63JOEw\n\tGglxLMf3da2GJUL2Mu1HMslwQjtBDkOVPe+nVFDTE+KMMwqIJc0Q==","v=1; a=rsa-sha256; c=relaxed/relaxed; d=\n\tmessagingengine.com; h=cc:content-type:date:from:in-reply-to\n\t:message-id:mime-version:references:subject:to:x-me-sender\n\t:x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=XWQhasp7XgfxvQJeaq\n\t8WYgTTYixk/BpI+YU7+EnDR8M=; b=HprsJaoonYOnVBnvrVzupyzwgTVP0z9f2b\n\tqQwc5+jprLKyuvlMx95nHPC+8uRvZxxSanzN+eAa+QuhQj3dhDQuBa49hzHIsgIg\n\tShJpB7gHB9e3F52wgwSMeBTp7AmCnpfg10gYu5H3bKnLBX8IGk2mkUp4WDuQ5b2r\n\tk/8i5Ka8LwdcNsGfVLUuNnOEfWvDpMUF+bvLk+ZJSPYbaBbRFQvn9QAhTIhVrIsi\n\t1Q4CHYXETDYmsHA+8tgZTnUHNq9iwpd1k0hkliaaKw90Rrn2n3X1e7+IyqBMtItC\n\tepyHLYsHnNwo6kZBVd7IUSnvB9UyHBV9t8ZIHz1KI+/gRU9DVYiQ=="],"X-ME-Sender":"","X-Sasl-enc":"3zt2KRcG3ASiaEkBwETutQBhNvF6xF2thAKCNQXZxuOb 1504106148","From":"Hannes Frederic Sowa ","To":"\"Mooney\\, Sean K\" ","References":"<1503670805-31051-1-git-send-email-yi.y.yang@intel.com>\n\t<1503670805-31051-4-git-send-email-yi.y.yang@intel.com>\n\t<87wp5l7560.fsf@stressinduktion.org>\n\t<4B1BB321037C0849AAE171801564DFA6888FAED3@IRSMSX107.ger.corp.intel.com>","Date":"Wed, 30 Aug 2017 17:15:45 +0200","In-Reply-To":"<4B1BB321037C0849AAE171801564DFA6888FAED3@IRSMSX107.ger.corp.intel.com>\n\t(Sean K. Mooney's message of \"Wed, 30 Aug 2017 11:36:17 +0000\")","Message-ID":"<87inh56q8u.fsf@stressinduktion.org>","User-Agent":"Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)","MIME-Version":"1.0","X-Spam-Status":"No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,\n\tDKIM_VALID_AU,RCVD_IN_DNSWL_LOW 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\" , \"e@erig.me\" ,\n\t\"jbenc@redhat.com\" ,\n\t\"netdev@vger.kernel.org\" ","Subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","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":1760411,"web_url":"http://patchwork.ozlabs.org/comment/1760411/","msgid":"<4B1BB321037C0849AAE171801564DFA6888FB254@IRSMSX107.ger.corp.intel.com>","list_archive_url":null,"date":"2017-08-30T19:00:44","subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","submitter":{"id":68763,"url":"http://patchwork.ozlabs.org/api/people/68763/","name":"Mooney, Sean K","email":"sean.k.mooney@intel.com"},"content":"> -----Original Message-----\n> From: Hannes Frederic Sowa [mailto:hannes@stressinduktion.org]\n> Sent: Wednesday, August 30, 2017 4:16 PM\n> To: Mooney, Sean K \n> Cc: Yang, Yi Y ; dev@openvswitch.org;\n> netdev@vger.kernel.org; jbenc@redhat.com; e@erig.me\n> Subject: Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n> support\n> \n> \"Mooney, Sean K\" writes:\n> \n> >> -----Original Message-----\n> >> From: ovs-dev-bounces@openvswitch.org [mailto:ovs-dev-\n> >> bounces@openvswitch.org] On Behalf Of Hannes Frederic Sowa\n> >> Sent: Wednesday, August 30, 2017 10:53 AM\n> >> To: Yang, Yi Y \n> >> Cc: dev@openvswitch.org; netdev@vger.kernel.org; jbenc@redhat.com;\n> >> e@erig.me\n> >> Subject: Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable\n> >> NSH support\n> >>\n> >> Hello,\n> >>\n> >> Yi Yang writes:\n> >>\n> >> [...]\n> >>\n> >> > +struct ovs_key_nsh {\n> >> > +\tu8 flags;\n> >> > +\tu8 ttl;\n> >> > +\tu8 mdtype;\n> >> > +\tu8 np;\n> >> > +\t__be32 path_hdr;\n> >> > +\t__be32 context[NSH_MD1_CONTEXT_SIZE]; };\n> >> > +\n> >> > struct sw_flow_key {\n> >> > \tu8 tun_opts[IP_TUNNEL_OPTS_MAX];\n> >> > \tu8 tun_opts_len;\n> >> > @@ -144,6 +154,7 @@ struct sw_flow_key {\n> >> > \t\t\t};\n> >> > \t\t} ipv6;\n> >> > \t};\n> >> > +\tstruct ovs_key_nsh nsh; /* network service header */\n> >> > \tstruct {\n> >> > \t\t/* Connection tracking fields not packed above. */\n> >> > \t\tstruct {\n> >>\n> >> Does it makes sense to keep the context headers as part of the flow?\n> >> What is the reasoning behind it? With mdtype 2 headers this might\n> >> either not work very well or will increase sw_flow_key size causing\n> >> slowdowns for all protocols.\n> > [Mooney, Sean K]\n> > Having the nsh context headers in the flow is quite useful It would\n> > allow loadblancing on values stored in the context headers Or other\n> > use. I belive odl previously used context header 4 to store a Flow id\n> > so this could potentialy be used with the multipath action to have\n> ovs\n> > Choose between several possible next hops in the chain.\n> \n> In OVS, masks are a list(!) for matching. How can this work for\n> different paths that might require different masks? If they can't be\n> unified you even get exact matches. Thus, for OVS the context should\n> not be part of the flow.\n[Mooney, Sean K] I'm not sure what you mean about a list as I never made reference to one.\nmd type 1 context headers are 4 mandatory 32 bit field.\nform an ovs context they should be treated the same as the 32 bit register fields.\nWe do not need to necessarily support those in md type 2 as all metadata is optional.\n> \n> > Another example of where this is usefull is branching chains. if I\n> > assume that both the classifier and Service function forwarder are\n> > collocated in ovs on the host, and is send A packet to a firewall\n> > service function which tags the packet as suspicious Via setting a\n> > context header metadata field to 1, I as the sdn controller can\n> > Install a high priority rule that will reclassify the packet as part\n> > of as separate Service function chain the will prefer dpi on the\n> > packet before returning it to The original chain if demand not a\n> > threat.\n> \n> You can do that with different path id's, too?\n[Mooney, Sean K] a service function is not allowed to alter the spi.\nOnly a classifier can do that. You are correct that a different spi is required for the branch\nTo the dpi sf but packets that are not droped can rejoin the original spi.\nPacket are not require you to enter a service chain at the first hop.\n\nservice function chain are explicitly not A list. They are a directed graph composed\nof service function instance or service function groups that generally \nare reducible to a directed acrylic graph and in the simple case to a simple list. \nbranching an recovering chains are expected, as is loadblancing between \nservice function instances in the same service function group which share the same spi. \nThe spi filed in the nsh heard is intended to transport the logical service plane path id\nnot the rendered service path id.\n> \n> > So while a sff dose not in general have to be able to match on the\n> > context header If I assume I want to use ovs to implenet a classifier\n> > or service function(e.g. loadblancer) The its desirable to be able to\n> > both match on the context headers in md type1 and also be able To set\n> > them(this is something classifies and service fuction are allowed to\n> > do).\n> \n> I don't think it is practical at all?\n[Mooney, Sean K] To day in OpenStack we co-locate the clarifier at every\nOvs instance and use mpls as a standing for nsh doing proxing at every hop before sending\nTo an sf. Flow based load balancing is not only practical but has been demonstrated to work with odl gbp classifier\nand sfc application controlling a patched ovs with nsh support in 2015. \n\nIf you look at slide 36 of http://events.linuxfoundation.org/sites/events/files/slides/odl%20summit%20sfc%20v5.pdf\nyou will see that prior to the berilium release of odl context header 1 and 2 are used to allow multi-tenancy\nand overlapping ips. For the loadblancing implentaiton I belived they also used context header 4 to store a flow id.\nThis require odl to generate openflow rules to set the context headers as part of classification.\n\nYou can also see that context header 1 and 2 are still used in the newer odl netvirt sfc classifier implementation\nhttps://github.com/opendaylight/netvirt/blob/ba22f7cf19d8a827d77a3391a7f654344ade43d8/docs/specs/new-sfc-classifier.rst#pipeline-changes\nso for odl existing nsh support to work with md type one we must have the ability to set the nsh context headers\nand should have the ability to match on them also for load lancing between service function in service function group.","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 3xjFFx3d8tz9sN5\n\tfor ;\n\tThu, 31 Aug 2017 05:00:52 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id A75E9C10;\n\tWed, 30 Aug 2017 19:00: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 B7F72BBF\n\tfor ; Wed, 30 Aug 2017 19:00:48 +0000 (UTC)","from mga04.intel.com (mga04.intel.com [192.55.52.120])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id 10B7C79\n\tfor ; Wed, 30 Aug 2017 19:00:47 +0000 (UTC)","from orsmga005.jf.intel.com ([10.7.209.41])\n\tby fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t30 Aug 2017 12:00:47 -0700","from irsmsx151.ger.corp.intel.com ([163.33.192.59])\n\tby orsmga005.jf.intel.com with ESMTP; 30 Aug 2017 12:00:46 -0700","from irsmsx155.ger.corp.intel.com (163.33.192.3) by\n\tIRSMSX151.ger.corp.intel.com (163.33.192.59) with Microsoft SMTP\n\tServer (TLS) id 14.3.319.2; Wed, 30 Aug 2017 20:00:45 +0100","from irsmsx107.ger.corp.intel.com ([169.254.10.65]) by\n\tirsmsx155.ger.corp.intel.com ([169.254.14.70]) with mapi id\n\t14.03.0319.002; Wed, 30 Aug 2017 20:00:44 +0100"],"X-Greylist":"domain auto-whitelisted by SQLgrey-1.7.6","X-ExtLoop1":"1","X-IronPort-AV":"E=Sophos;i=\"5.41,449,1498546800\"; d=\"scan'208\";a=\"143808195\"","From":"\"Mooney, Sean K\" ","To":"Hannes Frederic Sowa ","Thread-Topic":"[ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","Thread-Index":"AQHTIaLp7ynLp9NFwU+49cBe0yKcXqKdCwLg","Date":"Wed, 30 Aug 2017 19:00:44 +0000","Message-ID":"<4B1BB321037C0849AAE171801564DFA6888FB254@IRSMSX107.ger.corp.intel.com>","References":"<1503670805-31051-1-git-send-email-yi.y.yang@intel.com>\n\t<1503670805-31051-4-git-send-email-yi.y.yang@intel.com>\n\t<87wp5l7560.fsf@stressinduktion.org>\n\t<4B1BB321037C0849AAE171801564DFA6888FAED3@IRSMSX107.ger.corp.intel.com>\n\t<87inh56q8u.fsf@stressinduktion.org>","In-Reply-To":"<87inh56q8u.fsf@stressinduktion.org>","Accept-Language":"en-IE, en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","x-titus-metadata-40":"eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMjhkNTc5MGEtOThiYS00YjY4LWJiMGMtN2Y2NDU1OTkyMTE1IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6IitHMThFTVwva21xWlJKelpcL2ZFUUwyNEV5ZzMyOGM4TDRjVm1EYlNDNHlpZz0ifQ==","x-ctpclassification":"CTP_IC","x-originating-ip":"[163.33.239.182]","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\" ,\n\t\"jbenc@redhat.com\" , \"e@erig.me\" ,\n\t\"netdev@vger.kernel.org\" ","Subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","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":1760932,"web_url":"http://patchwork.ozlabs.org/comment/1760932/","msgid":"<87d17boqb1.fsf@stressinduktion.org>","list_archive_url":null,"date":"2017-08-31T12:49:22","subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","submitter":{"id":18284,"url":"http://patchwork.ozlabs.org/api/people/18284/","name":"Hannes Frederic Sowa","email":"hannes@stressinduktion.org"},"content":"Hello,\n\n\"Mooney, Sean K\" writes:\n\n\n[...]\n\n>> >> > +struct ovs_key_nsh {\n>> >> > +\tu8 flags;\n>> >> > +\tu8 ttl;\n>> >> > +\tu8 mdtype;\n>> >> > +\tu8 np;\n>> >> > +\t__be32 path_hdr;\n>> >> > +\t__be32 context[NSH_MD1_CONTEXT_SIZE]; };\n>> >> > +\n>> >> > struct sw_flow_key {\n>> >> > \tu8 tun_opts[IP_TUNNEL_OPTS_MAX];\n>> >> > \tu8 tun_opts_len;\n>> >> > @@ -144,6 +154,7 @@ struct sw_flow_key {\n>> >> > \t\t\t};\n>> >> > \t\t} ipv6;\n>> >> > \t};\n>> >> > +\tstruct ovs_key_nsh nsh; /* network service header */\n>> >> > \tstruct {\n>> >> > \t\t/* Connection tracking fields not packed above. */\n>> >> > \t\tstruct {\n>> >>\n>> >> Does it makes sense to keep the context headers as part of the flow?\n>> >> What is the reasoning behind it? With mdtype 2 headers this might\n>> >> either not work very well or will increase sw_flow_key size causing\n>> >> slowdowns for all protocols.\n>> > [Mooney, Sean K]\n>> > Having the nsh context headers in the flow is quite useful It would\n>> > allow loadblancing on values stored in the context headers Or other\n>> > use. I belive odl previously used context header 4 to store a Flow id\n>> > so this could potentialy be used with the multipath action to have\n>> ovs\n>> > Choose between several possible next hops in the chain.\n>> \n>> In OVS, masks are a list(!) for matching. How can this work for\n>> different paths that might require different masks? If they can't be\n>> unified you even get exact matches. Thus, for OVS the context should\n>> not be part of the flow.\n\n> [Mooney, Sean K] I'm not sure what you mean about a list as I never\n> made reference to one. md type 1 context headers are 4 mandatory 32\n> bit field.\n\nThe semantic of the context fields depend on the path id. Every path can\nhave their own interpretation of context fields.\n\nThus the paths will cetainly have their own masks. I hope I understood\nthis part of the standard correctly.\n\ndp only supports installing (approximated) disjoint megaflows and this\naffects performance a lot. Every new mask that gets added to the dp will\nbe installed into a list which will be walked sequentially for\npackets. This will kill performance.\n\nI assume that user space slows down, too, depending on the algorithm\nthey use generate megaflows.\n\nAll in all, this stuff sounds extremely fragile to me. E.g. imagine you\nconfigure a new match on your context and suddenly you start to generate\nexact match flows, they can't be offloaded anymore at more than 10Gbp/s,\nI don't think the network survives this event at all.\n\n> form an ovs context they should be treated the same as the 32 bit register fields.\n> We do not need to necessarily support those in md type 2 as all metadata is optional.\n>> \n>> > Another example of where this is usefull is branching chains. if I\n>> > assume that both the classifier and Service function forwarder are\n>> > collocated in ovs on the host, and is send A packet to a firewall\n>> > service function which tags the packet as suspicious Via setting a\n>> > context header metadata field to 1, I as the sdn controller can\n>> > Install a high priority rule that will reclassify the packet as part\n>> > of as separate Service function chain the will prefer dpi on the\n>> > packet before returning it to The original chain if demand not a\n>> > threat.\n>> \n>> You can do that with different path id's, too?\n> [Mooney, Sean K] a service function is not allowed to alter the spi.\n> Only a classifier can do that. You are correct that a different spi is required for the branch\n> To the dpi sf but packets that are not droped can rejoin the original spi.\n> Packet are not require you to enter a service chain at the first hop.\n>\n> service function chain are explicitly not A list. They are a directed graph composed\n> of service function instance or service function groups that generally \n> are reducible to a directed acrylic graph and in the simple case to a simple list. \n> branching an recovering chains are expected, as is loadblancing between \n> service function instances in the same service function group which share the same spi. \n> The spi filed in the nsh heard is intended to transport the logical service plane path id\n> not the rendered service path id.\n\nUse an explicit action with a parameter to multiplex on a context\nheader, no problem with that.\n\n>> \n>> > So while a sff dose not in general have to be able to match on the\n>> > context header If I assume I want to use ovs to implenet a classifier\n>> > or service function(e.g. loadblancer) The its desirable to be able to\n>> > both match on the context headers in md type1 and also be able To set\n>> > them(this is something classifies and service fuction are allowed to\n>> > do).\n>> \n>> I don't think it is practical at all?\n> [Mooney, Sean K] To day in OpenStack we co-locate the clarifier at every\n> Ovs instance and use mpls as a standing for nsh doing proxing at every hop before sending\n> To an sf. Flow based load balancing is not only practical but has been demonstrated to work with odl gbp classifier\n> and sfc application controlling a patched ovs with nsh support in 2015. \n\nDefine an action to do so.\n\n> If you look at slide 36 of http://events.linuxfoundation.org/sites/events/files/slides/odl%20summit%20sfc%20v5.pdf\n> you will see that prior to the berilium release of odl context header 1 and 2 are used to allow multi-tenancy\n> and overlapping ips. For the loadblancing implentaiton I belived they also used context header 4 to store a flow id.\n> This require odl to generate openflow rules to set the context headers\n> as part of classification.\n\nOkay.\n\n> You can also see that context header 1 and 2 are still used in the newer odl netvirt sfc classifier implementation\n> https://github.com/opendaylight/netvirt/blob/ba22f7cf19d8a827d77a3391a7f654344ade43d8/docs/specs/new-sfc-classifier.rst#pipeline-changes\n> so for odl existing nsh support to work with md type one we must have the ability to set the nsh context headers\n> and should have the ability to match on them also for load lancing between service function in service function group.\n\nAs I said, a separate action sounds much more useful.\n\nBye,\nHannes","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=stressinduktion.org\n\theader.i=@stressinduktion.org header.b=\"S5+s1UXj\"; \n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=messagingengine.com\n\theader.i=@messagingengine.com header.b=\"oDyQM65m\"; \n\tdkim-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 3xjhyy061Mz9sMN\n\tfor ;\n\tThu, 31 Aug 2017 22:49:29 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id 172F7AB9;\n\tThu, 31 Aug 2017 12:49:28 +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 E181FAB5\n\tfor ; Thu, 31 Aug 2017 12:49:26 +0000 (UTC)","from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com\n\t[66.111.4.25])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id CAAB2B0\n\tfor ; Thu, 31 Aug 2017 12:49:25 +0000 (UTC)","from compute7.internal (compute7.nyi.internal [10.202.2.47])\n\tby mailout.nyi.internal (Postfix) with ESMTP id 14F2E20C02;\n\tThu, 31 Aug 2017 08:49:25 -0400 (EDT)","from frontend2 ([10.202.2.161])\n\tby compute7.internal (MEProxy); Thu, 31 Aug 2017 08:49:25 -0400","from z.localhost.stressinduktion.org (unknown [217.192.177.51])\n\tby mail.messagingengine.com (Postfix) with ESMTPA id F30AB24081;\n\tThu, 31 Aug 2017 08:49:23 -0400 (EDT)"],"X-Greylist":"from auto-whitelisted by SQLgrey-1.7.6","DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed; d=\n\tstressinduktion.org; h=cc:content-type:date:from:in-reply-to\n\t:message-id:mime-version:references:subject:to:x-me-sender\n\t:x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=fk0tGOBbNn0O0Y5Yjv\n\t4sXPdSLw5f2njo+0cqI+ZpuKA=; b=S5+s1UXjbiJYMf1qiC31JcC6aE7FItQQFR\n\tXDRK52sHf5KDxj03BD9+1i3dB9srCwBCUy4A5WBTBCqXuGCL3M5CLEoIS5y5YLPO\n\tBiWz42leFirpHE/Y4mIhOLNPbBv+LGFc/YlIR9QO0pLfUPkaR3xyqmHy3zW7A13W\n\t5lU1HVlTcxFOUYX6rful4Lc0a5SuOveyVI+cOuV1QFRrhOZJiD+URXnTI7AxpWqa\n\tS6WCdU8k4A2A3cnAuTwuPy02FZ9Smmoi+gxMeMv5iiZkpmaxlqWp7PyJ4eICJUQb\n\tmC0eesy2exdMLxoWxrHA8LarVkyhFyy9qypPZjiw8U2yy2CzLHRQ==","v=1; a=rsa-sha256; c=relaxed/relaxed; d=\n\tmessagingengine.com; h=cc:content-type:date:from:in-reply-to\n\t:message-id:mime-version:references:subject:to:x-me-sender\n\t:x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=fk0tGOBbNn0O0Y5Yjv\n\t4sXPdSLw5f2njo+0cqI+ZpuKA=; b=oDyQM65mibEqu1ijQKXiPys9lSVWeiMK5M\n\tvBQO5ZN8w+WF232hbfNmBaBZK+IZqu5yLRKrNkSVXeaRF5yMmfRl4gwd1ctw95OO\n\tietDBa3TzIW5HM87ndm1a4AwaKolHQ2JIfCiMN1itTyZgAiWhBSHIyB+A7THi74i\n\tUqqdakTZBlAqMLsprYkgm8r+24/q0KGzFvsn4OhaCrPaH8c3cZ+KtowKgeySecC1\n\tKy8nmlhDNj3OnPSRurpjYhKpp8HwJgMtuFq15wQFfqD2XcJdIpCkHn4PSLyzxVwc\n\tn17x4YN0DcU4dPosYKlIM7uwHMA+tSEws65dbgQ+NuCB/4JRsGKw=="],"X-ME-Sender":"","X-Sasl-enc":"nvlZe/JyzZqDHnq+ENrh/2tYxQXNvbi3wwUB3FTfbe0I 1504183764","From":"Hannes Frederic Sowa ","To":"\"Mooney\\, Sean K\" ","References":"<1503670805-31051-1-git-send-email-yi.y.yang@intel.com>\n\t<1503670805-31051-4-git-send-email-yi.y.yang@intel.com>\n\t<87wp5l7560.fsf@stressinduktion.org>\n\t<4B1BB321037C0849AAE171801564DFA6888FAED3@IRSMSX107.ger.corp.intel.com>\n\t<87inh56q8u.fsf@stressinduktion.org>\n\t<4B1BB321037C0849AAE171801564DFA6888FB254@IRSMSX107.ger.corp.intel.com>","Date":"Thu, 31 Aug 2017 14:49:22 +0200","In-Reply-To":"<4B1BB321037C0849AAE171801564DFA6888FB254@IRSMSX107.ger.corp.intel.com>\n\t(Sean K. Mooney's message of \"Wed, 30 Aug 2017 19:00:44 +0000\")","Message-ID":"<87d17boqb1.fsf@stressinduktion.org>","User-Agent":"Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)","MIME-Version":"1.0","X-Spam-Status":"No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,\n\tDKIM_VALID_AU,RCVD_IN_DNSWL_LOW 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\" , \"e@erig.me\" ,\n\t\"jbenc@redhat.com\" ,\n\t\"netdev@vger.kernel.org\" ","Subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","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":1761635,"web_url":"http://patchwork.ozlabs.org/comment/1761635/","msgid":"","list_archive_url":null,"date":"2017-09-01T12:11:03","subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable\n\tNSH\tsupport","submitter":{"id":68449,"url":"http://patchwork.ozlabs.org/api/people/68449/","name":"Jan Scheurich","email":"jan.scheurich@ericsson.com"},"content":"> > [Mooney, Sean K]\n> > Having the nsh context headers in the flow is quite useful It would\n> > allow loadblancing on values stored in the context headers Or other\n> > use. I belive odl previously used context header 4 to store a Flow id\n> > so this could potentialy be used with the multipath action to have ovs\n> > Choose between several possible next hops in the chain.\n> \n> In OVS, masks are a list(!) for matching. How can this work for different\n> paths that might require different masks? If they can't be unified you even\n> get exact matches. Thus, for OVS the context should not be part of the\n> flow.\n\nThe NSH support in OVS 2.8 (for the user-space datapath only, so far) supports matching on and manipulating the fixed size MD1 context headers C1-C4. They are part of the flow and there are corresponding OXM fields defined. It is up to the SDN controller to program pipelines that match on or set these fields. \n\nThe goal was to support all relevant NSH use cases for MD1: Classifier, SFF, and (with certain limitations) NSH proxy, and SF.\n\nWe also support MD2 TLV context headers but not yet for matching and setting, so MD2 TLVs are not part of the flow. OVS 2.8 can add MD2 context TLVs with the encap(nsh) action (classifier use case), can transparently forward MD2 headers (SFF use case) and pop an NSH header with MD2 context (final SFF use case). Support for matching and setting MD2 TLVs is FFS and can be added in a later release.\n\nBR, Jan","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 3xkJ4G2NB9z9s3w\n\tfor ;\n\tFri, 1 Sep 2017 22:11:10 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id 97C23CCE;\n\tFri, 1 Sep 2017 12:11:07 +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 9067BCC6\n\tfor ; Fri, 1 Sep 2017 12:11:06 +0000 (UTC)","from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id E909379\n\tfor ; Fri, 1 Sep 2017 12:11:05 +0000 (UTC)","from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63])\n\tby sessmg23.ericsson.net (Symantec Mail Security) with SMTP id\n\t2A.17.22436.75E49A95; Fri, 1 Sep 2017 14:11:04 +0200 (CEST)","from ESESSMB107.ericsson.se ([169.254.7.26]) by\n\tESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0352.000; \n\tFri, 1 Sep 2017 14:11:03 +0200"],"X-Greylist":"domain auto-whitelisted by SQLgrey-1.7.6","X-AuditID":"c1b4fb2d-103ff700000057a4-b3-59a94e57ba72","From":"Jan Scheurich ","To":"Hannes Frederic Sowa , \"Mooney, Sean K\"\n\t","Thread-Topic":"[ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","Thread-Index":"AQHTIaLhQ5S/el03Z0+SlkcuGO+BraKf8FEA","Date":"Fri, 1 Sep 2017 12:11:03 +0000","Message-ID":"","References":"<1503670805-31051-1-git-send-email-yi.y.yang@intel.com>\n\t<1503670805-31051-4-git-send-email-yi.y.yang@intel.com>\n\t<87wp5l7560.fsf@stressinduktion.org>\n\t<4B1BB321037C0849AAE171801564DFA6888FAED3@IRSMSX107.ger.corp.intel.com>\n\t<87inh56q8u.fsf@stressinduktion.org>","In-Reply-To":"<87inh56q8u.fsf@stressinduktion.org>","Accept-Language":"en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","x-originating-ip":"[153.88.183.146]","MIME-Version":"1.0","X-Brightmail-Tracker":"H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUyM2K7vW6E38pIg9kNHBZHT+9htljcc4LJ\n\tYvNkZ4sVm04zWxxbIGbRe6uHxeL3121MDuweRxYdZPRYvOclk8ezm/8ZPd7vu8rm8eLiKRaP\n\tz5vkAtiiuGxSUnMyy1KL9O0SuDJWvzjNUvCDu2LW2jVMDYzrOLsYOTkkBEwkpv+bzQxiCwkc\n\tYZTY3sjSxcgFZC9ilDjR/QDI4eBgEzCQmL3bAaRGRCBZYvPixcwgNcwCjxglNp6eyA6SEBYI\n\tkLjRsIQFoihQYs6Wi6wQtpHE763fwWwWARWJvl1/mEBsXgFfia5v76CWTWWSeHrjFVgRp4Ch\n\txIwl3WA2o4CYxPdTa8AamAXEJW49mc8EcbWAxJI955khbFGJl4//sULYShI/NlxigajXkViw\n\t+xMbhK0tsWzha2aIxYISJ2c+YZnAKDoLydhZSFpmIWmZhaRlASPLKkbR4tTi4tx0I2O91KLM\n\t5OLi/Dy9vNSSTYzA6Du45bfuDsbVrx0PMQpwMCrx8K6auCJSiDWxrLgy9xCjBAezkgjvXZ+V\n\tkUK8KYmVValF+fFFpTmpxYcYpTlYlMR5HfZdiBASSE8sSc1OTS1ILYLJMnFwSjUw9lrMmfj7\n\t6PULb547pRT/uN4tVnLvmlma3euZZoax8cpy4Ve2dHV3OT6d8+P4Bs+e/PTf7imyzvMLps9n\n\tv28RsH/eDCnRvtq9PSZzrlmfP9zgHO559lwRp8Pd1tWXC1wt7uYc7K9UmJLx8EvJM8HuWzvm\n\tiNU3Z2/lVklTFm1/sH/H5B8n6yfIKLEUZyQaajEXFScCACC3lEO6AgAA","X-Spam-Status":"No, score=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED\n\tautolearn=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\" ,\n\t\"netdev@vger.kernel.org\" ,\n\t\"e@erig.me\" , \"jbenc@redhat.com\" ","Subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable\n\tNSH\tsupport","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":1762397,"web_url":"http://patchwork.ozlabs.org/comment/1762397/","msgid":"<20170904023831.GA68062@cran64.bj.intel.com>","list_archive_url":null,"date":"2017-09-04T02:38:32","subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","submitter":{"id":68962,"url":"http://patchwork.ozlabs.org/api/people/68962/","name":"Yang, Yi","email":"yi.y.yang@intel.com"},"content":"On Wed, Aug 30, 2017 at 05:53:27PM +0800, Hannes Frederic Sowa wrote:\n> Hello,\n> \n> Yi Yang writes:\n> \n> [...]\n> \n> > +struct ovs_key_nsh {\n> > +\tu8 flags;\n> > +\tu8 ttl;\n> > +\tu8 mdtype;\n> > +\tu8 np;\n> > +\t__be32 path_hdr;\n> > +\t__be32 context[NSH_MD1_CONTEXT_SIZE];\n> > +};\n> > +\n> > struct sw_flow_key {\n> > \tu8 tun_opts[IP_TUNNEL_OPTS_MAX];\n> > \tu8 tun_opts_len;\n> > @@ -144,6 +154,7 @@ struct sw_flow_key {\n> > \t\t\t};\n> > \t\t} ipv6;\n> > \t};\n> > +\tstruct ovs_key_nsh nsh; /* network service header */\n> > \tstruct {\n> > \t\t/* Connection tracking fields not packed above. */\n> > \t\tstruct {\n> \n> Does it makes sense to keep the context headers as part of the flow?\n> What is the reasoning behind it? With mdtype 2 headers this might either\n> not work very well or will increase sw_flow_key size causing slowdowns\n> for all protocols.\n\nFor userspace, miniflow can handle such issue, but kernel data path\ndidn't provide such mechanism, so I don't think we can think of a better\nway to fix this.\n\nWe have to have context headers in flow for match and set, every hop in\nservice function chaining can put its metedata into context headers on\ndemand, MD type 2 is much more complicated than you can imagine, it is\nimpossible to use an uniform way to handle MD type 1 and MD type 2, our\nway is to keep MD type 1 keys in struct ovs_key_nsh and to reuse struct\nflow_tnl for MD type 2 metadata, in case of MD type 2, we can set\ncontext headers to 0 in struct ovs_key_nsh.\n\nI beleive every newly-added key will result in similiar issue you\nconcern, maybe it will be better to introduce miniflow in kernel data\npath, but it isn't in scope of this patch series.\n\nIt will be great if you can have a better proposal to fix your concern.\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=)","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 3xlvYM4rtFz9s7f\n\tfor ;\n\tMon, 4 Sep 2017 12:53:26 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id EFF90722;\n\tMon, 4 Sep 2017 02: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 C2E1D516\n\tfor ; Mon, 4 Sep 2017 02:53:23 +0000 (UTC)","from mga11.intel.com (mga11.intel.com [192.55.52.93])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id 535B4428\n\tfor ; Mon, 4 Sep 2017 02:53:23 +0000 (UTC)","from fmsmga002.fm.intel.com ([10.253.24.26])\n\tby fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t03 Sep 2017 19:53:22 -0700","from unknown (HELO cran64.bj.intel.com) ([10.240.224.181])\n\tby fmsmga002.fm.intel.com with ESMTP; 03 Sep 2017 19:53:21 -0700"],"X-Greylist":"domain auto-whitelisted by SQLgrey-1.7.6","X-ExtLoop1":"1","X-IronPort-AV":"E=Sophos; i=\"5.41,473,1498546800\"; d=\"scan'208\";\n\ta=\"1214316413\"","Date":"Mon, 4 Sep 2017 10:38:32 +0800","From":"\"Yang, Yi\" ","To":"Hannes Frederic Sowa ","Message-ID":"<20170904023831.GA68062@cran64.bj.intel.com>","References":"<1503670805-31051-1-git-send-email-yi.y.yang@intel.com>\n\t<1503670805-31051-4-git-send-email-yi.y.yang@intel.com>\n\t<87wp5l7560.fsf@stressinduktion.org>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<87wp5l7560.fsf@stressinduktion.org>","User-Agent":"Mutt/1.5.23 (2014-03-12)","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\" ,\n\t\"netdev@vger.kernel.org\" ,\n\t\"jbenc@redhat.com\" , \"e@erig.me\" ","Subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","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":1762541,"web_url":"http://patchwork.ozlabs.org/comment/1762541/","msgid":"","list_archive_url":null,"date":"2017-09-04T09:38:41","subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable\n\tNSH\tsupport","submitter":{"id":68449,"url":"http://patchwork.ozlabs.org/api/people/68449/","name":"Jan Scheurich","email":"jan.scheurich@ericsson.com"},"content":"> >> >> Does it makes sense to keep the context headers as part of the flow?\n> >> >> What is the reasoning behind it? With mdtype 2 headers this might\n> >> >> either not work very well or will increase sw_flow_key size causing\n> >> >> slowdowns for all protocols.\n> >> > [Mooney, Sean K]\n> >> > Having the nsh context headers in the flow is quite useful It would\n> >> > allow loadblancing on values stored in the context headers Or other\n> >> > use. I belive odl previously used context header 4 to store a Flow id\n> >> > so this could potentialy be used with the multipath action to have\n> >> ovs\n> >> > Choose between several possible next hops in the chain.\n> >>\n> >> In OVS, masks are a list(!) for matching. How can this work for\n> >> different paths that might require different masks? If they can't be\n> >> unified you even get exact matches. Thus, for OVS the context should\n> >> not be part of the flow.\n> \n> > [Mooney, Sean K] I'm not sure what you mean about a list as I never\n> > made reference to one. md type 1 context headers are 4 mandatory 32\n> > bit field.\n> \n> The semantic of the context fields depend on the path id. Every path can\n> have their own interpretation of context fields.\n> \n> Thus the paths will cetainly have their own masks. I hope I understood\n> this part of the standard correctly.\n> \n> dp only supports installing (approximated) disjoint megaflows and this\n> affects performance a lot. Every new mask that gets added to the dp will\n> be installed into a list which will be walked sequentially for\n> packets. This will kill performance.\n> \n> I assume that user space slows down, too, depending on the algorithm\n> they use generate megaflows.\n\nThe primary use case for OVS in SFC/NSH is SFF. In almost all SFF use \ncases OVS will not need to match on context headers. The ability of OVS\nto match on context headers should not in general slow down the datapath.\n\nWhen SFC controllers match on parts of the context headers (e.g. in the \nfinal SFF or for load-balancing purposes), we will get additional megaflow \nmasks. This is a fact of life in OVS and nothing new in NSH. I don't think\nthis should prevent us from supporting valid use cases in OVS.\n\nThe slow-down of the megaflow lookup in the datapath with the number \nof masks has been addressed in the user-space datapath with sorting the\nmask lists according to hit frequency and maintaining one sorted lists per \ningress port. There is further work in progress to improve on this with a\ncuckoo hash to pick the most likely mask first.\nIt should be possible to apply similar optimization schemes also in the\nKernel datapath.\n\n> > form an ovs context they should be treated the same as the 32 bit register fields.\n> > We do not need to necessarily support those in md type 2 as all metadata is optional.\n\nSupport for matching on or updating MD2 TLV context headers is FFS in a\nfuture OVS release. We do not foresee to add MD2 TLVs explicitly to the \nflow struct.\n\n> > You can also see that context header 1 and 2 are still used in the newer odl netvirt sfc classifier implementation\n> > https://github.com/opendaylight/netvirt/blob/ba22f7cf19d8a827d77a3391a7f654344ade43d8/docs/specs/new-sfc-\n> classifier.rst#pipeline-changes\n> > so for odl existing nsh support to work with md type one we must have the ability to set the nsh context headers\n> > and should have the ability to match on them also for load lancing between service function in service function group.\n> \n> As I said, a separate action sounds much more useful.\n\nI don't think it is a good approach in OVS to introduce custom actions for NSH, e.g. for load sharing based on context header data. The primary tool for load sharing in OpenFlow is the Select Group. OVS already support an extension to the OF 1.5 Group Mod message to specify which fields to hash on. This can be used to hash on the relevant NSH context headers.\n\nBR, Jan","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 3xm4YQ58cSz9s7C\n\tfor ;\n\tMon, 4 Sep 2017 19:39:06 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id C7E37892;\n\tMon, 4 Sep 2017 09:39:03 +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 E7FFC892\n\tfor ; Mon, 4 Sep 2017 09:39:01 +0000 (UTC)","from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9D5A8134\n\tfor ; Mon, 4 Sep 2017 09:39:00 +0000 (UTC)","from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21])\n\tby sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id\n\t73.CF.22679.23F1DA95; Mon, 4 Sep 2017 11:38:58 +0200 (CEST)","from ESESSMB107.ericsson.se ([169.254.7.26]) by\n\tESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0352.000; \n\tMon, 4 Sep 2017 11:38:41 +0200"],"X-Greylist":"domain auto-whitelisted by SQLgrey-1.7.6","X-AuditID":"c1b4fb30-96f7a9c000005897-70-59ad1f321f5e","From":"Jan Scheurich ","To":"Hannes Frederic Sowa , \"Mooney, Sean K\"\n\t","Thread-Topic":"[ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","Thread-Index":"AQHTIleRQ5S/el03Z0+SlkcuGO+BraKkbjyw","Date":"Mon, 4 Sep 2017 09:38:41 +0000","Message-ID":"","References":"<1503670805-31051-1-git-send-email-yi.y.yang@intel.com>\n\t<1503670805-31051-4-git-send-email-yi.y.yang@intel.com>\n\t<87wp5l7560.fsf@stressinduktion.org>\n\t<4B1BB321037C0849AAE171801564DFA6888FAED3@IRSMSX107.ger.corp.intel.com>\n\t<87inh56q8u.fsf@stressinduktion.org>\n\t<4B1BB321037C0849AAE171801564DFA6888FB254@IRSMSX107.ger.corp.intel.com>\n\t<87d17boqb1.fsf@stressinduktion.org>","In-Reply-To":"<87d17boqb1.fsf@stressinduktion.org>","Accept-Language":"en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","x-originating-ip":"[153.88.183.20]","MIME-Version":"1.0","X-Brightmail-Tracker":"H4sIAAAAAAAAA+NgFlrMIsWRmVeSWpSXmKPExsUyM2K7qK6R/NpIg+apJhZHT+9htljcc4LJ\n\tYvNkZ4sVm04zWxxbIGbRe6uHxYHN48iig4wei/e8ZPJ4dvM/o8f7fVfZPF5cPMXi8XmTXABb\n\tFJdNSmpOZllqkb5dAlfGxhun2At2yFc8Ot/L0sD4Q6KLkZNDQsBE4vbC/+xdjFwcQgJHGCWO\n\ttt9ignAWMUo0TWli7GLk4GATMJCYvdsBpEFEIFli8+LFzCA1zALLGCWeHDnIBJIQFgiQuNGw\n\thAWiKFBizpaLrBC2kcTWX/PAbBYBFYkdkzczgti8Ar4SLz8tYIZY1sYs8f/EJ7AiTgFDiWlz\n\te8CKGAXEJL6fWgO2gFlAXOLWk/lMEGcLSCzZc54ZwhaVePn4HyuErShxdfpyqHodiQW7P7FB\n\t2NoSyxa+ZoZYLChxcuYTlgmMorOQjJ2FpGUWkpZZSFoWMLKsYhQtTi1Oyk03MtJLLcpMLi7O\n\tz9PLSy3ZxAiMuoNbfhvsYHz53PEQowAHoxIP71u5tZFCrIllxZW5hxglOJiVRHhteIFCvCmJ\n\tlVWpRfnxRaU5qcWHGKU5WJTEeR33XYgQEkhPLEnNTk0tSC2CyTJxcEo1MJYcWyefoK73Iab7\n\t/+wXooxnxX/5+hSvuqq93PfdSbkj7sufyMWuX3qTX/3cH7MvTcZVzXtshNcV1K69W3G9vyvZ\n\tveq6XezkYtkM17LQzwa8Ny5fX6a0yND0tcHtvQ9Oy4jxe/ZqmJs+tnn0/VFB1Y0GnQnbOPOO\n\tf2yvz71pcO3t8Z25Yv93GiixFGckGmoxFxUnAgBwvuBwtgIAAA==","X-Spam-Status":"No, score=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED\n\tautolearn=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\" ,\n\t\"netdev@vger.kernel.org\" ,\n\t\"e@erig.me\" , \"jbenc@redhat.com\" ","Subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable\n\tNSH\tsupport","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":1762585,"web_url":"http://patchwork.ozlabs.org/comment/1762585/","msgid":"<87mv6abte5.fsf@stressinduktion.org>","list_archive_url":null,"date":"2017-09-04T11:22:26","subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","submitter":{"id":18284,"url":"http://patchwork.ozlabs.org/api/people/18284/","name":"Hannes Frederic Sowa","email":"hannes@stressinduktion.org"},"content":"Hello,\n\n\"Yang, Yi\" writes:\n\n> On Wed, Aug 30, 2017 at 05:53:27PM +0800, Hannes Frederic Sowa wrote:\n>> Hello,\n>> \n>> Yi Yang writes:\n>> \n>> [...]\n>> \n>> > +struct ovs_key_nsh {\n>> > +\tu8 flags;\n>> > +\tu8 ttl;\n>> > +\tu8 mdtype;\n>> > +\tu8 np;\n>> > +\t__be32 path_hdr;\n>> > +\t__be32 context[NSH_MD1_CONTEXT_SIZE];\n>> > +};\n>> > +\n>> > struct sw_flow_key {\n>> > \tu8 tun_opts[IP_TUNNEL_OPTS_MAX];\n>> > \tu8 tun_opts_len;\n>> > @@ -144,6 +154,7 @@ struct sw_flow_key {\n>> > \t\t\t};\n>> > \t\t} ipv6;\n>> > \t};\n>> > +\tstruct ovs_key_nsh nsh; /* network service header */\n>> > \tstruct {\n>> > \t\t/* Connection tracking fields not packed above. */\n>> > \t\tstruct {\n>> \n>> Does it makes sense to keep the context headers as part of the flow?\n>> What is the reasoning behind it? With mdtype 2 headers this might either\n>> not work very well or will increase sw_flow_key size causing slowdowns\n>> for all protocols.\n>\n> For userspace, miniflow can handle such issue, but kernel data path\n> didn't provide such mechanism, so I don't think we can think of a better\n> way to fix this.\n\nI do think that both, kernel and dpdk dp, are fine if you don't match on\ncontext fields, which I think is the common case.\n\nAs soon as a few paths start to match on contexts at different offsets I\nam not sure if miniflow will actually help. I don't know enough about\nthat. Set cover is a NP hard problem, so constructing plain simple flows\nwill be an approximation somewhere anyway at some point.\n\nIf the context values are in some way discrete it might make sense, but\nfor load balancing purposes your ingress router might fill out one\ncontext field with a flow hash of the inner flow to allow ECMP or\nloadbalancing. You might want to treat that separately. Otherwise the\ndifferent paths might always need to context[3] & 0x3 (bits as number of\npossible next hops) and put that into the flow state. Because every hop\nand every path might have different numbers of nexthops etc., I don't\nthink this is easy unifiable anymore.\n\n> We have to have context headers in flow for match and set, every hop in\n> service function chaining can put its metedata into context headers on\n> demand, MD type 2 is much more complicated than you can imagine, it is\n> impossible to use an uniform way to handle MD type 1 and MD type 2, our\n> way is to keep MD type 1 keys in struct ovs_key_nsh and to reuse struct\n> flow_tnl for MD type 2 metadata, in case of MD type 2, we can set\n> context headers to 0 in struct ovs_key_nsh.\n\nUnderstood and agreed.\n\n> I beleive every newly-added key will result in similiar issue you\n> concern, maybe it will be better to introduce miniflow in kernel data\n> path, but it isn't in scope of this patch series.\n\nYou will see the same problem with offloading flows e.g. to network\ncards very soon. Flow explosion here will cause your 100Gbit/s NIC\nsuddenly to go to software slow path.\n\n> It will be great if you can have a better proposal to fix your concern.\n\nI do think that something alike miniflow might make sense, but I don't\nknow enough about miniflow.\n\nNew ACTIONS, that are not only bound to NSH, seem appealing to me at the\nmoment. E.g. have a subtable match in the kernel dp or allowing for some\nOXM % modulo -> select action or neighbor alike thing would probably\ncover a lot of cases in the beginning. The submatch would probably very\nmuch reassemble the miniflow in dpdk dp.\n\nThanks,\nHannes","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=stressinduktion.org\n\theader.i=@stressinduktion.org header.b=\"oaWFH4re\"; \n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=messagingengine.com\n\theader.i=@messagingengine.com header.b=\"jkM384QX\"; \n\tdkim-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 3xm6rr5KXTz9s8J\n\tfor ;\n\tMon, 4 Sep 2017 21:22:35 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id 6D61999F;\n\tMon, 4 Sep 2017 11:22: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 4E4AF40F\n\tfor ; Mon, 4 Sep 2017 11:22:31 +0000 (UTC)","from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com\n\t[66.111.4.25])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id 688DC1E8\n\tfor ; Mon, 4 Sep 2017 11:22:30 +0000 (UTC)","from compute7.internal (compute7.nyi.internal [10.202.2.47])\n\tby mailout.nyi.internal (Postfix) with ESMTP id A431F207B0;\n\tMon, 4 Sep 2017 07:22:29 -0400 (EDT)","from frontend1 ([10.202.2.160])\n\tby compute7.internal (MEProxy); Mon, 04 Sep 2017 07:22:29 -0400","from z.localhost.stressinduktion.org (unknown [217.192.177.51])\n\tby mail.messagingengine.com (Postfix) with ESMTPA id A4E8E7E725;\n\tMon, 4 Sep 2017 07:22:27 -0400 (EDT)"],"X-Greylist":"from auto-whitelisted by SQLgrey-1.7.6","DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed; d=\n\tstressinduktion.org; h=cc:content-type:date:from:in-reply-to\n\t:message-id:mime-version:references:subject:to:x-me-sender\n\t:x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=OZC1J3oXjbaluSH2+c\n\t96jhfSHfWo6t0xgqI5PDTuaE8=; b=oaWFH4reqdyF4lAnNCkVEYgB5zW3tX6caF\n\t6Eexi2EQf/q7neQSBuvKBj/uDMKM0HgFqoY4V8gUSAdeFoT0HruFuA3Mho2ehXuV\n\trsNNh4Zi7vCyinMdp9P1UhVStAh/xTfc3Vd3NeWu/JVB0WFLsqJo6mCuUiD883HK\n\tizMtywoTzN2vMLEh09rvi4rHIsTIRIqCGFX2YvxK6CW/Ll33TAqEKIX/ZX9fxUSz\n\tnXOvtCwJMZI+YPBAvjSLzRyFYJWxmvJmtFntw7ndnFpFMwQKcimDKYVA+nogTsck\n\tpxTXqAhSPGoRGGDMvTDPGC591O/jWM6kjIHL1zif4ODZrrtEfrNg==","v=1; a=rsa-sha256; c=relaxed/relaxed; d=\n\tmessagingengine.com; h=cc:content-type:date:from:in-reply-to\n\t:message-id:mime-version:references:subject:to:x-me-sender\n\t:x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=OZC1J3oXjbaluSH2+c\n\t96jhfSHfWo6t0xgqI5PDTuaE8=; b=jkM384QXsX/cp5eEIxaLHVdlx1uq01A2GY\n\twQzaniTADq2kgKN+rI5w7y3O4a9Q49A4PFd6yvS3brdYXKvEUA2EW0wuFwNMQtOM\n\tp3hbOucMCGGNObp6AcHFjqKaDqipR9LukBOH3POOomhpddCnjWM8NX8sWhgw19dj\n\tYx4yqYR+mEOav2WHMz0YvH6sScsviEnPARruf5WPXkTvzeXh6uXk1WoSgth6j9qm\n\t7xvbJEuF/80aD9lvnzvk98cDXwGM5obgGYnGFbsXfUzT7+lLy9/Hd4RKYbF35cyM\n\tBUad2FzFLXbiHfO26hGWZNUZBiSMZMJWt1eX5F96pNR9Sns7CuPg=="],"X-ME-Sender":"","X-Sasl-enc":"6cKjpDPG5T42GVMvQkMml9nMVDwG6ZIXXyYgC6e+uesR 1504524149","From":"Hannes Frederic Sowa ","To":"\"Yang\\, Yi\" ","References":"<1503670805-31051-1-git-send-email-yi.y.yang@intel.com>\n\t<1503670805-31051-4-git-send-email-yi.y.yang@intel.com>\n\t<87wp5l7560.fsf@stressinduktion.org>\n\t<20170904023831.GA68062@cran64.bj.intel.com>","Date":"Mon, 04 Sep 2017 13:22:26 +0200","In-Reply-To":"<20170904023831.GA68062@cran64.bj.intel.com> (Yi Yang's message\n\tof \"Mon, 4 Sep 2017 10:38:32 +0800\")","Message-ID":"<87mv6abte5.fsf@stressinduktion.org>","User-Agent":"Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)","MIME-Version":"1.0","X-Spam-Status":"No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,\n\tDKIM_VALID_AU,RCVD_IN_DNSWL_LOW 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\" ,\n\t\"netdev@vger.kernel.org\" ,\n\t\"jbenc@redhat.com\" , \"e@erig.me\" ","Subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","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":1762592,"web_url":"http://patchwork.ozlabs.org/comment/1762592/","msgid":"<87ingybsc3.fsf@stressinduktion.org>","list_archive_url":null,"date":"2017-09-04T11:45:16","subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","submitter":{"id":18284,"url":"http://patchwork.ozlabs.org/api/people/18284/","name":"Hannes Frederic Sowa","email":"hannes@stressinduktion.org"},"content":"Hello,\n\nJan Scheurich writes:\n\n>> >> >> Does it makes sense to keep the context headers as part of the flow?\n>> >> >> What is the reasoning behind it? With mdtype 2 headers this might\n>> >> >> either not work very well or will increase sw_flow_key size causing\n>> >> >> slowdowns for all protocols.\n>> >> > [Mooney, Sean K]\n>> >> > Having the nsh context headers in the flow is quite useful It would\n>> >> > allow loadblancing on values stored in the context headers Or other\n>> >> > use. I belive odl previously used context header 4 to store a Flow id\n>> >> > so this could potentialy be used with the multipath action to have\n>> >> ovs\n>> >> > Choose between several possible next hops in the chain.\n>> >>\n>> >> In OVS, masks are a list(!) for matching. How can this work for\n>> >> different paths that might require different masks? If they can't be\n>> >> unified you even get exact matches. Thus, for OVS the context should\n>> >> not be part of the flow.\n>> \n>> > [Mooney, Sean K] I'm not sure what you mean about a list as I never\n>> > made reference to one. md type 1 context headers are 4 mandatory 32\n>> > bit field.\n>> \n>> The semantic of the context fields depend on the path id. Every path can\n>> have their own interpretation of context fields.\n>> \n>> Thus the paths will cetainly have their own masks. I hope I understood\n>> this part of the standard correctly.\n>> \n>> dp only supports installing (approximated) disjoint megaflows and this\n>> affects performance a lot. Every new mask that gets added to the dp will\n>> be installed into a list which will be walked sequentially for\n>> packets. This will kill performance.\n>> \n>> I assume that user space slows down, too, depending on the algorithm\n>> they use generate megaflows.\n>\n> The primary use case for OVS in SFC/NSH is SFF. In almost all SFF use \n> cases OVS will not need to match on context headers. The ability of OVS\n> to match on context headers should not in general slow down the datapath.\n\nThe sw_flow_key is huge nowadays. You will be expanding it to the eigth\ncache line. But I agree that it should not generally slow down the data\npath.\n\n> When SFC controllers match on parts of the context headers (e.g. in the \n> final SFF or for load-balancing purposes), we will get additional megaflow \n> masks. This is a fact of life in OVS and nothing new in NSH. I don't think\n> this should prevent us from supporting valid use cases in OVS.\n\nOther protocols are using entropy from the protocol and load balance on\nthat implicitly. Why not NSH?\n\nI would argue that before NSH the masks were pretty constant. NSH\nintroduces context dependent paths where the design emphasizes to have\ndifferent masks per tenant. I don't think this is the case for other\nprotocols processed by the kernel dp right now. So the megaflow\nunification was rather effective so far.\n\nI expect a major slow down with just 10-20 masks.\n\nBtw. this also affects possibilities to synthesize those flows to\nhardware at all.\n\n> The slow-down of the megaflow lookup in the datapath with the number \n> of masks has been addressed in the user-space datapath with sorting the\n> mask lists according to hit frequency and maintaining one sorted lists per \n> ingress port. There is further work in progress to improve on this with a\n> cuckoo hash to pick the most likely mask first.\n> It should be possible to apply similar optimization schemes also in the\n> Kernel datapath.\n\nLots of optimizations could be done, I agree, but the fundamental\nproblem still exists, especially if you want to be traffic agnostic\n(short slow lived flows, 64 byte size UDP/RTP traffic etc., you\nbasically walk through more layers of abstraction to find your flow\nresolution).\n\n>\n>> > form an ovs context they should be treated the same as the 32 bit register fields.\n>> > We do not need to necessarily support those in md type 2 as all metadata is optional.\n>\n> Support for matching on or updating MD2 TLV context headers is FFS in a\n> future OVS release. We do not foresee to add MD2 TLVs explicitly to the \n> flow struct.\n\nIn my opinion I don't see a difference between MD1 and MD2.\n\n>> > You can also see that context header 1 and 2 are still used in the newer odl netvirt sfc classifier implementation\n>> > https://github.com/opendaylight/netvirt/blob/ba22f7cf19d8a827d77a3391a7f654344ade43d8/docs/specs/new-sfc-\n>> classifier.rst#pipeline-changes\n>> > so for odl existing nsh support to work with md type one we must have the ability to set the nsh context headers\n>> > and should have the ability to match on them also for load lancing between service function in service function group.\n>> \n>> As I said, a separate action sounds much more useful.\n>\n> I don't think it is a good approach in OVS to introduce custom actions\n> for NSH, e.g. for load sharing based on context header data. The\n> primary tool for load sharing in OpenFlow is the Select Group. OVS\n> already support an extension to the OF 1.5 Group Mod message to\n> specify which fields to hash on. This can be used to hash on the\n> relevant NSH context headers.\n\nIt doesn't need to be custom to NSH at all. A load balancing action\nbased on a flow hash seems pretty common to me (I am talking about\nkernel actions here).\n\nThanks and bye,\nHannes","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=stressinduktion.org\n\theader.i=@stressinduktion.org header.b=\"iTdHldLW\"; \n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=messagingengine.com\n\theader.i=@messagingengine.com header.b=\"VT1rptvc\"; \n\tdkim-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 3xm7MB0jMMz9sR9\n\tfor ;\n\tMon, 4 Sep 2017 21:45:24 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id 473CC9F8;\n\tMon, 4 Sep 2017 11:45: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 DEA74989\n\tfor ; Mon, 4 Sep 2017 11:45:20 +0000 (UTC)","from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com\n\t[66.111.4.25])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3FE04134\n\tfor ; Mon, 4 Sep 2017 11:45:20 +0000 (UTC)","from compute7.internal (compute7.nyi.internal [10.202.2.47])\n\tby mailout.nyi.internal (Postfix) with ESMTP id 7D17520D31;\n\tMon, 4 Sep 2017 07:45:19 -0400 (EDT)","from frontend2 ([10.202.2.161])\n\tby compute7.internal (MEProxy); Mon, 04 Sep 2017 07:45:19 -0400","from z.localhost.stressinduktion.org (unknown [217.192.177.51])\n\tby mail.messagingengine.com (Postfix) with ESMTPA id B5C7824A82;\n\tMon, 4 Sep 2017 07:45:17 -0400 (EDT)"],"X-Greylist":"from auto-whitelisted by SQLgrey-1.7.6","DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed; d=\n\tstressinduktion.org; h=cc:content-type:date:from:in-reply-to\n\t:message-id:mime-version:references:subject:to:x-me-sender\n\t:x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=ML4eozVLHkTDaqyVPv\n\tzQjyGPn1XHmvuQpLNrH+9sm+Q=; b=iTdHldLWdGTZqQNFnWaAmmtbfH5rsg9o3s\n\tdhPUSA0IkHIhhZsKcuypLqYoLtciJ3bdV6Y2jw2LGRgftmwnuV5UQJZod5PLaYhW\n\t9QygIkHdSTJMQqpmOQK+bEc/DoC4xMqhmK6y2JHNK+PL9SpCP0I4pJLS2CqNKr4E\n\tk5S5J9RyAI2iWk9XxSXMNauA96lDxYZtrPeQVXNlzbIf4uFRdqHff6pDJP6PWUfL\n\tM4xvWDgEun9j4S/DaFZRO2liCrDlK2m9C6ppeuzdg7dz5XimqhtAQb5SoW818ZYV\n\tDFqNZ474ZKLLEVrQx2TAczvLflhWeI4PGClD7Vfx1ZYqbyXfbeTg==","v=1; a=rsa-sha256; c=relaxed/relaxed; d=\n\tmessagingengine.com; h=cc:content-type:date:from:in-reply-to\n\t:message-id:mime-version:references:subject:to:x-me-sender\n\t:x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=ML4eozVLHkTDaqyVPv\n\tzQjyGPn1XHmvuQpLNrH+9sm+Q=; b=VT1rptvc3uaDWazDytyuThQUNpBDQln4YI\n\tCBWY8zgzpschCHVlukNUN17cyx9zFi2dkPGLz5ufENrEko9JLKRMrgn/6KXAzUfj\n\tUDbhdsi7knpj8n8ajBS9xIvV0b5jn2TZBrEjXLSxWvr+KkVAdG3SUF1s1GmptDwn\n\tsi76dQNpkmZt36sCh/UZQAU7g6chHO/CMAOo4gni7GS02YrmSkZahmy9MtUy/NfR\n\tMmT/qEOzKJGWc8am5pqqg1Q9I+HDVU2AQMBzIWFUMg4JyWtUqyZ7k2MqCgK6ymC9\n\t3VhojQkm1lreuR6Vv326px89vYzbWEfHkeMRJRciRLqqv4wWIBSA=="],"X-ME-Sender":"","X-Sasl-enc":"rXknMNejk6qyeM+KrmTJKKI6ELxKXOMBCFdImHLSf0UP 1504525518","From":"Hannes Frederic Sowa ","To":"Jan Scheurich ","References":"<1503670805-31051-1-git-send-email-yi.y.yang@intel.com>\n\t<1503670805-31051-4-git-send-email-yi.y.yang@intel.com>\n\t<87wp5l7560.fsf@stressinduktion.org>\n\t<4B1BB321037C0849AAE171801564DFA6888FAED3@IRSMSX107.ger.corp.intel.com>\n\t<87inh56q8u.fsf@stressinduktion.org>\n\t<4B1BB321037C0849AAE171801564DFA6888FB254@IRSMSX107.ger.corp.intel.com>\n\t<87d17boqb1.fsf@stressinduktion.org>\n\t","Date":"Mon, 04 Sep 2017 13:45:16 +0200","In-Reply-To":"\n\t(Jan Scheurich's message of \"Mon, 4 Sep 2017 09:38:41 +0000\")","Message-ID":"<87ingybsc3.fsf@stressinduktion.org>","User-Agent":"Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)","MIME-Version":"1.0","X-Spam-Status":"No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,\n\tDKIM_VALID_AU,RCVD_IN_DNSWL_LOW 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\" , \"e@erig.me\" ,\n\t\"jbenc@redhat.com\" ,\n\t\"netdev@vger.kernel.org\" ","Subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","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":1762596,"web_url":"http://patchwork.ozlabs.org/comment/1762596/","msgid":"","list_archive_url":null,"date":"2017-09-04T11:57:37","subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","submitter":{"id":68449,"url":"http://patchwork.ozlabs.org/api/people/68449/","name":"Jan Scheurich","email":"jan.scheurich@ericsson.com"},"content":"> >> Does it makes sense to keep the context headers as part of the flow?\n> >> What is the reasoning behind it? With mdtype 2 headers this might either\n> >> not work very well or will increase sw_flow_key size causing slowdowns\n> >> for all protocols.\n> >\n> > For userspace, miniflow can handle such issue, but kernel data path\n> > didn't provide such mechanism, so I don't think we can think of a better\n> > way to fix this.\n> \n> I do think that both, kernel and dpdk dp, are fine if you don't match on\n> context fields, which I think is the common case.\n\nAgree\n\n> As soon as a few paths start to match on contexts at different offsets I\n> am not sure if miniflow will actually help. I don't know enough about\n> that. Set cover is a NP hard problem, so constructing plain simple flows\n> will be an approximation somewhere anyway at some point.\n> \n> If the context values are in some way discrete it might make sense, but\n> for load balancing purposes your ingress router might fill out one\n> context field with a flow hash of the inner flow to allow ECMP or\n> loadbalancing. You might want to treat that separately. Otherwise the\n> different paths might always need to context[3] & 0x3 (bits as number of\n> possible next hops) and put that into the flow state. Because every hop\n> and every path might have different numbers of nexthops etc., I don't\n> think this is easy unifiable anymore.\n\nYes, that would become a scaling challenge for the datapaths and also for \nschemes to off-load that datapath to HW. I believe it requires discipline\non the controller side to not let the number of needed masks explode for\nOVS.\n\n> > I believe every newly-added key will result in similiar issue you\n> > concern, maybe it will be better to introduce miniflow in kernel data\n> > path, but it isn't in scope of this patch series.\n> \n> You will see the same problem with offloading flows e.g. to network\n> cards very soon. Flow explosion here will cause your 100Gbit/s NIC\n> suddenly to go to software slow path.\n> \n> > It will be great if you can have a better proposal to fix your concern.\n> \n> I do think that something alike miniflow might make sense, but I don't\n> know enough about miniflow.\n\nStruct miniflow in the netdev datapath is merely a compact representation\nof struct flow. struct flow is partitioned in to 64-bit \"stripes\" and struct\nminiflow only stores those 64-bit bit stripes that have a non-zero mask stripe.\nIt reduces the memory footprint for storing packet flow and megaflow entries\nbut does not provide any megaflow lookup performance as such.\n\n> New ACTIONS, that are not only bound to NSH, seem appealing to me at the\n> moment. E.g. have a subtable match in the kernel dp or allowing for some\n> OXM % modulo -> select action or neighbor alike thing would probably\n> cover a lot of cases in the beginning. The submatch would probably very\n> much reassemble the miniflow in dpdk dp.\n\nI would like to discuss your ideas to optimize scalable load-sharing in OVS.\nBut I think we should do that in a separate mail thread to let the immediate\nNSH kernel datapath work proceed. \n\nCan you provide some more details of what you suggest? Perhaps take that \non the ovs-dev mailing list.\n\nBR, Jan","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 3xm7dN6hwWz9s82\n\tfor ;\n\tMon, 4 Sep 2017 21:57:44 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id 2D0DF8E2;\n\tMon, 4 Sep 2017 11:57:42 +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 033FA720\n\tfor ; Mon, 4 Sep 2017 11:57:41 +0000 (UTC)","from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5B5D5D3\n\tfor ; Mon, 4 Sep 2017 11:57:40 +0000 (UTC)","from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69])\n\tby sessmg23.ericsson.net (Symantec Mail Security) with SMTP id\n\t5F.79.22436.2BF3DA95; Mon, 4 Sep 2017 13:57:38 +0200 (CEST)","from ESESSMB107.ericsson.se ([169.254.7.26]) by\n\tESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0352.000; \n\tMon, 4 Sep 2017 13:57:38 +0200"],"X-Greylist":"domain auto-whitelisted by SQLgrey-1.7.6","X-AuditID":"c1b4fb2d-11bff700000057a4-a8-59ad3fb2cc6e","From":"Jan Scheurich ","To":"Hannes Frederic Sowa , \"Yang, Yi\"\n\t","Thread-Topic":"[PATCH net-next v6 3/3] openvswitch: enable NSH support","Thread-Index":"AQHTJXAWHqGBP9SYnEO1eAqwAUNZJaKkl2kw","Date":"Mon, 4 Sep 2017 11:57:37 +0000","Message-ID":"","References":"<1503670805-31051-1-git-send-email-yi.y.yang@intel.com>\n\t<1503670805-31051-4-git-send-email-yi.y.yang@intel.com>\n\t<87wp5l7560.fsf@stressinduktion.org>\n\t<20170904023831.GA68062@cran64.bj.intel.com>\n\t<87mv6abte5.fsf@stressinduktion.org>","In-Reply-To":"<87mv6abte5.fsf@stressinduktion.org>","Accept-Language":"en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","x-originating-ip":"[153.88.183.20]","MIME-Version":"1.0","X-Brightmail-Tracker":"H4sIAAAAAAAAA+NgFlrDIsWRmVeSWpSXmKPExsUyM2K7q+4m+7WRBt9blSxeTW5gtDh6eg+z\n\txeKeE0wWmyc7W6zYdJrZ4tgCMYvfX7cxObB7HFl0kNFj8Z6XTB7Pbv5n9Hh+rYfF4/2+q2we\n\tLy6eYvH4vEkugD2KyyYlNSezLLVI3y6BK6Nlykm2gueSFYvPXWNqYNwi0sXIySEhYCJx/8oK\n\tFhBbSOAIo8Sa80FdjFxA9iJGiSuv1zB2MXJwsAkYSMze7QBSIyIQKdF+4jc7SA2zwGFGiZWH\n\tZ4I1Cwu4SDzafZUFoshVYs/mxawQtpHEkaXv2EFsFgEViTX/HoDZvAK+Eo+nfmSDWPaLUeLo\n\t029sIAlOAUOJtx8WgTUzCohJfD+1hgnEZhYQl7j1ZD4TxNUCEkv2nGeGsEUlXj7+xwphK0pc\n\tnb4cql5HYsHuT2wQtrbEsoWvmSEWC0qcnPmEZQKj6CwkY2chaZmFpGUWkpYFjCyrGEWLU4uL\n\tc9ONjPVSizKTi4vz8/TyUks2MQLj8OCW37o7GFe/djzEKMDBqMTD+9J6baQQa2JZcWXuIUYJ\n\tDmYlEV5nG6AQb0piZVVqUX58UWlOavEhRmkOFiVxXod9FyKEBNITS1KzU1MLUotgskwcnFIN\n\tjGZrVscVL7H+XB/4gZm16Kx6EJ90btZdjdtdzSs0Dmv0N8X7/1p2nvubnFGwvuKfjHA7kbWe\n\tR3+8LVyta7PFbc7asPiSx3znVrZImpbfjRfwP9fkXxjqNCve2yO5oS1qy7/JBuEbbjblOLSf\n\tKZ+myrY9QHDnxCzZD0ETHKaUNOYvfPGdeV66EktxRqKhFnNRcSIAC6MI078CAAA=","X-Spam-Status":"No, score=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED\n\tautolearn=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\" ,\n\t\"netdev@vger.kernel.org\" ,\n\t\"e@erig.me\" , \"jbenc@redhat.com\" ","Subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","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":1762917,"web_url":"http://patchwork.ozlabs.org/comment/1762917/","msgid":"<20170905021112.GA86057@cran64.bj.intel.com>","list_archive_url":null,"date":"2017-09-05T02:11:12","subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","submitter":{"id":68962,"url":"http://patchwork.ozlabs.org/api/people/68962/","name":"Yang, Yi","email":"yi.y.yang@intel.com"},"content":"On Mon, Sep 04, 2017 at 07:22:26PM +0800, Hannes Frederic Sowa wrote:\n> Hello,\n> \n> \"Yang, Yi\" writes:\n> \n> > On Wed, Aug 30, 2017 at 05:53:27PM +0800, Hannes Frederic Sowa wrote:\n> >> Hello,\n> >> \n> >> Yi Yang writes:\n> >> \n> >> [...]\n> >> \n> >> > +struct ovs_key_nsh {\n> >> > +\tu8 flags;\n> >> > +\tu8 ttl;\n> >> > +\tu8 mdtype;\n> >> > +\tu8 np;\n> >> > +\t__be32 path_hdr;\n> >> > +\t__be32 context[NSH_MD1_CONTEXT_SIZE];\n> >> > +};\n> >> > +\n> >> > struct sw_flow_key {\n> >> > \tu8 tun_opts[IP_TUNNEL_OPTS_MAX];\n> >> > \tu8 tun_opts_len;\n> >> > @@ -144,6 +154,7 @@ struct sw_flow_key {\n> >> > \t\t\t};\n> >> > \t\t} ipv6;\n> >> > \t};\n> >> > +\tstruct ovs_key_nsh nsh; /* network service header */\n> >> > \tstruct {\n> >> > \t\t/* Connection tracking fields not packed above. */\n> >> > \t\tstruct {\n> >> \n> >> Does it makes sense to keep the context headers as part of the flow?\n> >> What is the reasoning behind it? With mdtype 2 headers this might either\n> >> not work very well or will increase sw_flow_key size causing slowdowns\n> >> for all protocols.\n> >\n> > For userspace, miniflow can handle such issue, but kernel data path\n> > didn't provide such mechanism, so I don't think we can think of a better\n> > way to fix this.\n> \n> I do think that both, kernel and dpdk dp, are fine if you don't match on\n> context fields, which I think is the common case.\n> \n> As soon as a few paths start to match on contexts at different offsets I\n> am not sure if miniflow will actually help. I don't know enough about\n> that. Set cover is a NP hard problem, so constructing plain simple flows\n> will be an approximation somewhere anyway at some point.\n> \n> If the context values are in some way discrete it might make sense, but\n> for load balancing purposes your ingress router might fill out one\n> context field with a flow hash of the inner flow to allow ECMP or\n> loadbalancing. You might want to treat that separately. Otherwise the\n> different paths might always need to context[3] & 0x3 (bits as number of\n> possible next hops) and put that into the flow state. Because every hop\n> and every path might have different numbers of nexthops etc., I don't\n> think this is easy unifiable anymore.\n\nAnyway, this is a common issue but not NSH-implemention-specific issue.\nIn my perspective, kernel data path won't have better perfromance than\nuserspace DPDK data path, maybe you're considering hardware offload, but\nso far there isn't an infrastructure in OVS to offload NSH.\n\n> \n> > We have to have context headers in flow for match and set, every hop in\n> > service function chaining can put its metedata into context headers on\n> > demand, MD type 2 is much more complicated than you can imagine, it is\n> > impossible to use an uniform way to handle MD type 1 and MD type 2, our\n> > way is to keep MD type 1 keys in struct ovs_key_nsh and to reuse struct\n> > flow_tnl for MD type 2 metadata, in case of MD type 2, we can set\n> > context headers to 0 in struct ovs_key_nsh.\n> \n> Understood and agreed.\n> \n> > I beleive every newly-added key will result in similiar issue you\n> > concern, maybe it will be better to introduce miniflow in kernel data\n> > path, but it isn't in scope of this patch series.\n> \n> You will see the same problem with offloading flows e.g. to network\n> cards very soon. Flow explosion here will cause your 100Gbit/s NIC\n> suddenly to go to software slow path.\n\nDo you mean the whole OVS data path offload? As I said, this is a common\nissue, it isn't NSH-specific.\n\n> \n> > It will be great if you can have a better proposal to fix your concern.\n> \n> I do think that something alike miniflow might make sense, but I don't\n> know enough about miniflow.\n> \n> New ACTIONS, that are not only bound to NSH, seem appealing to me at the\n> moment. E.g. have a subtable match in the kernel dp or allowing for some\n> OXM % modulo -> select action or neighbor alike thing would probably\n> cover a lot of cases in the beginning. The submatch would probably very\n> much reassemble the miniflow in dpdk dp.\n\nI'm not sure what new action you expect to bring here, I think group\naction is just for this, as you said it isn't only bound to NSH, you can\nstart a new thread to discuss this. I don't think it is in scope of NSH.\n\n> \n> Thanks,\n> Hannes","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 3xmVvT2w0Nz9s7c\n\tfor ;\n\tTue, 5 Sep 2017 12:26:12 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id 3360088A;\n\tTue, 5 Sep 2017 02:26: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 01821891\n\tfor ; Tue, 5 Sep 2017 02:26:08 +0000 (UTC)","from mga05.intel.com (mga05.intel.com [192.55.52.43])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9E145D3\n\tfor ; Tue, 5 Sep 2017 02:26:04 +0000 (UTC)","from fmsmga005.fm.intel.com ([10.253.24.32])\n\tby fmsmga105.fm.intel.com with ESMTP; 04 Sep 2017 19:26:04 -0700","from unknown (HELO cran64.bj.intel.com) ([10.240.224.181])\n\tby fmsmga005.fm.intel.com with ESMTP; 04 Sep 2017 19:26:02 -0700"],"X-Greylist":"domain auto-whitelisted by SQLgrey-1.7.6","X-ExtLoop1":"1","X-IronPort-AV":"E=Sophos;i=\"5.41,477,1498546800\"; d=\"scan'208\";a=\"147460099\"","Date":"Tue, 5 Sep 2017 10:11:12 +0800","From":"\"Yang, Yi\" ","To":"Hannes Frederic Sowa ","Message-ID":"<20170905021112.GA86057@cran64.bj.intel.com>","References":"<1503670805-31051-1-git-send-email-yi.y.yang@intel.com>\n\t<1503670805-31051-4-git-send-email-yi.y.yang@intel.com>\n\t<87wp5l7560.fsf@stressinduktion.org>\n\t<20170904023831.GA68062@cran64.bj.intel.com>\n\t<87mv6abte5.fsf@stressinduktion.org>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<87mv6abte5.fsf@stressinduktion.org>","User-Agent":"Mutt/1.5.23 (2014-03-12)","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\" ,\n\t\"netdev@vger.kernel.org\" ,\n\t\"jbenc@redhat.com\" , \"e@erig.me\" ","Subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","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":1763188,"web_url":"http://patchwork.ozlabs.org/comment/1763188/","msgid":"<87vakxsaj2.fsf@stressinduktion.org>","list_archive_url":null,"date":"2017-09-05T10:30:09","subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","submitter":{"id":18284,"url":"http://patchwork.ozlabs.org/api/people/18284/","name":"Hannes Frederic Sowa","email":"hannes@stressinduktion.org"},"content":"\"Yang, Yi\" writes:\n\n> I'm not sure what new action you expect to bring here, I think group\n> action is just for this, as you said it isn't only bound to NSH, you can\n> start a new thread to discuss this. I don't think it is in scope of NSH.\n\nIt is in scope of this discussion as you will provide a user space API\nthat makes the NSH context fields accessible from user space in a\ncertain way. If you commit to this, there is no way going back.\n\nI haven't yet grasped the idea on how those fields will be used in OVS\nbesides load balancing. Even for load balancing the tunnel itself\n(vxlan-gpe + UDP source port or ipv6 flowlabel) already provides enough\nentropy to do per-flow load balancing. What else is needed? Why a\ncontext header for that? You just need multiple action chains and pick\none randomly.\n\nThe only protocol that I can compare that to is geneve with TLVs, but\nthe TLVs are global and uniquie and a property of the networking\nforwarding backplane and not a property of the path inside a tenant. So\nI expect this actually to be the first case where I think that matters.\n\nWhy are context labels that special that they are not part of tun_ops?\n\nThanks,\nHannes","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=stressinduktion.org\n\theader.i=@stressinduktion.org header.b=\"wGOmH5jo\"; \n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=messagingengine.com\n\theader.i=@messagingengine.com header.b=\"nUp4ZQ5S\"; \n\tdkim-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 3xmjfL1wfDz9s4q\n\tfor ;\n\tTue, 5 Sep 2017 20:30:33 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id 52C4AB66;\n\tTue, 5 Sep 2017 10:30:16 +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 C2B05B65\n\tfor ; Tue, 5 Sep 2017 10:30:14 +0000 (UTC)","from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com\n\t[66.111.4.25])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id E7A4C1BB\n\tfor ; Tue, 5 Sep 2017 10:30:13 +0000 (UTC)","from compute7.internal (compute7.nyi.internal [10.202.2.47])\n\tby mailout.nyi.internal (Postfix) with ESMTP id BD43F20BE9;\n\tTue, 5 Sep 2017 06:30:12 -0400 (EDT)","from frontend1 ([10.202.2.160])\n\tby compute7.internal (MEProxy); Tue, 05 Sep 2017 06:30:12 -0400","from z.localhost.stressinduktion.org (unknown [217.192.177.51])\n\tby mail.messagingengine.com (Postfix) with ESMTPA id F2E527F97C;\n\tTue, 5 Sep 2017 06:30:10 -0400 (EDT)"],"X-Greylist":"from auto-whitelisted by SQLgrey-1.7.6","DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed; d=\n\tstressinduktion.org; h=cc:content-type:date:from:in-reply-to\n\t:message-id:mime-version:references:subject:to:x-me-sender\n\t:x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=HGd+btBGW70/kDYiXk\n\tY0v2Jmwm5Jj+AJsi5GSHyfqSw=; b=wGOmH5joCRgn/4D0y9vL0y1kunnnfVi7wV\n\t9Fe/UfsMrutPsXktqEhiEd6CIUvFxe2NZmyoFHTTJ8jn3gcchqk857YHKaDjPHS3\n\tRIJ3WAJJfIJRMyWbeYoYT5IqYtpTsW1+h2caMPVfnNFUOitxBmgs2cEsbRyVRKuN\n\tIfg3VzuV6jc+miVePU6tXMZKsfdVXTJMOto+s9ogyx3llCMt20VaAHTccuuMrHtA\n\thVa58FnWKm46YIXXRYJ2/zWBwIIN6WE0XDxP5pJLkz0uCMFJcrQjpcDu/U4e+fsU\n\tliKbtMt1tRvM428LOLiXiEvWr0oRDhpTlmyQPozHyf9grM6IAFRA==","v=1; a=rsa-sha256; c=relaxed/relaxed; d=\n\tmessagingengine.com; h=cc:content-type:date:from:in-reply-to\n\t:message-id:mime-version:references:subject:to:x-me-sender\n\t:x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=HGd+btBGW70/kDYiXk\n\tY0v2Jmwm5Jj+AJsi5GSHyfqSw=; b=nUp4ZQ5S2WZuQVA/3UnXFjucwpLoY+KqrD\n\tLPpvuHK7NuI9UKPpS3X2k+51cVYRC6Aob2TTRDOc5Evz0ELi6HSdSMOTRac8CQFK\n\tX64WvSO2s7u3ryNw7WwajcPWFGgEjUVYT/bLm5EGgQJE1LVf4c/gYKRMvgtpeYvi\n\tOg9L0/4xKAy2icDZpud+p7hny7oZR6mP0c4ymRcNbzw+ln+5AgMVLccHmZzR1Ibe\n\t4qtCpL3FaCyp13LKNsXxDdfYoTblW/aInTNHfnGUlb0ZTqW0eA9nB5UfG1Hh2All\n\tss6irhUtT84qW2aNq2wh2/eI/Xx2w5B8SuqymHmW5HgyA/AWWT7g=="],"X-ME-Sender":"","X-Sasl-enc":"1minj4DK2PeZ7lnu5ZbcpF1kjtenT4ldR1/ZNun2Qt5o 1504607412","From":"Hannes Frederic Sowa ","To":"\"Yang\\, Yi\" ","References":"<1503670805-31051-1-git-send-email-yi.y.yang@intel.com>\n\t<1503670805-31051-4-git-send-email-yi.y.yang@intel.com>\n\t<87wp5l7560.fsf@stressinduktion.org>\n\t<20170904023831.GA68062@cran64.bj.intel.com>\n\t<87mv6abte5.fsf@stressinduktion.org>\n\t<20170905021112.GA86057@cran64.bj.intel.com>","Date":"Tue, 05 Sep 2017 12:30:09 +0200","In-Reply-To":"<20170905021112.GA86057@cran64.bj.intel.com> (Yi Yang's message\n\tof \"Tue, 5 Sep 2017 10:11:12 +0800\")","Message-ID":"<87vakxsaj2.fsf@stressinduktion.org>","User-Agent":"Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)","MIME-Version":"1.0","X-Spam-Status":"No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,\n\tDKIM_VALID_AU,RCVD_IN_DNSWL_LOW 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\" ,\n\t\"netdev@vger.kernel.org\" ,\n\t\"jbenc@redhat.com\" , \"e@erig.me\" ","Subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","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":1763263,"web_url":"http://patchwork.ozlabs.org/comment/1763263/","msgid":"<20170905113848.GC92895@cran64.bj.intel.com>","list_archive_url":null,"date":"2017-09-05T11:38:49","subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","submitter":{"id":68962,"url":"http://patchwork.ozlabs.org/api/people/68962/","name":"Yang, Yi","email":"yi.y.yang@intel.com"},"content":"On Tue, Sep 05, 2017 at 12:30:09PM +0200, Hannes Frederic Sowa wrote:\n> \"Yang, Yi\" writes:\n> \n> > I'm not sure what new action you expect to bring here, I think group\n> > action is just for this, as you said it isn't only bound to NSH, you can\n> > start a new thread to discuss this. I don't think it is in scope of NSH.\n> \n> It is in scope of this discussion as you will provide a user space API\n> that makes the NSH context fields accessible from user space in a\n> certain way. If you commit to this, there is no way going back.\n\nWe can change this later if we really find a better way to handle this\nbecause it isn't defined in include/uapi/linux/openvswitch.h, so I still\nhave backdoor to do this if needed :-)\n\n> \n> I haven't yet grasped the idea on how those fields will be used in OVS\n> besides load balancing. Even for load balancing the tunnel itself\n> (vxlan-gpe + UDP source port or ipv6 flowlabel) already provides enough\n> entropy to do per-flow load balancing. What else is needed? Why a\n> context header for that? You just need multiple action chains and pick\n> one randomly.\n\nFor our sfc use case in Opendaylight, we use context[0] for tunnel ID,\ncontext[1] for destination IP for reverse RSP, they are used to match\nand set in OpenFlow table, you can't limit users to use them in such\nways.\n\nIf you check GENEVE implementation, tun_metadata* can be set or matched\nas any other match field.\n\nActually the most important information in NSH are just these context\nheaders, you can't limit imagination of users by removing them from flow\nkeys.\n\nMy point is to bring miniflow into kernel data path to fix your concern,\nthis will benefit your employer directly :-)\n\nI'm just curious your company has hardware to offload NSH? Which\ncompany are you from?\n\n> \n> The only protocol that I can compare that to is geneve with TLVs, but\n> the TLVs are global and uniquie and a property of the networking\n> forwarding backplane and not a property of the path inside a tenant. So\n> I expect this actually to be the first case where I think that matters.\n> \n> Why are context labels that special that they are not part of tun_ops?\n> \n> Thanks,\n> Hannes","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 3xmlVM15rLz9sPs\n\tfor ;\n\tTue, 5 Sep 2017 21:53:46 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id C6D2EB5F;\n\tTue, 5 Sep 2017 11:53:43 +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 581847AA\n\tfor ; Tue, 5 Sep 2017 11:53:42 +0000 (UTC)","from mga07.intel.com (mga07.intel.com [134.134.136.100])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id CC0D542E\n\tfor ; Tue, 5 Sep 2017 11:53:41 +0000 (UTC)","from orsmga005.jf.intel.com ([10.7.209.41])\n\tby orsmga105.jf.intel.com with ESMTP; 05 Sep 2017 04:53:41 -0700","from unknown (HELO cran64.bj.intel.com) ([10.240.224.181])\n\tby orsmga005.jf.intel.com with ESMTP; 05 Sep 2017 04:53:39 -0700"],"X-Greylist":"domain auto-whitelisted by SQLgrey-1.7.6","X-ExtLoop1":"1","X-IronPort-AV":"E=Sophos;i=\"5.41,480,1498546800\"; d=\"scan'208\";a=\"145612593\"","Date":"Tue, 5 Sep 2017 19:38:49 +0800","From":"\"Yang, Yi\" ","To":"Hannes Frederic Sowa ","Message-ID":"<20170905113848.GC92895@cran64.bj.intel.com>","References":"<1503670805-31051-1-git-send-email-yi.y.yang@intel.com>\n\t<1503670805-31051-4-git-send-email-yi.y.yang@intel.com>\n\t<87wp5l7560.fsf@stressinduktion.org>\n\t<20170904023831.GA68062@cran64.bj.intel.com>\n\t<87mv6abte5.fsf@stressinduktion.org>\n\t<20170905021112.GA86057@cran64.bj.intel.com>\n\t<87vakxsaj2.fsf@stressinduktion.org>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<87vakxsaj2.fsf@stressinduktion.org>","User-Agent":"Mutt/1.5.23 (2014-03-12)","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\" ,\n\t\"netdev@vger.kernel.org\" ,\n\t\"jbenc@redhat.com\" , \"e@erig.me\" ","Subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","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":1763283,"web_url":"http://patchwork.ozlabs.org/comment/1763283/","msgid":"","list_archive_url":null,"date":"2017-09-05T12:19:11","subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","submitter":{"id":68449,"url":"http://patchwork.ozlabs.org/api/people/68449/","name":"Jan Scheurich","email":"jan.scheurich@ericsson.com"},"content":"Hi Hannes,\n\nPlease have a look at the Google doc that sketches the overall solution to support NSH in OVS. \nhttps://drive.google.com/open?id=1oWMYUH8sjZJzWa72o2q9kU0N6pNE-rwZcLH3-kbbDR8\n\nIn details it is slightly outdated but the NSH MD1 support (and all prerequisites like PTAP and Generic Encap/Decap) have been implemented in OVS 2.8 (ofproto layer and the userspace datapath). \n\nThe NSH use cases are discussed in the chapter \"Support for NSH\". OVS is primarily targeting the Classifier and SFF use cases. Obviously the classifier must be able to set the MD1 context headers. The final SFF must be able to inspect the context headers, typically to determine the L2 or L3 forwarding context (e.g. VRF) in which to forward the decapsulated packet on to its final destination.\n\nThis information has end-to-end significance for the SFP and is encoded by the classifier in the NSH context headers. It cannot be put into transport tunnel options of e.g. a Geneve tunnel connecting two SFFs along the SFP.\n\nWe are now trying to establish feature parity in the kernel datapath. If the kernel datapath chooses not to support the MD1 fields, OVS with kernel datapath will not be able to address the classifier and final SFF use cases.\n\nBR, Jan\n\n> -----Original Message-----\n> From: Hannes Frederic Sowa [mailto:hannes@stressinduktion.org]\n> Sent: Tuesday, 05 September, 2017 12:30\n> To: Yang, Yi \n> Cc: netdev@vger.kernel.org; dev@openvswitch.org; jbenc@redhat.com; e@erig.me; blp@ovn.org; Jan Scheurich\n> \n> Subject: Re: [PATCH net-next v6 3/3] openvswitch: enable NSH support\n> \n> \"Yang, Yi\" writes:\n> \n> > I'm not sure what new action you expect to bring here, I think group\n> > action is just for this, as you said it isn't only bound to NSH, you can\n> > start a new thread to discuss this. I don't think it is in scope of NSH.\n> \n> It is in scope of this discussion as you will provide a user space API\n> that makes the NSH context fields accessible from user space in a\n> certain way. If you commit to this, there is no way going back.\n> \n> I haven't yet grasped the idea on how those fields will be used in OVS\n> besides load balancing. Even for load balancing the tunnel itself\n> (vxlan-gpe + UDP source port or ipv6 flowlabel) already provides enough\n> entropy to do per-flow load balancing. What else is needed? Why a\n> context header for that? You just need multiple action chains and pick\n> one randomly.\n> \n> The only protocol that I can compare that to is geneve with TLVs, but\n> the TLVs are global and uniquie and a property of the networking\n> forwarding backplane and not a property of the path inside a tenant. So\n> I expect this actually to be the first case where I think that matters.\n> \n> Why are context labels that special that they are not part of tun_ops?\n> \n> Thanks,\n> Hannes","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 3xmm4B2P0hz9sRV\n\tfor ;\n\tTue, 5 Sep 2017 22:19:36 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id 055ABBBC;\n\tTue, 5 Sep 2017 12:19:17 +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 88B0FBB3\n\tfor ; Tue, 5 Sep 2017 12:19:15 +0000 (UTC)","from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id AC45F1F9\n\tfor ; Tue, 5 Sep 2017 12:19:14 +0000 (UTC)","from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21])\n\tby sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id\n\t05.EE.22679.0469EA95; Tue, 5 Sep 2017 14:19:12 +0200 (CEST)","from ESESSMB107.ericsson.se ([169.254.7.26]) by\n\tESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0352.000; \n\tTue, 5 Sep 2017 14:19:12 +0200"],"X-Greylist":"domain auto-whitelisted by SQLgrey-1.7.6","X-AuditID":"c1b4fb30-57fff70000005897-05-59ae9640ea21","From":"Jan Scheurich ","To":"Hannes Frederic Sowa , \"Yang, Yi\"\n\t","Thread-Topic":"[PATCH net-next v6 3/3] openvswitch: enable NSH support","Thread-Index":"AQHTJjHyHqGBP9SYnEO1eAqwAUNZJaKmMg5g","Date":"Tue, 5 Sep 2017 12:19:11 +0000","Message-ID":"","References":"<1503670805-31051-1-git-send-email-yi.y.yang@intel.com>\n\t<1503670805-31051-4-git-send-email-yi.y.yang@intel.com>\n\t<87wp5l7560.fsf@stressinduktion.org>\n\t<20170904023831.GA68062@cran64.bj.intel.com>\n\t<87mv6abte5.fsf@stressinduktion.org>\n\t<20170905021112.GA86057@cran64.bj.intel.com>\n\t<87vakxsaj2.fsf@stressinduktion.org>","In-Reply-To":"<87vakxsaj2.fsf@stressinduktion.org>","Accept-Language":"en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","x-originating-ip":"[153.88.183.18]","MIME-Version":"1.0","X-Brightmail-Tracker":"H4sIAAAAAAAAA+NgFlrDIsWRmVeSWpSXmKPExsUyM2K7qK7DtHWRBl9fWFq8mtzAaHH09B5m\n\ti8U9J5gsNk92tlix6TSzxbEFYha/v25jcmD3OLLoIKPH4j0vmTye3fzP6PH8Wg+Lx/t9V9k8\n\tXlw8xeLxeZNcAHsUl01Kak5mWWqRvl0CV8ayNVsZC9aIV1zZ2MrYwPhMqIuRk0NCwETi+6pb\n\tTF2MXBxCAkcYJTqOvYVyFjFK7H7+gq2LkYODTcBAYvZuB5AGEYFIifYTv9lBapgFDjNKrDw8\n\tkwUkISzgIvFo91UWiCJXiT2bF7NC2EYSp2/MZwexWQRUJA7/2g4W5xXwlXi9/gTUsgtMEqvf\n\tLmYHWcYpYCgxa40fSA2jgJjE91NrmEBsZgFxiVtP5jNBXC0gsWTPeWYIW1Ti5eN/rBC2osTH\n\tV/sYIep1JBbs/sQGYWtLLFv4mhlir6DEyZlPWCYwis5CMnYWkpZZSFpmIWlZwMiyilG0OLU4\n\tKTfdyEgvtSgzubg4P08vL7VkEyMwDg9u+W2wg/Hlc8dDjAIcjEo8vF7F6yKFWBPLiitzDzFK\n\tcDArifAemAwU4k1JrKxKLcqPLyrNSS0+xCjNwaIkzuu470KEkEB6YklqdmpqQWoRTJaJg1Oq\n\tgdG+eOrf6x87V2qy1t0sjti1tMjkkY6eW6lrncJDU4fkJ1GCU2b47tZsOym17NL+MMHM4Hje\n\tRyYyM7Z9uXylZ0HH0gVXdA8Hnb/5933t6Q87qz2Cw3c97FW9IxGmuuUli8/m7Y/1lm/fvDEg\n\t/7PyFG/j9R6qmTtSZ4rmTnn9fueRVdv3izpe3v1XiaU4I9FQi7moOBEAgcCtI78CAAA=","X-Spam-Status":"No, score=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED\n\tautolearn=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\" ,\n\t\"netdev@vger.kernel.org\" ,\n\t\"e@erig.me\" , \"jbenc@redhat.com\" ","Subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","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":1763350,"web_url":"http://patchwork.ozlabs.org/comment/1763350/","msgid":"<878thtmgra.fsf@stressinduktion.org>","list_archive_url":null,"date":"2017-09-05T13:12:09","subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","submitter":{"id":18284,"url":"http://patchwork.ozlabs.org/api/people/18284/","name":"Hannes Frederic Sowa","email":"hannes@stressinduktion.org"},"content":"\"Yang, Yi\" writes:\n\n> On Tue, Sep 05, 2017 at 12:30:09PM +0200, Hannes Frederic Sowa wrote:\n>> \"Yang, Yi\" writes:\n>> \n>> > I'm not sure what new action you expect to bring here, I think group\n>> > action is just for this, as you said it isn't only bound to NSH, you can\n>> > start a new thread to discuss this. I don't think it is in scope of NSH.\n>> \n>> It is in scope of this discussion as you will provide a user space API\n>> that makes the NSH context fields accessible from user space in a\n>> certain way. If you commit to this, there is no way going back.\n>\n> We can change this later if we really find a better way to handle this\n> because it isn't defined in include/uapi/linux/openvswitch.h, so I still\n> have backdoor to do this if needed :-)\n\nSorry, I can't follow you.\n\nIt doesn't matter if something is defined in uapi headers, the\nobservable behavior matters. If you allow users to configure flows with\nspecific fields, it should not stop working at a future point in time.\n\n>> I haven't yet grasped the idea on how those fields will be used in OVS\n>> besides load balancing. Even for load balancing the tunnel itself\n>> (vxlan-gpe + UDP source port or ipv6 flowlabel) already provides enough\n>> entropy to do per-flow load balancing. What else is needed? Why a\n>> context header for that? You just need multiple action chains and pick\n>> one randomly.\n>\n> For our sfc use case in Opendaylight, we use context[0] for tunnel ID,\n> context[1] for destination IP for reverse RSP, they are used to match\n> and set in OpenFlow table, you can't limit users to use them in such\n> ways.\n\nSo in your specific case you expect the masks to be completely stable\nbecause you defined a protocol on top of NSH, understood. And that is\nstable accross all possible paths. Understood as well.\n\n> If you check GENEVE implementation, tun_metadata* can be set or matched\n> as any other match field.\n\nYes, I wrote that in my previous mail. I wonder why NSH context metadata\nis not in tun_metadata as well?\n\n> Actually the most important information in NSH are just these context\n> headers, you can't limit imagination of users by removing them from flow\n> keys.\n>\n> My point is to bring miniflow into kernel data path to fix your concern,\n> this will benefit your employer directly :-)\n\nOkay, interesting. It will probably not help if you still have a hash of\na packet inside the flow table and use that for load balancing.\n\n[...]\n\nBTW I don't want to stop this patch, I am merely interested in how the\nbigger picture will look like in the end.\n\nBye,\nHannes","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=stressinduktion.org\n\theader.i=@stressinduktion.org header.b=\"GNZtKjw7\"; \n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=messagingengine.com\n\theader.i=@messagingengine.com header.b=\"rVNR/sU1\"; \n\tdkim-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 3xmnF06Bfkz9t24\n\tfor ;\n\tTue, 5 Sep 2017 23:12:20 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id 9DA20BC5;\n\tTue, 5 Sep 2017 13:12:16 +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 35C67BAC\n\tfor ; Tue, 5 Sep 2017 13:12:15 +0000 (UTC)","from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com\n\t[66.111.4.25])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id 272B942E\n\tfor ; Tue, 5 Sep 2017 13:12:13 +0000 (UTC)","from compute7.internal (compute7.nyi.internal [10.202.2.47])\n\tby mailout.nyi.internal (Postfix) with ESMTP id C5E0C2108D;\n\tTue, 5 Sep 2017 09:12:12 -0400 (EDT)","from frontend1 ([10.202.2.160])\n\tby compute7.internal (MEProxy); Tue, 05 Sep 2017 09:12:12 -0400","from z.localhost.stressinduktion.org (unknown [217.192.177.51])\n\tby mail.messagingengine.com (Postfix) with ESMTPA id BDFD37F96C;\n\tTue, 5 Sep 2017 09:12:10 -0400 (EDT)"],"X-Greylist":"from auto-whitelisted by SQLgrey-1.7.6","DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed; d=\n\tstressinduktion.org; h=cc:content-type:date:from:in-reply-to\n\t:message-id:mime-version:references:subject:to:x-me-sender\n\t:x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=5Xvvz9uL0/LpDs4lOC\n\t8GFTLo8OvzY/r7iBfXn7HJDgk=; b=GNZtKjw7mWl/wdbxyyKHgY07amPuEEQgNL\n\td7IABnvAQM/z3WhwH+66JoH/ykbhPT5dMTAlFYHOkiH4W2HlGPD3sfrOUbyBfvaa\n\t7+wgHmYDtfT7CUEVYqFwQiQ3CenL3ANt7+I7sgQmTRq3Y5XLq4eEFbTZM20Hyt+9\n\tqWd5D1Eyh3ZyGIYmJPPHpGXp5xeJYRS8df/OQ78Yd6xUTgeBleIlAa9S/GU8k9UY\n\t63jE5oRmVQvG9/Fb8QZlDbdsBjT+D0A4KR7QSAfVn6NHCqrz0qv2NM/Xz21rcvtw\n\tVumyIKBxBWYvt2VwYO+LSYacdpPeBkg1cpIXBeAlDDObcbCnCZnQ==","v=1; a=rsa-sha256; c=relaxed/relaxed; d=\n\tmessagingengine.com; h=cc:content-type:date:from:in-reply-to\n\t:message-id:mime-version:references:subject:to:x-me-sender\n\t:x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=5Xvvz9uL0/LpDs4lOC\n\t8GFTLo8OvzY/r7iBfXn7HJDgk=; b=rVNR/sU1ZYSJD1IV/I60v3T3PTcKcjSjGo\n\tWqaW0XXigbC9fY6qfJqDDHW9TyAVCOEU0KzgX367ktkF0GehjJVIm71dbpp+MiNd\n\tBFm+gLTdWMM9VLzlc3ExXEDUCeP9TQeb49L3txIKQVjbANtoqn0L5esX+mkI7gaL\n\tUTxuq5tI2k06ig3t59VoTKLfxtcSo4xaUXfCJ6gYS4WrmoBHsX83nEOUnBt9XCCf\n\tiLELMFcRXb3VWFyztyZc+ZTO1huKSxAT9SKgXZO67+sJHzl5JN1epA5SJtpN966Z\n\tjW+vNC9m3DCPNAmv8BXWoxeXz9rPyX1PLohY58ovFY53Dz9qtrTw=="],"X-ME-Sender":"","X-Sasl-enc":"CjF+KMtoK6JYxHKqqGf7VtsAM5LCYw6jgWeCW0lo7VuN 1504617132","From":"Hannes Frederic Sowa ","To":"\"Yang\\, Yi\" ","References":"<1503670805-31051-1-git-send-email-yi.y.yang@intel.com>\n\t<1503670805-31051-4-git-send-email-yi.y.yang@intel.com>\n\t<87wp5l7560.fsf@stressinduktion.org>\n\t<20170904023831.GA68062@cran64.bj.intel.com>\n\t<87mv6abte5.fsf@stressinduktion.org>\n\t<20170905021112.GA86057@cran64.bj.intel.com>\n\t<87vakxsaj2.fsf@stressinduktion.org>\n\t<20170905113848.GC92895@cran64.bj.intel.com>","Date":"Tue, 05 Sep 2017 15:12:09 +0200","In-Reply-To":"<20170905113848.GC92895@cran64.bj.intel.com> (Yi Yang's message\n\tof \"Tue, 5 Sep 2017 19:38:49 +0800\")","Message-ID":"<878thtmgra.fsf@stressinduktion.org>","User-Agent":"Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)","MIME-Version":"1.0","X-Spam-Status":"No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,\n\tDKIM_VALID_AU,RCVD_IN_DNSWL_LOW 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\" ,\n\t\"netdev@vger.kernel.org\" ,\n\t\"jbenc@redhat.com\" , \"e@erig.me\" ","Subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","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":1763360,"web_url":"http://patchwork.ozlabs.org/comment/1763360/","msgid":"<874lshmfqa.fsf@stressinduktion.org>","list_archive_url":null,"date":"2017-09-05T13:34:21","subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","submitter":{"id":18284,"url":"http://patchwork.ozlabs.org/api/people/18284/","name":"Hannes Frederic Sowa","email":"hannes@stressinduktion.org"},"content":"Hello Jan,\n\nJan Scheurich writes:\n\n> Please have a look at the Google doc that sketches the overall\n> solution to support NSH in OVS.\n> https://drive.google.com/open?id=1oWMYUH8sjZJzWa72o2q9kU0N6pNE-rwZcLH3-kbbDR8\n>\n> In details it is slightly outdated but the NSH MD1 support (and all\n> prerequisites like PTAP and Generic Encap/Decap) have been implemented\n> in OVS 2.8 (ofproto layer and the userspace datapath).\n>\n> The NSH use cases are discussed in the chapter \"Support for NSH\". OVS\n> is primarily targeting the Classifier and SFF use cases. Obviously the\n> classifier must be able to set the MD1 context headers. The final SFF\n> must be able to inspect the context headers, typically to determine\n> the L2 or L3 forwarding context (e.g. VRF) in which to forward the\n> decapsulated packet on to its final destination.\n\nFrom Yi Yang's mail I understood that you put a tunnel ID into\ncontext[0]. In this case, I can understand that you want to match on\nthat. I was under the impression that the combination of tenant id from\nthe vxlan-gpe header and the path id plus ttl would give enough state\nfor the SDN to keep state on where the packet is in the network. I don't\nunderstand what a tunnel id is.\n\nI understood that the context fields are usable by the service function\nchains, but they are actually in use by the outer SDN and basically\nstandardized.\n\n> This information has end-to-end significance for the SFP and is\n> encoded by the classifier in the NSH context headers. It cannot be put\n> into transport tunnel options of e.g. a Geneve tunnel connecting two\n> SFFs along the SFP.\n\nBecause the TLVs are not end to end in the geneve case? Yes, this makes\nsense.\n\n> We are now trying to establish feature parity in the kernel\n> datapath. If the kernel datapath chooses not to support the MD1\n> fields, OVS with kernel datapath will not be able to address the\n> classifier and final SFF use cases.\n\nAs I understand this now, you are designing some kind of protocol or\nparticular implementation on top of NSH. Thus you don't expect masks to\ngrow limitless and you don't allow any SFC elements to take part in the\ndecision what to communicate over the context fields.\n\nI still wonder about the hash as part of the NSH context and how that\nfits into the picture, which looked like the only standardized\napplication of context headers from your google doc.\n\nBtw., I don't want to block this patch.\n\nBye,\nHannes","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=stressinduktion.org\n\theader.i=@stressinduktion.org header.b=\"dxeJGvhq\"; \n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=messagingengine.com\n\theader.i=@messagingengine.com header.b=\"E5PiCii0\"; \n\tdkim-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 3xmnkc1Cdbz9t2W\n\tfor ;\n\tTue, 5 Sep 2017 23:34:30 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id 3E50F722;\n\tTue, 5 Sep 2017 13:34: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 9D7B1722\n\tfor ; Tue, 5 Sep 2017 13:34:26 +0000 (UTC)","from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com\n\t[66.111.4.25])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id 98A34405\n\tfor ; Tue, 5 Sep 2017 13:34:25 +0000 (UTC)","from compute7.internal (compute7.nyi.internal [10.202.2.47])\n\tby mailout.nyi.internal (Postfix) with ESMTP id A36CC20C90;\n\tTue, 5 Sep 2017 09:34:24 -0400 (EDT)","from frontend2 ([10.202.2.161])\n\tby compute7.internal (MEProxy); Tue, 05 Sep 2017 09:34:24 -0400","from z.localhost.stressinduktion.org (unknown [217.192.177.51])\n\tby mail.messagingengine.com (Postfix) with ESMTPA id 87AEE24A60;\n\tTue, 5 Sep 2017 09:34:22 -0400 (EDT)"],"X-Greylist":"from auto-whitelisted by SQLgrey-1.7.6","DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed; d=\n\tstressinduktion.org; h=cc:content-type:date:from:in-reply-to\n\t:message-id:mime-version:references:subject:to:x-me-sender\n\t:x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=xKy3LnyHbzgcFNsAaH\n\tJid7k7qk9RX3Db6aCPtW/9iNY=; b=dxeJGvhqu5L6lxv2802YBXib2ZsqIKx3NA\n\tXLMsNKA4l+pbsckKiMVYzuszGDnQkMI+e1DYyn1ue1U8iMtTtXtequF/pq7hBfrj\n\t73/VT2kVTgC49msrieuvBVCXdM0YSCQeZbjWtP5xQ6qwvEznHAP1wdChE6kPff4P\n\tNdMSBROBHPGstqpfPIJrG4zNpB5L9FvT5Gw53QLGBgqgvGNX1D7DN0SQD06NO72e\n\t6w509cVP3b7E4EOAniFRprftHNczD8zm5N/9IOQTuSpaXiLuGGYApPDFlMmSuNOL\n\ttZzJkRFcaggfmZtH4HwMoW7eiZ58GVjgOxzsSd6iVIE+UCZ05QhQ==","v=1; a=rsa-sha256; c=relaxed/relaxed; d=\n\tmessagingengine.com; h=cc:content-type:date:from:in-reply-to\n\t:message-id:mime-version:references:subject:to:x-me-sender\n\t:x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=xKy3LnyHbzgcFNsAaH\n\tJid7k7qk9RX3Db6aCPtW/9iNY=; b=E5PiCii0Qzrg/VlnPg5oJm8vLiL2Ds1iIo\n\twqaQiIabPzi4RgMbTVb3fBQSj5BLsXE+dHGjjGdEromZFRri5E3jEGKOLxvGZnT6\n\tpHNW4Wq1hrJk2Cm9PLgcvPQ6rakVZ5Wevgn0q6Jq7dnbDS4r9af5bIThS3TwlmC0\n\tL0ne91xgVZL6UpWVl+hUy1g93wydLrH1csxu6SmZVVNxBSpqWmu158yxxLggrlbg\n\tkPA7X2nKtqBBlUsNsj1vCL8+X7UDmexTOug06TQzKV2bKHrYIxxkMZy6ZCkeJG4v\n\t+QK7qXOy71/AWGgd+uXhJ7Zd94Mipi5nsxmDu5PaTV9jLwqSErOA=="],"X-ME-Sender":"","X-Sasl-enc":"qUVeaskjWkbBiA/H0LqxPJbJfqSYE7Cyt0XoYcyoIcXn 1504618463","From":"Hannes Frederic Sowa ","To":"Jan Scheurich ","References":"<1503670805-31051-1-git-send-email-yi.y.yang@intel.com>\n\t<1503670805-31051-4-git-send-email-yi.y.yang@intel.com>\n\t<87wp5l7560.fsf@stressinduktion.org>\n\t<20170904023831.GA68062@cran64.bj.intel.com>\n\t<87mv6abte5.fsf@stressinduktion.org>\n\t<20170905021112.GA86057@cran64.bj.intel.com>\n\t<87vakxsaj2.fsf@stressinduktion.org>\n\t","Date":"Tue, 05 Sep 2017 15:34:21 +0200","In-Reply-To":"\n\t(Jan Scheurich's message of \"Tue, 5 Sep 2017 12:19:11 +0000\")","Message-ID":"<874lshmfqa.fsf@stressinduktion.org>","User-Agent":"Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)","MIME-Version":"1.0","X-Spam-Status":"No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,\n\tDKIM_VALID_AU,RCVD_IN_DNSWL_LOW 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\" ,\n\t\"netdev@vger.kernel.org\" ,\n\t\"jbenc@redhat.com\" , \"e@erig.me\" ","Subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","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":1763761,"web_url":"http://patchwork.ozlabs.org/comment/1763761/","msgid":"<20170906005359.GA103260@cran64.bj.intel.com>","list_archive_url":null,"date":"2017-09-06T00:53:59","subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","submitter":{"id":68962,"url":"http://patchwork.ozlabs.org/api/people/68962/","name":"Yang, Yi","email":"yi.y.yang@intel.com"},"content":"On Tue, Sep 05, 2017 at 09:12:09PM +0800, Hannes Frederic Sowa wrote:\n> \"Yang, Yi\" writes:\n> \n> > We can change this later if we really find a better way to handle this\n> > because it isn't defined in include/uapi/linux/openvswitch.h, so I still\n> > have backdoor to do this if needed :-)\n> \n> Sorry, I can't follow you.\n> \n> It doesn't matter if something is defined in uapi headers, the\n> observable behavior matters. If you allow users to configure flows with\n> specific fields, it should not stop working at a future point in time.\n\nAnyway this can be changed if it is really needed, so far current way is\nthe best one we can come up with, we would like to use it if you can\nhave better proposal. We have explained repeatedly context headers must\nbe matched and set, this is bottom line.\n\n> \n> > For our sfc use case in Opendaylight, we use context[0] for tunnel ID,\n> > context[1] for destination IP for reverse RSP, they are used to match\n> > and set in OpenFlow table, you can't limit users to use them in such\n> > ways.\n> \n> So in your specific case you expect the masks to be completely stable\n> because you defined a protocol on top of NSH, understood. And that is\n> stable accross all possible paths. Understood as well.\n> \n> > If you check GENEVE implementation, tun_metadata* can be set or matched\n> > as any other match field.\n> \n> Yes, I wrote that in my previous mail. I wonder why NSH context metadata\n> is not in tun_metadata as well?\n\ntun_metadata is tunnel metadata, GENEVE needs tunnel port, but NSH is\nnot so, NSH can't directly use tun_metadata, for MD type 2, we need to a\nlot of rework on tun_metadata to make it shared between GENEVE and NSH,\nI don't think this can happen in near term. So tun_metadata isn't option\nfor this now.\n\n> \n> > Actually the most important information in NSH are just these context\n> > headers, you can't limit imagination of users by removing them from flow\n> > keys.\n> >\n> > My point is to bring miniflow into kernel data path to fix your concern,\n> > this will benefit your employer directly :-)\n> \n> Okay, interesting. It will probably not help if you still have a hash of\n> a packet inside the flow table and use that for load balancing.\n> \n> [...]\n> \n> BTW I don't want to stop this patch, I am merely interested in how the\n> bigger picture will look like in the end.\n> \n> Bye,\n> Hannes","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 3xn57t0mp0z9s7h\n\tfor ;\n\tWed, 6 Sep 2017 11:08:57 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id 74F0B9E8;\n\tWed, 6 Sep 2017 01:08: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 4F91A92F\n\tfor ; Wed, 6 Sep 2017 01:08:53 +0000 (UTC)","from mga09.intel.com (mga09.intel.com [134.134.136.24])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id C49631BB\n\tfor ; Wed, 6 Sep 2017 01:08:52 +0000 (UTC)","from fmsmga005.fm.intel.com ([10.253.24.32])\n\tby orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t05 Sep 2017 18:08:52 -0700","from unknown (HELO cran64.bj.intel.com) ([10.240.224.181])\n\tby fmsmga005.fm.intel.com with ESMTP; 05 Sep 2017 18:08:50 -0700"],"X-Greylist":"domain auto-whitelisted by SQLgrey-1.7.6","X-ExtLoop1":"1","X-IronPort-AV":"E=Sophos;i=\"5.41,481,1498546800\"; d=\"scan'208\";a=\"147907656\"","Date":"Wed, 6 Sep 2017 08:53:59 +0800","From":"\"Yang, Yi\" ","To":"Hannes Frederic Sowa ","Message-ID":"<20170906005359.GA103260@cran64.bj.intel.com>","References":"<1503670805-31051-1-git-send-email-yi.y.yang@intel.com>\n\t<1503670805-31051-4-git-send-email-yi.y.yang@intel.com>\n\t<87wp5l7560.fsf@stressinduktion.org>\n\t<20170904023831.GA68062@cran64.bj.intel.com>\n\t<87mv6abte5.fsf@stressinduktion.org>\n\t<20170905021112.GA86057@cran64.bj.intel.com>\n\t<87vakxsaj2.fsf@stressinduktion.org>\n\t<20170905113848.GC92895@cran64.bj.intel.com>\n\t<878thtmgra.fsf@stressinduktion.org>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<878thtmgra.fsf@stressinduktion.org>","User-Agent":"Mutt/1.5.23 (2014-03-12)","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\" ,\n\t\"netdev@vger.kernel.org\" ,\n\t\"jbenc@redhat.com\" , \"e@erig.me\" ","Subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","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":1763879,"web_url":"http://patchwork.ozlabs.org/comment/1763879/","msgid":"<87o9qo9ru6.fsf@stressinduktion.org>","list_archive_url":null,"date":"2017-09-06T08:03:29","subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","submitter":{"id":18284,"url":"http://patchwork.ozlabs.org/api/people/18284/","name":"Hannes Frederic Sowa","email":"hannes@stressinduktion.org"},"content":"\"Yang, Yi\" writes:\n\n> On Tue, Sep 05, 2017 at 09:12:09PM +0800, Hannes Frederic Sowa wrote:\n>> \"Yang, Yi\" writes:\n>> \n>> > We can change this later if we really find a better way to handle this\n>> > because it isn't defined in include/uapi/linux/openvswitch.h, so I still\n>> > have backdoor to do this if needed :-)\n>> \n>> Sorry, I can't follow you.\n>> \n>> It doesn't matter if something is defined in uapi headers, the\n>> observable behavior matters. If you allow users to configure flows with\n>> specific fields, it should not stop working at a future point in time.\n>\n> Anyway this can be changed if it is really needed, so far current way is\n> the best one we can come up with, we would like to use it if you can\n> have better proposal. We have explained repeatedly context headers must\n> be matched and set, this is bottom line.\n\nI understand that in the way you use those context fields you will have\nto match on those. I understand that there is no way around that.\n\n>> > For our sfc use case in Opendaylight, we use context[0] for tunnel ID,\n>> > context[1] for destination IP for reverse RSP, they are used to match\n>> > and set in OpenFlow table, you can't limit users to use them in such\n>> > ways.\n>> \n>> So in your specific case you expect the masks to be completely stable\n>> because you defined a protocol on top of NSH, understood. And that is\n>> stable accross all possible paths. Understood as well.\n>> \n>> > If you check GENEVE implementation, tun_metadata* can be set or matched\n>> > as any other match field.\n>> \n>> Yes, I wrote that in my previous mail. I wonder why NSH context metadata\n>> is not in tun_metadata as well?\n>\n> tun_metadata is tunnel metadata, GENEVE needs tunnel port, but NSH is\n> not so, NSH can't directly use tun_metadata, for MD type 2, we need to a\n> lot of rework on tun_metadata to make it shared between GENEVE and NSH,\n> I don't think this can happen in near term. So tun_metadata isn't option\n> for this now.\n\nSorry, I couldn't follow you. Why can't you store the context headers in\ntun_metadata exactly?\n\n[...]\n\nBye,\nHannes","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=stressinduktion.org\n\theader.i=@stressinduktion.org header.b=\"P6BKTZ4j\"; \n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=messagingengine.com\n\theader.i=@messagingengine.com header.b=\"R5fbYF/7\"; \n\tdkim-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 3xnGLN3T1tz9s8J\n\tfor ;\n\tWed, 6 Sep 2017 18:03:39 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id 97C72ACC;\n\tWed, 6 Sep 2017 08:03: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 A3D54A7F\n\tfor ; Wed, 6 Sep 2017 08:03:34 +0000 (UTC)","from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com\n\t[66.111.4.25])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id D19D2127\n\tfor ; Wed, 6 Sep 2017 08:03:33 +0000 (UTC)","from compute7.internal (compute7.nyi.internal [10.202.2.47])\n\tby mailout.nyi.internal (Postfix) with ESMTP id 0145E20DF0;\n\tWed, 6 Sep 2017 04:03:33 -0400 (EDT)","from frontend1 ([10.202.2.160])\n\tby compute7.internal (MEProxy); Wed, 06 Sep 2017 04:03:33 -0400","from z.localhost.stressinduktion.org (unknown [217.192.177.51])\n\tby mail.messagingengine.com (Postfix) with ESMTPA id 0020E7F97D;\n\tWed, 6 Sep 2017 04:03:30 -0400 (EDT)"],"X-Greylist":"from auto-whitelisted by SQLgrey-1.7.6","DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed; d=\n\tstressinduktion.org; h=cc:content-type:date:from:in-reply-to\n\t:message-id:mime-version:references:subject:to:x-me-sender\n\t:x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=DifZS3GLTPw90t2dMC\n\tJeXau8VldxK7JylfJGeFCZZPE=; b=P6BKTZ4jRMgxqNmpBS+JX2KtjqsnZ/8YAk\n\tD082CEBkh1cYt6ZBj2EVw+sTnJyoRhLyuAcAAwgQsyeC2cEYAJmUjZNc++hgVROV\n\tILmYPIhsb3IAX6e21se3Xzv+tcWPHMBalYjJpWalqEevb8pEuGm7gSKsnEcQHJp7\n\tYm8yxGORx9GK1yX6JRZtciGEd9u1ujaE4fmjT+wBzT7VexXbaDXTijVa9NdL5Bhs\n\t8bbF8iASpQvJR+NSAMIzPagIg6g/gSNIbJoD1spXFFaVAsez1eTYIclqFK6BdnuN\n\tXeH+1yGF+NnH3BLuc0a0rfX9rmaAOd6928xblMzQiSncjLgDm1ag==","v=1; a=rsa-sha256; c=relaxed/relaxed; d=\n\tmessagingengine.com; h=cc:content-type:date:from:in-reply-to\n\t:message-id:mime-version:references:subject:to:x-me-sender\n\t:x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=DifZS3GLTPw90t2dMC\n\tJeXau8VldxK7JylfJGeFCZZPE=; b=R5fbYF/73r9HuabPvTQzy9ztdNo92Iz2DL\n\tvAnwETfBSm8hVYpdJ0ha5y5JRmGcimVY/2oCM6N5RXqArjEet+ZRCyzQD85GkUwe\n\tTFn8TZkhLhM5hOnrWHVUvyErzKyOffmkvmnzVn/kcrgYpN5y5KVfszY5nSSevAWa\n\tL+k4gw8Oe/cUKhNB7FNyVinkeOxN4A/911w9gtspqCLXn76iMX2CtVLY6s8sKfuB\n\trPPrUuVvLDR8HapkFERxfdynQi6+tE3DyBhe8IGYmzsq/9/wBPJWcVqKbGsGUbp5\n\tyDwqF8NkjBeh1UEtnOTXzOA+nPq593G7gblIiH0jxPhb+paJHZBw=="],"X-ME-Sender":"","X-Sasl-enc":"Kati1XESNx4ig1rF0hM85tKioX8avWK3+ZrUZMFFhuGA 1504685012","From":"Hannes Frederic Sowa ","To":"\"Yang\\, Yi\" ","References":"<1503670805-31051-1-git-send-email-yi.y.yang@intel.com>\n\t<1503670805-31051-4-git-send-email-yi.y.yang@intel.com>\n\t<87wp5l7560.fsf@stressinduktion.org>\n\t<20170904023831.GA68062@cran64.bj.intel.com>\n\t<87mv6abte5.fsf@stressinduktion.org>\n\t<20170905021112.GA86057@cran64.bj.intel.com>\n\t<87vakxsaj2.fsf@stressinduktion.org>\n\t<20170905113848.GC92895@cran64.bj.intel.com>\n\t<878thtmgra.fsf@stressinduktion.org>\n\t<20170906005359.GA103260@cran64.bj.intel.com>","Date":"Wed, 06 Sep 2017 10:03:29 +0200","In-Reply-To":"<20170906005359.GA103260@cran64.bj.intel.com> (Yi Yang's message\n\tof \"Wed, 6 Sep 2017 08:53:59 +0800\")","Message-ID":"<87o9qo9ru6.fsf@stressinduktion.org>","User-Agent":"Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)","MIME-Version":"1.0","X-Spam-Status":"No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,\n\tDKIM_VALID_AU,RCVD_IN_DNSWL_LOW 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\" ,\n\t\"netdev@vger.kernel.org\" ,\n\t\"jbenc@redhat.com\" , \"e@erig.me\" ","Subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","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":1763910,"web_url":"http://patchwork.ozlabs.org/comment/1763910/","msgid":"","list_archive_url":null,"date":"2017-09-06T08:27:00","subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","submitter":{"id":68449,"url":"http://patchwork.ozlabs.org/api/people/68449/","name":"Jan Scheurich","email":"jan.scheurich@ericsson.com"},"content":"> >> Yes, I wrote that in my previous mail. I wonder why NSH context metadata\n> >> is not in tun_metadata as well?\n> >\n> > tun_metadata is tunnel metadata, GENEVE needs tunnel port, but NSH is\n> > not so, NSH can't directly use tun_metadata, for MD type 2, we need to a\n> > lot of rework on tun_metadata to make it shared between GENEVE and NSH,\n> > I don't think this can happen in near term. So tun_metadata isn't option\n> > for this now.\n> \n> Sorry, I couldn't follow you. Why can't you store the context headers in\n> tun_metadata exactly?\n> \n\nI think we mixing things. Let me try to clarify:\n\n1. NSH context metadata has end-to-end significance for the SFP. They must be part of the NSH header and cannot be transported as tunnel metadata, because transport tunnels (e.g. Geneve) only connect pairs of SFFs in the path. So we need OVS to be able to match on and set NSH context header fields, also for MD2 TLVs in the future. \n\n2. OVS today has support for matching on TLV tunnel metadata after termination of a Geneve tunnel. This infrastructure is only usable for OVS tunnel ports (like Geneve) but not for matching on TLV headers of the NSH protocol, which is not modelled as an OVS tunnel port but handled in the OpenFlow pipeline (with generic encp/decap actions to enter/terminate an NSH SFP). This was a strategic decision by the OVS community two years ago.\n\nThere is no way we can re-use the existing TLV tunnel metadata infrastructure in OVS for matching and setting NSH MD2 TLV headers. We will need to introduce a new (perhaps similar) scheme for modelling generic TLV match registers in OVS that are assigned to protocol TLVs by the controller. This is FFS.\n\nBR, Jan","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 3xnGsS4Gnxz9s9Y\n\tfor ;\n\tWed, 6 Sep 2017 18:27:08 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id 427B8A88;\n\tWed, 6 Sep 2017 08:27:05 +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 A3B0B978\n\tfor ; Wed, 6 Sep 2017 08:27:04 +0000 (UTC)","from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5B814A1\n\tfor ; Wed, 6 Sep 2017 08:27:03 +0000 (UTC)","from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63])\n\tby sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id\n\t8D.D5.22679.551BFA95; Wed, 6 Sep 2017 10:27:01 +0200 (CEST)","from ESESSMB107.ericsson.se ([169.254.7.26]) by\n\tESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0352.000; \n\tWed, 6 Sep 2017 10:27:00 +0200"],"X-Greylist":"domain auto-whitelisted by SQLgrey-1.7.6","X-AuditID":"c1b4fb30-96f7a9c000005897-0d-59afb155f447","From":"Jan Scheurich ","To":"Hannes Frederic Sowa , \"Yang, Yi\"\n\t","Thread-Topic":"[PATCH net-next v6 3/3] openvswitch: enable NSH support","Thread-Index":"AQHTJuafHqGBP9SYnEO1eAqwAUNZJaKnghOQ","Date":"Wed, 6 Sep 2017 08:27:00 +0000","Message-ID":"","References":"<1503670805-31051-1-git-send-email-yi.y.yang@intel.com>\n\t<1503670805-31051-4-git-send-email-yi.y.yang@intel.com>\n\t<87wp5l7560.fsf@stressinduktion.org>\n\t<20170904023831.GA68062@cran64.bj.intel.com>\n\t<87mv6abte5.fsf@stressinduktion.org>\n\t<20170905021112.GA86057@cran64.bj.intel.com>\n\t<87vakxsaj2.fsf@stressinduktion.org>\n\t<20170905113848.GC92895@cran64.bj.intel.com>\n\t<878thtmgra.fsf@stressinduktion.org>\n\t<20170906005359.GA103260@cran64.bj.intel.com>\n\t<87o9qo9ru6.fsf@stressinduktion.org>","In-Reply-To":"<87o9qo9ru6.fsf@stressinduktion.org>","Accept-Language":"en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","x-originating-ip":"[153.88.183.146]","MIME-Version":"1.0","X-Brightmail-Tracker":"H4sIAAAAAAAAA+NgFlrLIsWRmVeSWpSXmKPExsUyM2K7vW7oxvWRBg+b5S1eTW5gtDh6eg+z\n\txeKeE0wWmyc7W6zYdJrZ4tgCMYvfX7cxObB7HFl0kNFj8Z6XTB7Pbv5n9Hh+rYfF4/2+q2we\n\tLy6eYvH4vEkugD2KyyYlNSezLLVI3y6BK+PbixdsBY94K35/vM/awPiOq4uRk0NCwETi/d4/\n\tLF2MXBxCAkcYJda9mc4M4SxilNi3dAJQhoODTcBAYvZuB5AGEYFIifYTv9lBapgFDjNKrDw8\n\tkwUkISzgIvFo91UWiCJXiT2bF7NC2EYSX+5OA4uzCKhILLn9HyzOK+Ar8eP2QyaIZX+ZJU5N\n\t3Q+W4BQwlJi48ihYA6OAmMT3U2uYQGxmAXGJW0/mM0GcLSCxZM95ZghbVOLl43+sELaSxI8N\n\tl1gg6nUkFuz+xAZha0ssW/iaGWKxoMTJmU9YJjCKzkIydhaSlllIWmYhaVnAyLKKUbQ4tTgp\n\tN93ISC+1KDO5uDg/Ty8vtWQTIzASD275bbCD8eVzx0OMAhyMSjy8AXPXRwqxJpYVV+YeYpTg\n\tYFYS4e2fBhTiTUmsrEotyo8vKs1JLT7EKM3BoiTO67jvQoSQQHpiSWp2ampBahFMlomDU6qB\n\tMaJw48m+DPfEDJ/S7ZP8Zs5d83yuSEDlgUs618r0n2b/vaK8TU1vWvFLhXdTQjb9+3rlSXNd\n\t/lG2+PKalHdGKTuX3zrEwlG8TeSfi77TmT/JIXoaAka37rHtODc31ko5ykSl69Mlk9PWYlef\n\tWk8LjBJ5PK9oju+HtQePMSy7eFF1c5100asoLyWW4oxEQy3mouJEAHSQcJ/AAgAA","X-Spam-Status":"No, score=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED\n\tautolearn=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\" ,\n\t\"netdev@vger.kernel.org\" ,\n\t\"e@erig.me\" , \"jbenc@redhat.com\" ","Subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","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":1763960,"web_url":"http://patchwork.ozlabs.org/comment/1763960/","msgid":"<87bmmo9ngt.fsf@stressinduktion.org>","list_archive_url":null,"date":"2017-09-06T09:37:54","subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","submitter":{"id":18284,"url":"http://patchwork.ozlabs.org/api/people/18284/","name":"Hannes Frederic Sowa","email":"hannes@stressinduktion.org"},"content":"Jan Scheurich writes:\n\n>> >> Yes, I wrote that in my previous mail. I wonder why NSH context metadata\n>> >> is not in tun_metadata as well?\n>> >\n>> > tun_metadata is tunnel metadata, GENEVE needs tunnel port, but NSH is\n>> > not so, NSH can't directly use tun_metadata, for MD type 2, we need to a\n>> > lot of rework on tun_metadata to make it shared between GENEVE and NSH,\n>> > I don't think this can happen in near term. So tun_metadata isn't option\n>> > for this now.\n>> \n>> Sorry, I couldn't follow you. Why can't you store the context headers in\n>> tun_metadata exactly?\n>> \n>\n> I think we mixing things. Let me try to clarify:\n>\n> 1. NSH context metadata has end-to-end significance for the SFP. They\n> must be part of the NSH header and cannot be transported as tunnel\n> metadata, because transport tunnels (e.g. Geneve) only connect pairs\n> of SFFs in the path.\n\nNo questions asked. I am not talking about a design choice of the\nprotocol but an implementation detail of the patch.\n\n> So we need OVS to be able to match on and set NSH context header\n> fields, also for MD2 TLVs in the future.\n\nSo be it.\n\n> 2. OVS today has support for matching on TLV tunnel metadata after\n> termination of a Geneve tunnel. This infrastructure is only usable for\n> OVS tunnel ports (like Geneve) but not for matching on TLV headers of\n> the NSH protocol, which is not modelled as an OVS tunnel port but\n> handled in the OpenFlow pipeline (with generic encp/decap actions to\n> enter/terminate an NSH SFP). This was a strategic decision by the OVS\n> community two years ago.\n\nI am talking about the tun_opts field in the sw_flow_keys structure for\nthe kernel dp only.\n\n> There is no way we can re-use the existing TLV tunnel metadata\n> infrastructure in OVS for matching and setting NSH MD2 TLV headers. We\n> will need to introduce a new (perhaps similar) scheme for modelling\n> generic TLV match registers in OVS that are assigned to protocol TLVs\n> by the controller. This is FFS.\n\nThis is what I don't understand.\n\nWhy can't you just reuse the space in the struct sw_flow_key where\ngeneve would put in their metadata. There are 255 empty bytes at the\nbeginning if you don't have other tunnel metadata anyway.\n\nIf you receive packets over vxlan(gpe), tun_opts gets populated with an\nip_tunnel_key. Couldn't you use the options space in there after the\nip_tunnel_key to store the NSH context just for the sake of storing them\nsomewhere instead of adding 16 bytes to sw_flow_key?\n\nThanks,\nHannes","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=stressinduktion.org\n\theader.i=@stressinduktion.org header.b=\"Z/rDzsVf\"; \n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=messagingengine.com\n\theader.i=@messagingengine.com header.b=\"lYnAA8gr\"; \n\tdkim-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 3xnJRJ6KmLz9s8J\n\tfor ;\n\tWed, 6 Sep 2017 19:38:04 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id 48065B5A;\n\tWed, 6 Sep 2017 09:38: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 5DD07B3F\n\tfor ; Wed, 6 Sep 2017 09:38:01 +0000 (UTC)","from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com\n\t[66.111.4.25])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id BD695127\n\tfor ; Wed, 6 Sep 2017 09:38:00 +0000 (UTC)","from compute7.internal (compute7.nyi.internal [10.202.2.47])\n\tby mailout.nyi.internal (Postfix) with ESMTP id EB41520BFE;\n\tWed, 6 Sep 2017 05:37:59 -0400 (EDT)","from frontend1 ([10.202.2.160])\n\tby compute7.internal (MEProxy); Wed, 06 Sep 2017 05:37:59 -0400","from z.localhost.stressinduktion.org (unknown [217.192.177.51])\n\tby mail.messagingengine.com (Postfix) with ESMTPA id 9140E7E75E;\n\tWed, 6 Sep 2017 05:37:55 -0400 (EDT)"],"X-Greylist":"from auto-whitelisted by SQLgrey-1.7.6","DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed; d=\n\tstressinduktion.org; h=cc:content-type:date:from:in-reply-to\n\t:message-id:mime-version:references:subject:to:x-me-sender\n\t:x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=YiZIRh7gpeXmp1EvxJ\n\tKWRnkB37CaR1IWRpLAIGBcxpU=; b=Z/rDzsVfJo67E7duCTsZr1R4x4L1kr1enn\n\tfIUVI+2gKTPIOWO64xGBViYg5Diox6eeOxtPE/C+qZi6ACXIjpBn4vcisTaQb+5n\n\tHwGz+5v+yxd2vPIijMZZf/rQM4iD2huqB7liIVVH/1cYWN3R8DQaB7VMzotngNsi\n\tS886uis42ku4f/sCcfWBwzmOTsEjhh3LyDHu8DAZYaWAh/Bb4Ey/0bmN98PZnbz/\n\tgi6BZGfJIrm95tLwHjuJBwTwgXBGGyj5+tK3FmQ+BnuB2fvzp1CBEfmNxYBEwzyn\n\tAZjM2TfJGKmmDH78o36TaOz7LwI/7tij4EVj/h11DcGS52Mit3lg==","v=1; a=rsa-sha256; c=relaxed/relaxed; d=\n\tmessagingengine.com; h=cc:content-type:date:from:in-reply-to\n\t:message-id:mime-version:references:subject:to:x-me-sender\n\t:x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=YiZIRh7gpeXmp1EvxJ\n\tKWRnkB37CaR1IWRpLAIGBcxpU=; b=lYnAA8grQYesmRbOv/zanXn2jPFPqVGgZb\n\t+yXyjub+F29iobVL8suHlcYq+EGWiJf+U1NEGAeqVhRiw9p4RlwDF5aGYhJVXqam\n\tL5IG5RyQ3OVTRENGIA8roXVuhdDUTSjQ8+1E2D9z/rHcHm0ShnyLzdCUrCTQV4V/\n\tNEPFazE6riA8gRsCbtKco2kz+Vc+p/FYub6BeBZdjr04DM5diT06ZlESR3qKXH8D\n\teC5InXcS6+jhHbFKs3crxRnIfvp/FYtPyhZgLIDEVXqEMGsrnLlldxpsd6jvOUch\n\t2op4owJ1flW1YqgXfI51LbdG7TF8SJSelNYcSN6z6ZTqXCjpQ6Dg=="],"X-ME-Sender":"","X-Sasl-enc":"1hQlZEKRz72XVhcMJVVMGXUKNwhb14E6xj6elWInrj8C 1504690677","From":"Hannes Frederic Sowa ","To":"Jan Scheurich ","References":"<1503670805-31051-1-git-send-email-yi.y.yang@intel.com>\n\t<1503670805-31051-4-git-send-email-yi.y.yang@intel.com>\n\t<87wp5l7560.fsf@stressinduktion.org>\n\t<20170904023831.GA68062@cran64.bj.intel.com>\n\t<87mv6abte5.fsf@stressinduktion.org>\n\t<20170905021112.GA86057@cran64.bj.intel.com>\n\t<87vakxsaj2.fsf@stressinduktion.org>\n\t<20170905113848.GC92895@cran64.bj.intel.com>\n\t<878thtmgra.fsf@stressinduktion.org>\n\t<20170906005359.GA103260@cran64.bj.intel.com>\n\t<87o9qo9ru6.fsf@stressinduktion.org>\n\t","Date":"Wed, 06 Sep 2017 11:37:54 +0200","In-Reply-To":"\n\t(Jan Scheurich's message of \"Wed, 6 Sep 2017 08:27:00 +0000\")","Message-ID":"<87bmmo9ngt.fsf@stressinduktion.org>","User-Agent":"Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)","MIME-Version":"1.0","X-Spam-Status":"No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,\n\tDKIM_VALID_AU,RCVD_IN_DNSWL_LOW 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\" ,\n\t\"netdev@vger.kernel.org\" ,\n\t\"jbenc@redhat.com\" , \"e@erig.me\" ","Subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","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":1763969,"web_url":"http://patchwork.ozlabs.org/comment/1763969/","msgid":"","list_archive_url":null,"date":"2017-09-06T09:54:08","subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","submitter":{"id":68449,"url":"http://patchwork.ozlabs.org/api/people/68449/","name":"Jan Scheurich","email":"jan.scheurich@ericsson.com"},"content":"> > There is no way we can re-use the existing TLV tunnel metadata\n> > infrastructure in OVS for matching and setting NSH MD2 TLV headers. We\n> > will need to introduce a new (perhaps similar) scheme for modelling\n> > generic TLV match registers in OVS that are assigned to protocol TLVs\n> > by the controller. This is FFS.\n> \n> This is what I don't understand.\n> \n> Why can't you just reuse the space in the struct sw_flow_key where\n> geneve would put in their metadata. There are 255 empty bytes at the\n> beginning if you don't have other tunnel metadata anyway.\n> \n> If you receive packets over vxlan(gpe), tun_opts gets populated with an\n> ip_tunnel_key. Couldn't you use the options space in there after the\n> ip_tunnel_key to store the NSH context just for the sake of storing them\n> somewhere instead of adding 16 bytes to sw_flow_key?\n\nThere is a significant conceptual difference between tunnel metadata (copied from a popped tunnel header) and packed match fields extracted during parsing of the packets. If we'd store them in the same space in the sw_flow_key struct, we are calling for trouble.\n\nNSH is transport agnostic, it should work over Ethernet, VXLAN(GPE) and other transport tunnels. Think about an NSH packet arriving on an Geneve tunnel port. Any Geneve tunnel options have already been stored in the tun_opts metadata bytes. Now the datapath parses the NSH header and overwrites the tun_opts metadata with the NSH metadata. This would break the OVS semantics.\n\nI absolutely understand your concern about efficient space utilization in the flow struct for TLV match fields and it will be part of the design challenge for MD2 TLV support to find a good balance between memory and run-time efficiency. But that is FFS. For the four fixed size MD1 headers the decision has been to include them as additional attributes in the flow key.\n\nBR, Jan","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 3xnJpB0L0Rz9sNc\n\tfor ;\n\tWed, 6 Sep 2017 19:54:25 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id 92CCBB5E;\n\tWed, 6 Sep 2017 09:54:19 +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 35B96B4A\n\tfor ; Wed, 6 Sep 2017 09:54:18 +0000 (UTC)","from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id 98E4C127\n\tfor ; Wed, 6 Sep 2017 09:54:17 +0000 (UTC)","from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60])\n\tby sessmg22.ericsson.net (Symantec Mail Security) with SMTP id\n\t08.4B.20899.7C5CFA95; Wed, 6 Sep 2017 11:54:15 +0200 (CEST)","from ESESSMB107.ericsson.se ([169.254.7.26]) by\n\tESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0352.000; \n\tWed, 6 Sep 2017 11:54:08 +0200"],"X-Greylist":"domain auto-whitelisted by SQLgrey-1.7.6","X-AuditID":"c1b4fb3a-9e1d49c0000051a3-41-59afc5c718e4","From":"Jan Scheurich ","To":"Hannes Frederic Sowa ","Thread-Topic":"[PATCH net-next v6 3/3] openvswitch: enable NSH support","Thread-Index":"AQHTJvPQHqGBP9SYnEO1eAqwAUNZJaKnmrpQ","Date":"Wed, 6 Sep 2017 09:54:08 +0000","Message-ID":"","References":"<1503670805-31051-1-git-send-email-yi.y.yang@intel.com>\n\t<1503670805-31051-4-git-send-email-yi.y.yang@intel.com>\n\t<87wp5l7560.fsf@stressinduktion.org>\n\t<20170904023831.GA68062@cran64.bj.intel.com>\n\t<87mv6abte5.fsf@stressinduktion.org>\n\t<20170905021112.GA86057@cran64.bj.intel.com>\n\t<87vakxsaj2.fsf@stressinduktion.org>\n\t<20170905113848.GC92895@cran64.bj.intel.com>\n\t<878thtmgra.fsf@stressinduktion.org>\n\t<20170906005359.GA103260@cran64.bj.intel.com>\n\t<87o9qo9ru6.fsf@stressinduktion.org>\n\t\n\t<87bmmo9ngt.fsf@stressinduktion.org>","In-Reply-To":"<87bmmo9ngt.fsf@stressinduktion.org>","Accept-Language":"en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","x-originating-ip":"[153.88.183.20]","MIME-Version":"1.0","X-Brightmail-Tracker":"H4sIAAAAAAAAA+NgFlrNIsWRmVeSWpSXmKPExsUyM2K7je7xo+sjDX7tNrd4NbmB0eLo6T3M\n\tFot7TjBZbJ7sbLFi02lmi2MLxCx+f93G5MDucWTRQUaPxXteMnk8u/mf0eP5tR4Wj/f7rrJ5\n\tvLh4isXj8ya5APYoLpuU1JzMstQifbsErowrR9ayFEzgr/j+h72BcQJPFyMnh4SAicSi3lPs\n\tILaQwBFGiTsHubsYuYDsRYwSEy9uY+1i5OBgEzCQmL3bAaRGRMBU4uXHp+wgNcwCzxklVn66\n\tyASSEBZwkXi0+yoLRJGrxJ7Ni1khbCOJxT/nMYPYLAIqEotvfAVbxivgK9H64i4bxLIXLBJT\n\tHzWANXMKGEp0HvkG1sAoICbx/dQasAXMAuISt57MZ4K4WkBiyZ7zzBC2qMTLx/9YIWxFiavT\n\tl0PV60gs2P2JDcLWlli28DUzxGJBiZMzn7BMYBSdhWTsLCQts5C0zELSsoCRZRWjaHFqcXFu\n\tupGRXmpRZnJxcX6eXl5qySZGYBQe3PLbagfjweeOhxgFOBiVeHg9D66PFGJNLCuuzD3EKMHB\n\trCTC+/gAUIg3JbGyKrUoP76oNCe1+BCjNAeLkjivw74LEUIC6YklqdmpqQWpRTBZJg5OqQZG\n\tiQV6Kjl7V6nsYdrzJGSXruWi7VYffs4Q8Fois0x177OZvLZzrzgcWTFjQvzW7Afth7qtRZJu\n\tzcotPNsYWWIf2LTY4PiyaX2iOiui5+3Jcz2/eZmZ5qmzYk/eGNv6dJsX1GU3Kbsyq0XJOJnf\n\t59XSXvriU9UtSzNLlU8T6lbLMRntznp4SMJDiaU4I9FQi7moOBEAG2skoL4CAAA=","X-Spam-Status":"No, score=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED\n\tautolearn=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\" ,\n\t\"netdev@vger.kernel.org\" ,\n\t\"jbenc@redhat.com\" , \"e@erig.me\" ","Subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","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":1763979,"web_url":"http://patchwork.ozlabs.org/comment/1763979/","msgid":"<8760cwuou5.fsf@stressinduktion.org>","list_archive_url":null,"date":"2017-09-06T10:02:42","subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","submitter":{"id":18284,"url":"http://patchwork.ozlabs.org/api/people/18284/","name":"Hannes Frederic Sowa","email":"hannes@stressinduktion.org"},"content":"Jan Scheurich writes:\n\n>> > There is no way we can re-use the existing TLV tunnel metadata\n>> > infrastructure in OVS for matching and setting NSH MD2 TLV headers. We\n>> > will need to introduce a new (perhaps similar) scheme for modelling\n>> > generic TLV match registers in OVS that are assigned to protocol TLVs\n>> > by the controller. This is FFS.\n>> \n>> This is what I don't understand.\n>> \n>> Why can't you just reuse the space in the struct sw_flow_key where\n>> geneve would put in their metadata. There are 255 empty bytes at the\n>> beginning if you don't have other tunnel metadata anyway.\n>> \n>> If you receive packets over vxlan(gpe), tun_opts gets populated with an\n>> ip_tunnel_key. Couldn't you use the options space in there after the\n>> ip_tunnel_key to store the NSH context just for the sake of storing them\n>> somewhere instead of adding 16 bytes to sw_flow_key?\n>\n> There is a significant conceptual difference between tunnel metadata\n> (copied from a popped tunnel header) and packed match fields extracted\n> during parsing of the packets. If we'd store them in the same space in\n> the sw_flow_key struct, we are calling for trouble.\n>\n> NSH is transport agnostic, it should work over Ethernet, VXLAN(GPE)\n> and other transport tunnels. Think about an NSH packet arriving on an\n> Geneve tunnel port. Any Geneve tunnel options have already been stored\n> in the tun_opts metadata bytes. Now the datapath parses the NSH header\n> and overwrites the tun_opts metadata with the NSH metadata. This would\n> break the OVS semantics.\n\nObviously you would use key->tun_opts_len and start appending there and\nnot simply overwrite. Otherwise that would be rather silly.\n\n> I absolutely understand your concern about efficient space utilization\n> in the flow struct for TLV match fields and it will be part of the\n> design challenge for MD2 TLV support to find a good balance between\n> memory and run-time efficiency. But that is FFS. For the four fixed\n> size MD1 headers the decision has been to include them as additional\n> attributes in the flow key.\n\nOkay, then.\n\nBye,\nHannes","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=stressinduktion.org\n\theader.i=@stressinduktion.org header.b=\"MBGlGxGO\"; \n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=messagingengine.com\n\theader.i=@messagingengine.com header.b=\"WCumH4/9\"; \n\tdkim-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 3xnJzw44Ylz9s03\n\tfor ;\n\tWed, 6 Sep 2017 20:02:52 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id 0C8E29EE;\n\tWed, 6 Sep 2017 10:02: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 6CD0598A\n\tfor ; Wed, 6 Sep 2017 10:02:47 +0000 (UTC)","from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com\n\t[66.111.4.25])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id C7B6E8A\n\tfor ; Wed, 6 Sep 2017 10:02:46 +0000 (UTC)","from compute7.internal (compute7.nyi.internal [10.202.2.47])\n\tby mailout.nyi.internal (Postfix) with ESMTP id 21B0D20CE1;\n\tWed, 6 Sep 2017 06:02:46 -0400 (EDT)","from frontend2 ([10.202.2.161])\n\tby compute7.internal (MEProxy); Wed, 06 Sep 2017 06:02:46 -0400","from z.localhost.stressinduktion.org (unknown [217.192.177.51])\n\tby mail.messagingengine.com (Postfix) with ESMTPA id 2E86D249C6;\n\tWed, 6 Sep 2017 06:02:43 -0400 (EDT)"],"X-Greylist":"from auto-whitelisted by SQLgrey-1.7.6","DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed; d=\n\tstressinduktion.org; h=cc:content-type:date:from:in-reply-to\n\t:message-id:mime-version:references:subject:to:x-me-sender\n\t:x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=Ss7blPb/l3VnPZCMZC\n\tcwQEUzziofhFnqowgH431PRX0=; b=MBGlGxGOR0ZfD+gSWmRbPY/qtT3RQjb57B\n\tLM3FYWRneRFp2ea1Opk7jtFmPXjRpfXGohn3ZlHq4xhb2wElxsLoaFsDuohayMr+\n\t/wZpqdf4gXpBtMthSdWdjARmr+X5DP+C3QucEs1llDNWdyYvS59FPDZpkm+mnkxb\n\tX94UP6K48MvjGT3fUnpSYrxiVqy6Td3ilrpVl9Z0grM1HRTpLxG6wpaiurE4ok3r\n\tGuRD++w+x6uFAgIxaB1UeaA7hRoR9EX9FLWpQIgBfcGbTrtE5NHnU3Q3FCLumhAT\n\tFk/Y6aokLfK9yE3PoeIV2EnciYVOdwdnPRoWv04iSV2kqNYtfsjA==","v=1; a=rsa-sha256; c=relaxed/relaxed; d=\n\tmessagingengine.com; h=cc:content-type:date:from:in-reply-to\n\t:message-id:mime-version:references:subject:to:x-me-sender\n\t:x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=Ss7blPb/l3VnPZCMZC\n\tcwQEUzziofhFnqowgH431PRX0=; b=WCumH4/9TYXFMTMWg7phmW0JQ4RgdeMbWt\n\tsO9WVqdTdao3Knr0afIsV+0/QMI3AfGPw8ORH91V/S8GG5iab/BBms4fhp4hN+RS\n\tvu/2zPyfwYBVfr99bSakDoyqgJOK4K6fU4AcJcpSO++5o6LXaRsXa7Bx6Fti/Qm6\n\tJc14IMI2qYj+ZddwlYCpa3zP5s0EFCnyVnRza2rqmDYMQFOos6Nk4DS4BBaLyH3k\n\tri/nW1BKH7Tm5HgKhJA9Km6QosgJhbBuKv3V7y9Uyc6Q1C3Fsqr3fCSgCuuqx+p/\n\tMXnY5UM41kWfucjzTrH2Zf6AQb69dTxfB+x5klBlcpnswJ7Zw1Xw=="],"X-ME-Sender":"","X-Sasl-enc":"DNnNsyj+SAXFeSDU9hhUtIj2GpF4Hc+Jzx42pVjMIlE/ 1504692165","From":"Hannes Frederic Sowa ","To":"Jan Scheurich ","References":"<1503670805-31051-1-git-send-email-yi.y.yang@intel.com>\n\t<1503670805-31051-4-git-send-email-yi.y.yang@intel.com>\n\t<87wp5l7560.fsf@stressinduktion.org>\n\t<20170904023831.GA68062@cran64.bj.intel.com>\n\t<87mv6abte5.fsf@stressinduktion.org>\n\t<20170905021112.GA86057@cran64.bj.intel.com>\n\t<87vakxsaj2.fsf@stressinduktion.org>\n\t<20170905113848.GC92895@cran64.bj.intel.com>\n\t<878thtmgra.fsf@stressinduktion.org>\n\t<20170906005359.GA103260@cran64.bj.intel.com>\n\t<87o9qo9ru6.fsf@stressinduktion.org>\n\t\n\t<87bmmo9ngt.fsf@stressinduktion.org>\n\t","Date":"Wed, 06 Sep 2017 12:02:42 +0200","In-Reply-To":"\n\t(Jan Scheurich's message of \"Wed, 6 Sep 2017 09:54:08 +0000\")","Message-ID":"<8760cwuou5.fsf@stressinduktion.org>","User-Agent":"Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)","MIME-Version":"1.0","X-Spam-Status":"No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,\n\tDKIM_VALID_AU,RCVD_IN_DNSWL_LOW 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\" ,\n\t\"netdev@vger.kernel.org\" ,\n\t\"jbenc@redhat.com\" , \"e@erig.me\" ","Subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","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":1764020,"web_url":"http://patchwork.ozlabs.org/comment/1764020/","msgid":"<20170906110354.GA111355@cran64.bj.intel.com>","list_archive_url":null,"date":"2017-09-06T11:03:54","subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","submitter":{"id":68962,"url":"http://patchwork.ozlabs.org/api/people/68962/","name":"Yang, Yi","email":"yi.y.yang@intel.com"},"content":"On Wed, Sep 06, 2017 at 04:03:29PM +0800, Hannes Frederic Sowa wrote:\n> \"Yang, Yi\" writes:\n> >> \n> >> > If you check GENEVE implementation, tun_metadata* can be set or matched\n> >> > as any other match field.\n> >> \n> >> Yes, I wrote that in my previous mail. I wonder why NSH context metadata\n> >> is not in tun_metadata as well?\n> >\n> > tun_metadata is tunnel metadata, GENEVE needs tunnel port, but NSH is\n> > not so, NSH can't directly use tun_metadata, for MD type 2, we need to a\n> > lot of rework on tun_metadata to make it shared between GENEVE and NSH,\n> > I don't think this can happen in near term. So tun_metadata isn't option\n> > for this now.\n> \n> Sorry, I couldn't follow you. Why can't you store the context headers in\n> tun_metadata exactly?\n\ntun_metadata can work only if in_port and out_port are GENEVE tunnel\nport, it is designed specially for GENEVE, Eth+NSH can work without\nany tunnel port involved, context headers for NSH are not tunnel\nmetadata, they aren't tunnel-specific, you can't treat them as same\nthing. In addtition, tun_metadata also can be matched and set, they have\nthe same issue as you concern.\n\n> \n> [...]\n> \n> Bye,\n> Hannes","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 3xnLgf2SN3z9s76\n\tfor ;\n\tWed, 6 Sep 2017 21:18:54 +1000 (AEST)","from mail.linux-foundation.org (localhost [127.0.0.1])\n\tby mail.linuxfoundation.org (Postfix) with ESMTP id 70C2DB9E;\n\tWed, 6 Sep 2017 11:18:50 +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 4CEE2B6E\n\tfor ; Wed, 6 Sep 2017 11:18:49 +0000 (UTC)","from mga02.intel.com (mga02.intel.com [134.134.136.20])\n\tby smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5C6408A\n\tfor ; Wed, 6 Sep 2017 11:18:48 +0000 (UTC)","from fmsmga003.fm.intel.com ([10.253.24.29])\n\tby orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t06 Sep 2017 04:18:47 -0700","from unknown (HELO cran64.bj.intel.com) ([10.240.224.181])\n\tby FMSMGA003.fm.intel.com with ESMTP; 06 Sep 2017 04:18:45 -0700"],"X-Greylist":"domain auto-whitelisted by SQLgrey-1.7.6","X-ExtLoop1":"1","X-IronPort-AV":"E=Sophos;i=\"5.41,483,1498546800\"; d=\"scan'208\";a=\"897589652\"","Date":"Wed, 6 Sep 2017 19:03:54 +0800","From":"\"Yang, Yi\" ","To":"Hannes Frederic Sowa ","Message-ID":"<20170906110354.GA111355@cran64.bj.intel.com>","References":"<1503670805-31051-4-git-send-email-yi.y.yang@intel.com>\n\t<87wp5l7560.fsf@stressinduktion.org>\n\t<20170904023831.GA68062@cran64.bj.intel.com>\n\t<87mv6abte5.fsf@stressinduktion.org>\n\t<20170905021112.GA86057@cran64.bj.intel.com>\n\t<87vakxsaj2.fsf@stressinduktion.org>\n\t<20170905113848.GC92895@cran64.bj.intel.com>\n\t<878thtmgra.fsf@stressinduktion.org>\n\t<20170906005359.GA103260@cran64.bj.intel.com>\n\t<87o9qo9ru6.fsf@stressinduktion.org>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<87o9qo9ru6.fsf@stressinduktion.org>","User-Agent":"Mutt/1.5.23 (2014-03-12)","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\" ,\n\t\"netdev@vger.kernel.org\" ,\n\t\"jbenc@redhat.com\" , \"e@erig.me\" ","Subject":"Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH\n\tsupport","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"}}]