[{"id":1776439,"web_url":"http://patchwork.ozlabs.org/comment/1776439/","msgid":"<20170927174637.28654c72@griffin>","list_archive_url":null,"date":"2017-09-27T15:46:37","subject":"Re: [PATCH v2 net-next 0/2] net/sched: support tunnel options in\n\tcls_flower and act_tunnel_key","submitter":{"id":9287,"url":"http://patchwork.ozlabs.org/api/people/9287/","name":"Jiri Benc","email":"jbenc@redhat.com"},"content":"On Wed, 27 Sep 2017 10:16:32 +0200, Simon Horman wrote:\n> * Geneve\n> \n>   In the case of Geneve options are TLVs[1]. My reading is that in collect\n>   metadata mode the kernel does not appear to do anything other than pass\n>   them around as a bytestring.\n> \n>   [1] https://tools.ietf.org/html/draft-ietf-nvo3-geneve-05#section-3.5\n[...]\n> \n> Neither of the above appear to assume any structure for the data.\n\nBut that's not true. Geneve uses TLVs, you even mentioned that\nyourself. Matching on a block of TLVs as a bytestring doesn't make\nsense. The TLV fields may be in any order.\n\nWe need better matching here. Bytestring is useless for Geneve.\n\nNACK for this direction of option matching. We'd need to introduce\nmatching on TLVs sooner or later anyway and this would be just a never\nused compat cruft that we need to keep around forever.\n\n Jiri","headers":{"Return-Path":"<netdev-owner@vger.kernel.org>","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=<UNKNOWN>)","ext-mx08.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx08.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=jbenc@redhat.com"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y2Mcz54S2z9tXw\n\tfor <patchwork-incoming@ozlabs.org>;\n\tThu, 28 Sep 2017 01:46:43 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1753219AbdI0Pql (ORCPT <rfc822;patchwork-incoming@ozlabs.org>);\n\tWed, 27 Sep 2017 11:46:41 -0400","from mx1.redhat.com ([209.132.183.28]:53034 \"EHLO mx1.redhat.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1752190AbdI0Pqk (ORCPT <rfc822;netdev@vger.kernel.org>);\n\tWed, 27 Sep 2017 11:46:40 -0400","from smtp.corp.redhat.com\n\t(int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id 8EDE1C081F2C;\n\tWed, 27 Sep 2017 15:46:40 +0000 (UTC)","from griffin (ovpn-204-109.brq.redhat.com [10.40.204.109])\n\tby smtp.corp.redhat.com (Postfix) with ESMTPS id EEDD081ED8;\n\tWed, 27 Sep 2017 15:46:38 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 8EDE1C081F2C","Date":"Wed, 27 Sep 2017 17:46:37 +0200","From":"Jiri Benc <jbenc@redhat.com>","To":"Simon Horman <simon.horman@netronome.com>","Cc":"David Miller <davem@davemloft.net>, Jiri Pirko <jiri@mellanox.com>,\n\tJamal Hadi Salim <jhs@mojatatu.com>,\n\tCong Wang <xiyou.wangcong@gmail.com>, netdev@vger.kernel.org,\n\toss-drivers@netronome.com","Subject":"Re: [PATCH v2 net-next 0/2] net/sched: support tunnel options in\n\tcls_flower and act_tunnel_key","Message-ID":"<20170927174637.28654c72@griffin>","In-Reply-To":"<1506500194-17637-1-git-send-email-simon.horman@netronome.com>","References":"<1506500194-17637-1-git-send-email-simon.horman@netronome.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=US-ASCII","Content-Transfer-Encoding":"7bit","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.16","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.32]);\n\tWed, 27 Sep 2017 15:46:40 +0000 (UTC)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<netdev.vger.kernel.org>","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1777483,"web_url":"http://patchwork.ozlabs.org/comment/1777483/","msgid":"<20170929.055423.108055524887949393.davem@davemloft.net>","list_archive_url":null,"date":"2017-09-29T04:54:23","subject":"Re: [PATCH v2 net-next 0/2] net/sched: support tunnel options in\n\tcls_flower and act_tunnel_key","submitter":{"id":15,"url":"http://patchwork.ozlabs.org/api/people/15/","name":"David Miller","email":"davem@davemloft.net"},"content":"From: Simon Horman <simon.horman@netronome.com>\nDate: Wed, 27 Sep 2017 10:16:32 +0200\n\n> Users of options:\n> \n> * There are eBPF hooks to allow getting on and setting tunnel metadata:\n>   bpf_skb_set_tunnel_opt, bpf_skb_get_tunnel_opt.\n> \n> * Open vSwitch is able to match and set Geneve and VXLAN-GBP options.\n> \n> Neither of the above appear to assume any structure for the data.\n\nI really worry about this.\n\nThese metadata option blobs are internal kernel datastructure which we\ncould change at any point in time.  They are not exported to\nuserspace as a UAPI.\n\nIt's kinda OK for eBPF programs to access this stuff since they are\nexpected to cope with changes to internal data-structures.\n\nBut for anything user facing, this really doesn't work.","headers":{"Return-Path":"<netdev-owner@vger.kernel.org>","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=<UNKNOWN>)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y3Szl348Jz9t34\n\tfor <patchwork-incoming@ozlabs.org>;\n\tFri, 29 Sep 2017 20:51:47 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752096AbdI2Kvp (ORCPT <rfc822;patchwork-incoming@ozlabs.org>);\n\tFri, 29 Sep 2017 06:51:45 -0400","from shards.monkeyblade.net ([184.105.139.130]:45032 \"EHLO\n\tshards.monkeyblade.net\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751224AbdI2Kvo (ORCPT\n\t<rfc822;netdev@vger.kernel.org>); Fri, 29 Sep 2017 06:51:44 -0400","from localhost (unknown [172.58.43.23])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(Client did not present a certificate)\n\t(Authenticated sender: davem-davemloft)\n\tby shards.monkeyblade.net (Postfix) with ESMTPSA id 745701340BCA5;\n\tThu, 28 Sep 2017 21:54:27 -0700 (PDT)"],"Date":"Fri, 29 Sep 2017 05:54:23 +0100 (WEST)","Message-Id":"<20170929.055423.108055524887949393.davem@davemloft.net>","To":"simon.horman@netronome.com","Cc":"jiri@mellanox.com, jhs@mojatatu.com, xiyou.wangcong@gmail.com,\n\tnetdev@vger.kernel.org, oss-drivers@netronome.com","Subject":"Re: [PATCH v2 net-next 0/2] net/sched: support tunnel options in\n\tcls_flower and act_tunnel_key","From":"David Miller <davem@davemloft.net>","In-Reply-To":"<1506500194-17637-1-git-send-email-simon.horman@netronome.com>","References":"<1506500194-17637-1-git-send-email-simon.horman@netronome.com>","X-Mailer":"Mew version 6.7 on Emacs 25.3 / Mule 6.0 (HANACHIRUSATO)","Mime-Version":"1.0","Content-Type":"Text/Plain; charset=us-ascii","Content-Transfer-Encoding":"7bit","X-Greylist":"Sender succeeded SMTP AUTH, not delayed by\n\tmilter-greylist-4.5.12 (shards.monkeyblade.net\n\t[149.20.54.216]); Thu, 28 Sep 2017 21:54:27 -0700 (PDT)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<netdev.vger.kernel.org>","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1778191,"web_url":"http://patchwork.ozlabs.org/comment/1778191/","msgid":"<20171002075013.GA22179@netronome.com>","list_archive_url":null,"date":"2017-10-02T07:50:15","subject":"Re: [PATCH v2 net-next 0/2] net/sched: support tunnel options in\n\tcls_flower and act_tunnel_key","submitter":{"id":64714,"url":"http://patchwork.ozlabs.org/api/people/64714/","name":"Simon Horman","email":"simon.horman@netronome.com"},"content":"On Fri, Sep 29, 2017 at 05:54:23AM +0100, David Miller wrote:\n> From: Simon Horman <simon.horman@netronome.com>\n> Date: Wed, 27 Sep 2017 10:16:32 +0200\n> \n> > Users of options:\n> > \n> > * There are eBPF hooks to allow getting on and setting tunnel metadata:\n> >   bpf_skb_set_tunnel_opt, bpf_skb_get_tunnel_opt.\n> > \n> > * Open vSwitch is able to match and set Geneve and VXLAN-GBP options.\n> > \n> > Neither of the above appear to assume any structure for the data.\n> \n> I really worry about this.\n> \n> These metadata option blobs are internal kernel datastructure which we\n> could change at any point in time.  They are not exported to\n> userspace as a UAPI.\n> \n> It's kinda OK for eBPF programs to access this stuff since they are\n> expected to cope with changes to internal data-structures.\n> \n> But for anything user facing, this really doesn't work.\n\nHi Dave, Hi Jiri,\n\nthe feedback I got from Jiri is that there needs to be some exposure\nof TLVs. What I have in mind is to describe Geneve option TLVs in the\nUAPI and for the kernel - most likely cls_flower, possibly using helpers,\nto translate between that encoding and the one used internally by the kernel\n- which currently happens to be the on-the-wire format.\n\nI believe that in order to avoid per-packet overhead and at the same time\ncode complexity the TLVs should be described in-order. So matching on\nTLV-A,TLV-B,TLV-C would be a different match to TLV-C,TLV-A,TLV-B.  An\norder-independent match could be added if desired in future.\n\nThis would mean the feature is initially restricted to Geneve but could\nbe expended to offer a similar feature for other encapsulation protocols\nas the need arises.\n\nWould this address your concerns?","headers":{"Return-Path":"<netdev-owner@vger.kernel.org>","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=<UNKNOWN>)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=netronome-com.20150623.gappssmtp.com\n\theader.i=@netronome-com.20150623.gappssmtp.com\n\theader.b=\"PFc85+sD\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y5Dq36dw4z9t2V\n\tfor <patchwork-incoming@ozlabs.org>;\n\tMon,  2 Oct 2017 18:50:23 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751061AbdJBHuT (ORCPT <rfc822;patchwork-incoming@ozlabs.org>);\n\tMon, 2 Oct 2017 03:50:19 -0400","from mail-wm0-f51.google.com ([74.125.82.51]:49808 \"EHLO\n\tmail-wm0-f51.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751019AbdJBHuR (ORCPT\n\t<rfc822;netdev@vger.kernel.org>); Mon, 2 Oct 2017 03:50:17 -0400","by mail-wm0-f51.google.com with SMTP id b189so4909780wmd.4\n\tfor <netdev@vger.kernel.org>; Mon, 02 Oct 2017 00:50:17 -0700 (PDT)","from netronome.com ([217.111.208.18])\n\tby smtp.gmail.com with ESMTPSA id\n\tt15sm4876114wrb.41.2017.10.02.00.50.14\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tMon, 02 Oct 2017 00:50:16 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=netronome-com.20150623.gappssmtp.com; s=20150623;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:in-reply-to:user-agent;\n\tbh=cGLoFxwxcXiDGRXUp7Y4+cpGyczpMcZDNUJV/pARR9Y=;\n\tb=PFc85+sDiRyrSWKDc4vsa5JSIHgiMUJ2c62vuUTT9Vm2tIt4mbaPbthN0Rlht/73DJ\n\tlRDU70Z/9fFK2+9f2hRDsZw0gB83LiMG3ekw0+5agyGqTUICZAHX5aRTpfLeezQshDBJ\n\tVcWtVc21qeomHxNipn37AZvHQjtOcXGTZ+CXqCaK/8O7Hjz9dwC2q94gGMGgQQXBkDFx\n\thvcFghHE699siBI6Gv5BWHJRp47o2dwuNo6vYiwCku0paz2XmqaKhPFxlyxOYm3fy678\n\tbyDymvfAYZm5kruNY3+XyJojNb7C4GUYg2MUOl5IYoskSqL+2yVHKaVxOZQ9176My7XL\n\tGK3w==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:in-reply-to:user-agent;\n\tbh=cGLoFxwxcXiDGRXUp7Y4+cpGyczpMcZDNUJV/pARR9Y=;\n\tb=Z4+dfNND5+HHy5nuB0A0ei4Thmp7vCf3UpF7WVJXfYP0wsXo9rsqFPorkh5rysTLgl\n\teXLMPs2bTW8WiKpkvhBuNbYB36J5nfI9ReM3qYO6p6BIg2MOKfU85WhfP/AB04IFbrPM\n\txLIMsah4v+pPYPrlSJH3jyU7QmDJhoAbRUsUmCVwB6Az7AQkPgh7hGcsaiC5qB6YYDgt\n\t+PtpuEK6g4lKl1VBdj0KHoHGkNnuCsNNou6qKdrW0GziEPPFaSiHltkRp/XSbYTgEbCA\n\tjdbuk2qkLX+qjYHJXBc6D0HxMfpBtvf35n05r8U8GyQYyL/uTl8DIul9qoBa41X/rwh7\n\tVFtw==","X-Gm-Message-State":"AMCzsaVSLiKwSo8gWOE4mdjYFsYiyd8xQrg3kpC0/OhccLJT3yiC9toJ\n\txjpyK1L6i4/tlpQ1vFytucTCYg==","X-Google-Smtp-Source":"AOwi7QAXTjcm61MiWCDHr1yqi+dl8/1u3T0fUk7WYbanwhdFFbvmd/MGX1Zcc+C8uOJYza0V/JDFbQ==","X-Received":"by 10.28.63.150 with SMTP id m144mr1179215wma.141.1506930616758; \n\tMon, 02 Oct 2017 00:50:16 -0700 (PDT)","Date":"Mon, 2 Oct 2017 09:50:15 +0200","From":"Simon Horman <simon.horman@netronome.com>","To":"David Miller <davem@davemloft.net>","Cc":"jiri@mellanox.com, jhs@mojatatu.com, xiyou.wangcong@gmail.com,\n\tnetdev@vger.kernel.org, oss-drivers@netronome.com","Subject":"Re: [PATCH v2 net-next 0/2] net/sched: support tunnel options in\n\tcls_flower and act_tunnel_key","Message-ID":"<20171002075013.GA22179@netronome.com>","References":"<1506500194-17637-1-git-send-email-simon.horman@netronome.com>\n\t<20170929.055423.108055524887949393.davem@davemloft.net>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20170929.055423.108055524887949393.davem@davemloft.net>","User-Agent":"Mutt/1.5.23 (2014-03-12)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<netdev.vger.kernel.org>","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1780585,"web_url":"http://patchwork.ozlabs.org/comment/1780585/","msgid":"<20171005145130.1f9bd7c4@griffin>","list_archive_url":null,"date":"2017-10-05T12:51:30","subject":"Re: [PATCH v2 net-next 0/2] net/sched: support tunnel options in\n\tcls_flower and act_tunnel_key","submitter":{"id":9287,"url":"http://patchwork.ozlabs.org/api/people/9287/","name":"Jiri Benc","email":"jbenc@redhat.com"},"content":"On Mon, 2 Oct 2017 09:50:15 +0200, Simon Horman wrote:\n> I believe that in order to avoid per-packet overhead and at the same time\n> code complexity the TLVs should be described in-order. So matching on\n> TLV-A,TLV-B,TLV-C would be a different match to TLV-C,TLV-A,TLV-B.  An\n> order-independent match could be added if desired in future.\n\nAlthough better than the binary format, I doubt that it would be\nuseful. I can't imagine a real use case where you would want such match.\n\nInstead, what you want is a match on a particular TLV, wherever it is\nin the data. For start, we can support just a single TLV.\n\nI.e. when matching on TLV-A, all of these would match:\nTLV-A,TLV-B,TLV-C; TLV-B,TLV-A,TLV-C; TLV-B,TLV-C,TLV-A. And this one\nwon't match: TLV-B,TLV-C,TLV-D.\n\n Jiri","headers":{"Return-Path":"<netdev-owner@vger.kernel.org>","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=<UNKNOWN>)","ext-mx04.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx04.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=jbenc@redhat.com"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y7CMF1n1mz9rxj\n\tfor <patchwork-incoming@ozlabs.org>;\n\tThu,  5 Oct 2017 23:51:37 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751388AbdJEMvf (ORCPT <rfc822;patchwork-incoming@ozlabs.org>);\n\tThu, 5 Oct 2017 08:51:35 -0400","from mx1.redhat.com ([209.132.183.28]:45224 \"EHLO mx1.redhat.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751318AbdJEMve (ORCPT <rfc822;netdev@vger.kernel.org>);\n\tThu, 5 Oct 2017 08:51:34 -0400","from smtp.corp.redhat.com\n\t(int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id C69567E382;\n\tThu,  5 Oct 2017 12:51:33 +0000 (UTC)","from griffin (ovpn-204-160.brq.redhat.com [10.40.204.160])\n\tby smtp.corp.redhat.com (Postfix) with ESMTPS id 26D586362C;\n\tThu,  5 Oct 2017 12:51:31 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com C69567E382","Date":"Thu, 5 Oct 2017 14:51:30 +0200","From":"Jiri Benc <jbenc@redhat.com>","To":"Simon Horman <simon.horman@netronome.com>","Cc":"David Miller <davem@davemloft.net>, jiri@mellanox.com,\n\tjhs@mojatatu.com, xiyou.wangcong@gmail.com, netdev@vger.kernel.org,\n\toss-drivers@netronome.com","Subject":"Re: [PATCH v2 net-next 0/2] net/sched: support tunnel options in\n\tcls_flower and act_tunnel_key","Message-ID":"<20171005145130.1f9bd7c4@griffin>","In-Reply-To":"<20171002075013.GA22179@netronome.com>","References":"<1506500194-17637-1-git-send-email-simon.horman@netronome.com>\n\t<20170929.055423.108055524887949393.davem@davemloft.net>\n\t<20171002075013.GA22179@netronome.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=US-ASCII","Content-Transfer-Encoding":"7bit","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.15","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.28]);\n\tThu, 05 Oct 2017 12:51:34 +0000 (UTC)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<netdev.vger.kernel.org>","X-Mailing-List":"netdev@vger.kernel.org"}}]