[{"id":1770222,"web_url":"http://patchwork.ozlabs.org/comment/1770222/","msgid":"<87poaocb4q.fsf@stressinduktion.org>","list_archive_url":null,"date":"2017-09-18T14:52:21","subject":"Re: [PATCH net-next 5/5] tls: Add generic NIC offload\n\tinfrastructure.","submitter":{"id":18284,"url":"http://patchwork.ozlabs.org/api/people/18284/","name":"Hannes Frederic Sowa","email":"hannes@stressinduktion.org"},"content":"Ilya Lesokhin writes:\n\n> +/* We assume that the socket is already connected */\n> +static struct net_device *get_netdev_for_sock(struct sock *sk)\n> +{\n> +\tstruct inet_sock *inet = inet_sk(sk);\n> +\tstruct net_device *netdev = NULL;\n> +\n> +\tnetdev = dev_get_by_index(sock_net(sk), inet->cork.fl.flowi_oif);\n> +\n> +\treturn netdev;\n> +}\n\nThe user should be aware of that they can't migrate the socket to\nanother interface if they got hw offloaded. This is not the case for\nsoftware offload. Thus I think the user has to opt in and it shouldn't\nbe a heuristic until we can switch back to sw offload path.\n\nMaybe change flowi_oif to sk_bound_dev_if and somwhow lock it against\nfurther changes if hw tls is in use?\n\nThanks,\nHannes","headers":{"Return-Path":"","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=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=stressinduktion.org\n\theader.i=@stressinduktion.org header.b=\"RHJInhda\"; \n\tdkim=pass (2048-bit key;\n\tunprotected) header.d=messagingengine.com\n\theader.i=@messagingengine.com header.b=\"D4D/Yys5\"; \n\tdkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xwprY0L1Kz9s3w\n\tfor ;\n\tTue, 19 Sep 2017 00:52:29 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1754630AbdIROw0 (ORCPT );\n\tMon, 18 Sep 2017 10:52:26 -0400","from out1-smtp.messagingengine.com ([66.111.4.25]:55395 \"EHLO\n\tout1-smtp.messagingengine.com\" rhost-flags-OK-OK-OK-OK)\n\tby vger.kernel.org with ESMTP id S1752823AbdIROwZ (ORCPT\n\t); Mon, 18 Sep 2017 10:52:25 -0400","from compute7.internal (compute7.nyi.internal [10.202.2.47])\n\tby mailout.nyi.internal (Postfix) with ESMTP id 58583212DB;\n\tMon, 18 Sep 2017 10:52:25 -0400 (EDT)","from frontend1 ([10.202.2.160])\n\tby compute7.internal (MEProxy); Mon, 18 Sep 2017 10:52:25 -0400","from z.localhost.stressinduktion.org (unknown [217.192.177.51])\n\tby mail.messagingengine.com (Postfix) with ESMTPA id 57B097FAC3;\n\tMon, 18 Sep 2017 10:52:23 -0400 (EDT)"],"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=HMyhOqYIt6L/p/XpDN\n\tTpqvBE4YlCpGB3Su2bFtHFcwI=; b=RHJInhdakWSnW3rntlaYSCKeRX3tLuFLl1\n\tl6+71XjaiYZrHFIHmWqNjElhOCb0wt46/V79aomMMpzXVv16RcegS5c2v4cail3w\n\tXqJFiOEIv/jN35snywFilQFQo6vosne35DLnQ5tLBQgFBEkymOKEAZtKvqV8uq+f\n\t5NG0QgMFCPYU71knaNgLSMKkJ9AlSOy8XHe7tT8rOKKbRgNieAzJrIXWJd1omgkH\n\tU8dt2nv/ZcFGrEoJXjCxR9j4p4UW1ufN6c+eY7ybbi2ETFq6St6ylIJ8LNgbNwiC\n\tVmhCo62PS035I9jU5FTmJLH6CUj24998j/lWcSh6Pvzi54aD8pCA==","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=HMyhOqYIt6L/p/XpDN\n\tTpqvBE4YlCpGB3Su2bFtHFcwI=; b=D4D/Yys5GT2EzrT5EKC/QKa0Vvr2yADyFh\n\tWKIo7QvsH6n01IVFRMHGbcP5bcCBTQeLJ3vIL/htcMdK/mvsz+eQE92uE1mSwJgC\n\tHA35DDTjiMcbx7DEm03hiPfQeQFThfkujtcka2FjZLR8NnoWMFjPK9UxVqGxdDYK\n\tYycMnYIueV66exDysRHb4Vl14lPhJbWhbtUL3g/OO7zpprHttW/TEZzs12lRZB2M\n\tSo3SnDD3m9XabU6a9piddMaHdSKV/cc6NXmYMNGzOd+FJxMnOuzFQxOAZmCvRbD4\n\tnIDhFB8+y7U3DAJvgSDS10cDqg5qVgvRDuAvZjkx8NP3krVv5ryw=="],"X-ME-Sender":"","X-Sasl-enc":"DHGw15IqcqugNZNoC/vGm+xso50JosYlWi5yeNuUXaPH 1505746344","From":"Hannes Frederic Sowa ","To":"Ilya Lesokhin ","Cc":"netdev@vger.kernel.org, davem@davemloft.net, davejwatson@fb.com,\n\ttom@herbertland.com, borisp@mellanox.com, aviadye@mellanox.com,\n\tliranl@mellanox.com","Subject":"Re: [PATCH net-next 5/5] tls: Add generic NIC offload\n\tinfrastructure.","References":"<1505385988-94522-1-git-send-email-ilyal@mellanox.com>\n\t<1505385988-94522-6-git-send-email-ilyal@mellanox.com>","Date":"Mon, 18 Sep 2017 16:52:21 +0200","In-Reply-To":"<1505385988-94522-6-git-send-email-ilyal@mellanox.com> (Ilya\n\tLesokhin's message of \"Thu, 14 Sep 2017 13:46:28 +0300\")","Message-ID":"<87poaocb4q.fsf@stressinduktion.org>","User-Agent":"Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)","MIME-Version":"1.0","Content-Type":"text/plain","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1770701,"web_url":"http://patchwork.ozlabs.org/comment/1770701/","msgid":"","list_archive_url":null,"date":"2017-09-19T07:36:28","subject":"RE: [PATCH net-next 5/5] tls: Add generic NIC offload\n\tinfrastructure.","submitter":{"id":67931,"url":"http://patchwork.ozlabs.org/api/people/67931/","name":"Ilya Lesokhin","email":"ilyal@mellanox.com"},"content":"Hannes Frederic Sowa writes:\n\n> The user should be aware of that they can't migrate the socket to another\n> interface if they got hw offloaded. This is not the case for software offload.\n> Thus I think the user has to opt in and it shouldn't be a heuristic until we can\n> switch back to sw offload path.\n> \n> Maybe change flowi_oif to sk_bound_dev_if and somwhow lock it against\n> further changes if hw tls is in use?\n> \n\nI'm not sure I follow.\nWe do set sk->sk_bound_dev_if to prevent further changes.\n\nDo you recommend we enable TLS offload only if SO_BINDTODEVICE\t\nwas previously used on that socket?\nand prevent even users with CAP_NET_RAW from unbinding it?\n\nI would rather avoid requiring CAP_NET_RAW to use TLS offload. \nBut admittedly I'm not sure setting sk->sk_bound_dev_if \nwithout CAP_NET_RAW like we do is legit either.\n\nFinally, the reason we made HW offload the default is that the user\ncan use sudo ethtool -K enp0s4 tls-hw-tx-offload off to opt out of HW offload\nand we currently don't have anything equivalent for opting out of SW KTLS.\n\nThanks,\nIlya","headers":{"Return-Path":"","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=)","ozlabs.org; dkim=pass (1024-bit key;\n\tunprotected) header.d=Mellanox.com header.i=@Mellanox.com\n\theader.b=\"Humr+XeK\"; dkim-atps=neutral","spf=none (sender IP is )\n\tsmtp.mailfrom=ilyal@mellanox.com; "],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xxF7749p3z9sBZ\n\tfor ;\n\tTue, 19 Sep 2017 17:36:35 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751372AbdISHgd (ORCPT );\n\tTue, 19 Sep 2017 03:36:33 -0400","from mail-ve1eur01on0076.outbound.protection.outlook.com\n\t([104.47.1.76]:21453\n\t\"EHLO EUR01-VE1-obe.outbound.protection.outlook.com\"\n\trhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP\n\tid S1750972AbdISHgb (ORCPT );\n\tTue, 19 Sep 2017 03:36:31 -0400","from AM4PR0501MB2723.eurprd05.prod.outlook.com (10.172.215.148) by\n\tAM4PR0501MB2641.eurprd05.prod.outlook.com (10.172.215.15) with\n\tMicrosoft SMTP Server (version=TLS1_2,\n\tcipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id\n\t15.20.56.11; Tue, 19 Sep 2017 07:36:28 +0000","from AM4PR0501MB2723.eurprd05.prod.outlook.com\n\t([fe80::4c25:3ce5:e5b2:d0db]) by\n\tAM4PR0501MB2723.eurprd05.prod.outlook.com\n\t([fe80::4c25:3ce5:e5b2:d0db%17]) with mapi id 15.20.0056.016;\n\tTue, 19 Sep 2017 07:36:28 +0000"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com;\n\ts=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;\n\tbh=tMJpmsmszn+qfOzbVjKIi7fAnoAwzjyqK92yW2PjD2Y=;\n\tb=Humr+XeK2ws1/givfmhQujWyvmJP5H+I9O5aJ8zQhHpXN0rTH16w4sDYxVjjWuu/Vkfcb7fRHn87fClLdIbexIUwAVHY60+80RJIOIwfrrJFRH2yyblIp/9tXbIbBt9yLuRLjwNcHiS61yg+CW0QLzxR4LGVk0y/FW3ucKZQo/w=","From":"Ilya Lesokhin ","To":"Hannes Frederic Sowa ","CC":"\"netdev@vger.kernel.org\" ,\n\t\"davem@davemloft.net\" ,\n\t\"davejwatson@fb.com\" ,\n\t\"tom@herbertland.com\" ,\n\tBoris Pismenny ,\n\tAviad Yehezkel , Liran Liss ","Subject":"RE: [PATCH net-next 5/5] tls: Add generic NIC offload\n\tinfrastructure.","Thread-Topic":"[PATCH net-next 5/5] tls: Add generic NIC offload\n\tinfrastructure.","Thread-Index":"AQHTLUbe+Tnty7MSOEahr558nhSl2KK6wPeqgAEDx+A=","Date":"Tue, 19 Sep 2017 07:36:28 +0000","Message-ID":"","References":"<1505385988-94522-1-git-send-email-ilyal@mellanox.com>\n\t<1505385988-94522-6-git-send-email-ilyal@mellanox.com>\n\t<87poaocb4q.fsf@stressinduktion.org>","In-Reply-To":"<87poaocb4q.fsf@stressinduktion.org>","Accept-Language":"en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","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=)","ozlabs.org; dkim=pass (1024-bit key;\n\tunprotected) header.d=Mellanox.com header.i=@Mellanox.com\n\theader.b=\"Humr+XeK\"; dkim-atps=neutral","spf=none (sender IP is )\n\tsmtp.mailfrom=ilyal@mellanox.com; "],"x-originating-ip":"[193.47.165.251]","x-ms-publictraffictype":"Email","x-microsoft-exchange-diagnostics":"1; AM4PR0501MB2641;\n\t6:xBdQO2hfxfSwjmZoI3b4ldrzUh5wUpgZ4NqpB8xsyV/htEO31mY0Nt/xVqLbezIjYSMHEiTAU1DVDKDYX/Gjkt8SS8zm91Dfv/dyzeBV5H+KmPaeY9KhjdjcUaTyWFJvvjanId2qRkHjY0e9rMXdMpOz3/1eQSwuah4wBslfjZzFgrUQLeV/OCW9NtaPQnEKfqYuqUIYlvqsZbuKVP+LGdi0PhwAvU0yjBJMhYq6eJtijl7poaRo7Wu+Xh4lGMo9sMZi6nV28RtAz92f2duir6ZNj2d1xzLtWYpItyB3TqDp6iqyDG3ro0rgAinub6ECJ9dfXarmd4dEx6GbL+cCaA==;\n\t5:z6Oc4qALt7QEPNY3Y5ceXlshTr3GqDXjFC3aHpKtpwBiHNDz155Q/18yFpY7sh3SPh2BzMFCMlBrERwbpsh2Zk/Luk0/25APo2c+zKM/Yw9oq6oJlJR6RKWvjLdSa/woBTNomnw3wedZID5NsjIYLQ==;\n\t24:YE2EAHDm/DzHK0zoH++7RlsyCIKySEM8LYBFX5cZIJ1S55tx8dZGp71zcHFqBdZhVyUoJm/Wqz6Yjxh3VdzyAuiB6spQPXTvhCWi+TTm7N4=;\n\t7:BBvCfwiPrxD1G5yr9XJmtzudUZF903ny95FSNiqdzypbWQ2Lf+Bc5FBofFcKvQMOyPcbd+fmPk36A5m/b8ATmikQ1g7Wxq9I5W0zUkWOyGJnqKDq33d0+RvneeoMLXigSQw2Ccz6N9Nk0FenSdqrtkOhqti1GIWlH/ReVtW6VTGxUfGX2lYNxN1I9E1n26JmStjlF7q1I+zZXw6PBZ8E+SBXlOjXpAUHCVkLBHovPd4=","x-ms-exchange-antispam-srfa-diagnostics":"SSOS;","x-ms-office365-filtering-correlation-id":"c29bff6c-49e5-4efa-af10-08d4ff3123e3","x-ms-office365-filtering-ht":"Tenant","x-microsoft-antispam":"UriScan:; BCL:0; PCL:0;\n\tRULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);\n\tSRVR:AM4PR0501MB2641; ","x-ms-traffictypediagnostic":"AM4PR0501MB2641:","x-exchange-antispam-report-test":"UriScan:;","x-microsoft-antispam-prvs":"","x-exchange-antispam-report-cfa-test":"BCL:0; PCL:0;\n\tRULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123558100)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);\n\tSRVR:AM4PR0501MB2641; BCL:0; PCL:0;\n\tRULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);\n\tSRVR:AM4PR0501MB2641; ","x-forefront-prvs":"04359FAD81","x-forefront-antispam-report":"SFV:NSPM;\n\tSFS:(10009020)(6009001)(376002)(346002)(189002)(199003)(14454004)(316002)(575784001)(97736004)(305945005)(74316002)(7736002)(6916009)(7696004)(6506006)(6436002)(5660300001)(86362001)(3660700001)(3280700002)(229853002)(2906002)(2950100002)(5250100002)(76176999)(54356999)(25786009)(8676002)(50986999)(4326008)(105586002)(53936002)(81156014)(81166006)(54906002)(106356001)(2900100001)(66066001)(478600001)(3846002)(99286003)(101416001)(8936002)(189998001)(9686003)(55016002)(102836003)(6116002)(33656002)(107886003)(6246003)(68736007)(41533002);\n\tDIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0501MB2641;\n\tH:AM4PR0501MB2723.eurprd05.prod.outlook.com; FPR:; SPF:None;\n\tPTR:InfoNoRecords; MX:1; A:1; LANG:en; ","received-spf":"None (protection.outlook.com: mellanox.com does not designate\n\tpermitted sender hosts)","spamdiagnosticoutput":"1:99","spamdiagnosticmetadata":"NSPM","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"quoted-printable","MIME-Version":"1.0","X-OriginatorOrg":"Mellanox.com","X-MS-Exchange-CrossTenant-originalarrivaltime":"19 Sep 2017 07:36:28.5593\n\t(UTC)","X-MS-Exchange-CrossTenant-fromentityheader":"Hosted","X-MS-Exchange-CrossTenant-id":"a652971c-7d2e-4d9b-a6a4-d149256f461b","X-MS-Exchange-Transport-CrossTenantHeadersStamped":"AM4PR0501MB2641","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1770793,"web_url":"http://patchwork.ozlabs.org/comment/1770793/","msgid":"<87wp4vt4aa.fsf@stressinduktion.org>","list_archive_url":null,"date":"2017-09-19T09:40:29","subject":"Re: [PATCH net-next 5/5] tls: Add generic NIC offload\n\tinfrastructure.","submitter":{"id":18284,"url":"http://patchwork.ozlabs.org/api/people/18284/","name":"Hannes Frederic Sowa","email":"hannes@stressinduktion.org"},"content":"Hello,\n\nIlya Lesokhin writes:\n\n> Hannes Frederic Sowa writes:\n>\n>> The user should be aware of that they can't migrate the socket to another\n>> interface if they got hw offloaded. This is not the case for software offload.\n>> Thus I think the user has to opt in and it shouldn't be a heuristic until we can\n>> switch back to sw offload path.\n>> \n>> Maybe change flowi_oif to sk_bound_dev_if and somwhow lock it against\n>> further changes if hw tls is in use?\n>> \n>\n> I'm not sure I follow.\n> We do set sk->sk_bound_dev_if to prevent further changes.\n>\n> Do you recommend we enable TLS offload only if SO_BINDTODEVICE\t\n> was previously used on that socket?\n> and prevent even users with CAP_NET_RAW from unbinding it?\n>\n> I would rather avoid requiring CAP_NET_RAW to use TLS offload. \n> But admittedly I'm not sure setting sk->sk_bound_dev_if \n> without CAP_NET_RAW like we do is legit either.\n>\n> Finally, the reason we made HW offload the default is that the user\n> can use sudo ethtool -K enp0s4 tls-hw-tx-offload off to opt out of HW offload\n> and we currently don't have anything equivalent for opting out of SW KTLS.\n\nIMHO the decision if a TCP flow should be bounded to hw and thus never\npush traffic to another interface should a decision the administrator\nand the application should opt in. You might have your management\napplication which is accessible over multiple interfaces and your\nproduction application which might want to use hw offloaded tls. Thus I\ndon't think only a single ethtool knob will do it.\n\nI agree that SO_BINDTODEVICE is bad for this use case. First, the\nCAP_NET_RAW limitation seems annoying and we don't want to enforce TLS\napps to have this capability. Second, the user space application doesn't\ncare which interface it should talk to (maybe?) but leave the routing\ndecision to the kernel and just opt in to TLS. SO_BINDTODEVICE doesn't\nallow this.\n\nsk_bound_dev_if can be rebound later with CAP_NET_RAW privileges, will\nthis be a problem?\n\nHave you thought how the user space will configure the various\noffloading features (sw, hw, none)? Will it in e.g. OpenSSL be part of\nthe Cipher Spec or will there be new functions around SSL_CTX to do so?\n\nMaybe an enhancement of the TLS_TX setsockopt with a boolean for hw\noffload is a solution?\n\nAnother question:\n\nHow is the dependency management done between socket layer and driver\nlayer? It seems a bit cyclic but judging from this code you don't hold\nreferences to the device (dev_hold) (which is good, you don't want to\nhave users creating refs to devices). OTOH you somehow need to match\nsockets from the device layer up to the socket. Will those be reference\ncounted or does that work without?\n\nThanks,\nHannes","headers":{"Return-Path":"","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=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=stressinduktion.org\n\theader.i=@stressinduktion.org header.b=\"sdyOboOt\"; \n\tdkim=pass (2048-bit key;\n\tunprotected) header.d=messagingengine.com\n\theader.i=@messagingengine.com header.b=\"I+bHqui9\"; \n\tdkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xxHtD4ljhz9s7F\n\tfor ;\n\tTue, 19 Sep 2017 19:40:36 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751561AbdISJke (ORCPT );\n\tTue, 19 Sep 2017 05:40:34 -0400","from out1-smtp.messagingengine.com ([66.111.4.25]:60069 \"EHLO\n\tout1-smtp.messagingengine.com\" rhost-flags-OK-OK-OK-OK)\n\tby vger.kernel.org with ESMTP id S1751024AbdISJkd (ORCPT\n\t); Tue, 19 Sep 2017 05:40:33 -0400","from compute7.internal (compute7.nyi.internal [10.202.2.47])\n\tby mailout.nyi.internal (Postfix) with ESMTP id 9E97D20DD1;\n\tTue, 19 Sep 2017 05:40:32 -0400 (EDT)","from frontend2 ([10.202.2.161])\n\tby compute7.internal (MEProxy); Tue, 19 Sep 2017 05:40:32 -0400","from z.localhost.stressinduktion.org (unknown [217.192.177.51])\n\tby mail.messagingengine.com (Postfix) with ESMTPA id AB56C244C7;\n\tTue, 19 Sep 2017 05:40:30 -0400 (EDT)"],"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=NOFHhXzo5trZZCsCko\n\turYPmUZscBF3sCZaI2r2x0dao=; b=sdyOboOtAc9qf6rBwYTxlhW32xMC6clLE7\n\t3LbAD5wpEyBbQU4TnZLHuI9SLe2KqTUYCMO4zLpFc6jsYJzbG3BPgZ8LYK6dBFv7\n\t6DHll+g5yVUZwCz4BcSeidSHHm1C4Nb0ZwbBXGy0ssBQoEmTLr0Bq6zi/5geK6pm\n\tyBLqvjJ+b7CmGN5eOe1naW0R8aUnptarYUTmxqim8e6bi9XqjyHUZ/IZ9NwrzXiI\n\tdWoafSmKwGfELd7qJ7U2aBSAxNrfKd1SpE+Q1va3gFb3rfwrj4Vi7yLiomJ9BHu9\n\tCzmMSeRnmiECU4FwE9YYlisZ00QkUwIU/cVUdxS1e4VTmn/rfkyQ==","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=NOFHhXzo5trZZCsCko\n\turYPmUZscBF3sCZaI2r2x0dao=; b=I+bHqui95DBWn4Nbi+t011E9/ncN5jzzJA\n\t5Hfn2dSeokF1WMp9Vf8RqNRF8jh+JpfLzQk89KLi+89cuy6GBE/65RLNWb/cL6uc\n\tMyA81JkTJ4lsE5AJOYR2oCz6/pNkA2C39T1vCNsBfEfwJhkacIOYy3eGvfuOTaQQ\n\tOstW7zXV4rP7YxXDTr+JY7YDfkVnv2tduYXlU753ZaQBedUkNtE1RC6Nmh7SDzzP\n\t3XT0dv+R4w9FvzDhlHx8nzrC+dQJcPe/pJJN69NMsXTaFHMdvAewRoeKoL9Bf8Bf\n\tKDh8RM0TkQWk/eH6o3TScG/BdtnB0ENWDJSM96yNGl68Ie1lRA6w=="],"X-ME-Sender":"","X-Sasl-enc":"NQT4XPi/hKDJnE1GSTS3msw/N6+aQ5mFjBvHn2eGVOM9 1505814032","From":"Hannes Frederic Sowa ","To":"Ilya Lesokhin ","Cc":"\"netdev\\@vger.kernel.org\" ,\n\t\"davem\\@davemloft.net\" ,\n\t\"davejwatson\\@fb.com\" ,\n\t\"tom\\@herbertland.com\" ,\n\tBoris Pismenny ,\n\tAviad Yehezkel , Liran Liss ","Subject":"Re: [PATCH net-next 5/5] tls: Add generic NIC offload\n\tinfrastructure.","References":"<1505385988-94522-1-git-send-email-ilyal@mellanox.com>\n\t<1505385988-94522-6-git-send-email-ilyal@mellanox.com>\n\t<87poaocb4q.fsf@stressinduktion.org>\n\t","Date":"Tue, 19 Sep 2017 11:40:29 +0200","In-Reply-To":"\n\t(Ilya Lesokhin's message of \"Tue, 19 Sep 2017 07:36:28 +0000\")","Message-ID":"<87wp4vt4aa.fsf@stressinduktion.org>","User-Agent":"Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)","MIME-Version":"1.0","Content-Type":"text/plain","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1771054,"web_url":"http://patchwork.ozlabs.org/comment/1771054/","msgid":"","list_archive_url":null,"date":"2017-09-19T14:02:33","subject":"RE: [PATCH net-next 5/5] tls: Add generic NIC offload\n\tinfrastructure.","submitter":{"id":68344,"url":"http://patchwork.ozlabs.org/api/people/68344/","name":"Boris Pismenny","email":"borisp@mellanox.com"},"content":"Hello,\n\nHannes Frederic Sowa writes:\n> Hello,\n> \n> Ilya Lesokhin writes:\n> \n> > Hannes Frederic Sowa writes:\n> >\n> >> The user should be aware of that they can't migrate the socket to\n> >> another interface if they got hw offloaded. This is not the case for\n> software offload.\n> >> Thus I think the user has to opt in and it shouldn't be a heuristic\n> >> until we can switch back to sw offload path.\n> >>\n> >> Maybe change flowi_oif to sk_bound_dev_if and somwhow lock it against\n> >> further changes if hw tls is in use?\n> >>\n> >\n> > I'm not sure I follow.\n> > We do set sk->sk_bound_dev_if to prevent further changes.\n> >\n> > Do you recommend we enable TLS offload only if SO_BINDTODEVICE\n> > was previously used on that socket?\n> > and prevent even users with CAP_NET_RAW from unbinding it?\n> >\n> > I would rather avoid requiring CAP_NET_RAW to use TLS offload.\n> > But admittedly I'm not sure setting sk->sk_bound_dev_if without\n> > CAP_NET_RAW like we do is legit either.\n> >\n> > Finally, the reason we made HW offload the default is that the user\n> > can use sudo ethtool -K enp0s4 tls-hw-tx-offload off to opt out of HW\n> > offload and we currently don't have anything equivalent for opting out of\n> SW KTLS.\n> \n> IMHO the decision if a TCP flow should be bounded to hw and thus never\n> push traffic to another interface should a decision the administrator and the\n> application should opt in. You might have your management application\n> which is accessible over multiple interfaces and your production application\n> which might want to use hw offloaded tls. Thus I don't think only a single\n> ethtool knob will do it.\n\nIMO the configuration knob should be at the kTLS level and not at the\nHW vs. SW level. The management application shouldn't be using kTLS.\nI'd like to view TLS offload similarly to LSO. The default is opt-in if\npossible, and the Kernel decides that based on device capabilities.\n\n> \n> I agree that SO_BINDTODEVICE is bad for this use case. First, the\n> CAP_NET_RAW limitation seems annoying and we don't want to enforce TLS\n> apps to have this capability. Second, the user space application doesn't care\n> which interface it should talk to (maybe?) but leave the routing decision to\n> the kernel and just opt in to TLS. SO_BINDTODEVICE doesn't allow this.\n> \n> sk_bound_dev_if can be rebound later with CAP_NET_RAW privileges, will\n> this be a problem?\n\nYes it is a problem and we have some ideas for a software fallback that should\ncatch this. \n\nIs the software fallback a prerequisite for kTLS offload in Kernel?\n\n> \n> Have you thought how the user space will configure the various offloading\n> features (sw, hw, none)? Will it in e.g. OpenSSL be part of the Cipher Spec or\n> will there be new functions around SSL_CTX to do so?\n> \n> Maybe an enhancement of the TLS_TX setsockopt with a boolean for hw\n> offload is a solution?\n\nYes, we think that OpenSSL should first configure whether it complies with\nkTLS support. Next, we thought of using an environment variable to control\nkTLS globally in OpenSSL as follows:\n1. only software kTLS\n2. only hardware kTLS - no fallback to software.\n3. Try to use hardware kTLS and if it isn't supported fallback to software kTLS.\n\nThe above is something we plan for the future, assuming that kTLS wouldn't fit for\nall use-cases. What do you think?\n\nIf you'd like to have more fine-grained control of kTLS, e.g. per socket,\nthen the application would need to be modified to configure that,\nwhich is something we try to avoid.\n\n> \n> Another question:\n> \n> How is the dependency management done between socket layer and driver\n> layer? It seems a bit cyclic but judging from this code you don't hold\n> references to the device (dev_hold) (which is good, you don't want to have\n> users creating refs to devices). OTOH you somehow need to match sockets\n> from the device layer up to the socket. Will those be reference counted or\n> does that work without?\n\nNot sure I follow your question.\nWe use the socket from the device layer through the SKB that carries it,\nso I think it should work without.\nWe don't attempt to perform a socket lookup or anything of this sort.","headers":{"Return-Path":"","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=)","ozlabs.org; dkim=pass (1024-bit key;\n\tunprotected) header.d=Mellanox.com header.i=@Mellanox.com\n\theader.b=\"ZPNcICxT\"; dkim-atps=neutral","spf=none (sender IP is )\n\tsmtp.mailfrom=borisp@mellanox.com; "],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xxPhb2stwz9s7c\n\tfor ;\n\tWed, 20 Sep 2017 00:02:39 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751370AbdISOCh (ORCPT );\n\tTue, 19 Sep 2017 10:02:37 -0400","from mail-db5eur01on0047.outbound.protection.outlook.com\n\t([104.47.2.47]:43264\n\t\"EHLO EUR01-DB5-obe.outbound.protection.outlook.com\"\n\trhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP\n\tid S1750822AbdISOCg (ORCPT );\n\tTue, 19 Sep 2017 10:02:36 -0400","from DB6PR05MB3176.eurprd05.prod.outlook.com (10.170.221.26) by\n\tDB6PR05MB3352.eurprd05.prod.outlook.com (10.170.222.22) with\n\tMicrosoft SMTP Server (version=TLS1_2,\n\tcipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id\n\t15.20.56.11; Tue, 19 Sep 2017 14:02:33 +0000","from DB6PR05MB3176.eurprd05.prod.outlook.com\n\t([fe80::6950:5fb1:cff1:35b7]) by\n\tDB6PR05MB3176.eurprd05.prod.outlook.com\n\t([fe80::6950:5fb1:cff1:35b7%13]) with mapi id 15.20.0056.016;\n\tTue, 19 Sep 2017 14:02:33 +0000"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com;\n\ts=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;\n\tbh=V/6FH17RTf+QHyPZkOszJ3vCd2DKHLWda6D7dkTRQ20=;\n\tb=ZPNcICxTqdsCN4os31XQNVhJfHTaEX4NM8D1SGAuFAdClI8DdJB/KHAGHnxZserjFAtP2p9PUBktuQzy8thZoUB0VsQ70wW3YwaOVp0GQYg/cbi+yly9JeDSqdiC/kw4nE97R+7cm3d/kjG0fteZ7QswtsX03AvXX3ovxhOJDIg=","From":"Boris Pismenny ","To":"Hannes Frederic Sowa ,\n\tIlya Lesokhin ","CC":"\"netdev@vger.kernel.org\" ,\n\t\"davem@davemloft.net\" ,\n\t\"davejwatson@fb.com\" ,\n\t\"tom@herbertland.com\" ,\n\tAviad Yehezkel , Liran Liss ","Subject":"RE: [PATCH net-next 5/5] tls: Add generic NIC offload\n\tinfrastructure.","Thread-Topic":"[PATCH net-next 5/5] tls: Add generic NIC offload\n\tinfrastructure.","Thread-Index":"AQHTLUbx241xnd3ej0qYAkwdmNu0a6K6wPasgAEYfgCAACKuU4AAPq0A","Date":"Tue, 19 Sep 2017 14:02:33 +0000","Message-ID":"","References":"<1505385988-94522-1-git-send-email-ilyal@mellanox.com>\n\t<1505385988-94522-6-git-send-email-ilyal@mellanox.com>\n\t<87poaocb4q.fsf@stressinduktion.org>\n\t\n\t<87wp4vt4aa.fsf@stressinduktion.org>","In-Reply-To":"<87wp4vt4aa.fsf@stressinduktion.org>","Accept-Language":"en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","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=)","ozlabs.org; dkim=pass (1024-bit key;\n\tunprotected) header.d=Mellanox.com header.i=@Mellanox.com\n\theader.b=\"ZPNcICxT\"; dkim-atps=neutral","spf=none (sender IP is )\n\tsmtp.mailfrom=borisp@mellanox.com; "],"x-originating-ip":"[37.142.231.231]","x-ms-publictraffictype":"Email","x-microsoft-exchange-diagnostics":"1; DB6PR05MB3352;\n\t6:r57qnLGC2k70NDB0snu08Fey4xubRsBHbvHk49JAHdjS/l6rF96JVm6uIvYhBiyuFwtcAZNGvJaV5BxAh+yoCeQPnnhLDRHItrD4/kNEoqv7u74PYDtyiB0dkO/XXdsWvgJMFWGIj4CyVq3Mq7Rnl5aLUx+dAa485g6xhxkUG6WOvhglvGvMtpZUhCfE1s8Ulztjufwsv7SNaCF0BbaFupCDkthCDV09fEc3gm6T7zTww61fKpzWUtWD5y8HdjkWOWvXefYwx5s21BdASCvsGOCC5PUpK2jAbxKUunY2V4bsExC2VTDvO+L6WnlzSrwcCouy9wNEBpRUtMyece7xGg==;\n\t5:eOtkEEJBPIuQadc5ZFm13ZQMXbogGHu2IVyx7yYue2iUZqFy11/M/s2AkazXBC8TRptneed3nKTmO1qmveVAZFMo5PW584wmtn/hCrBRMecrLO36SOg+iav527NpvUJbDi2Xe9vHV1W/yKJbljlAQg==;\n\t24:olkkF6xMPDce8pBlZYZbTLQaMRJzcGIJfplSLudGkFMKhjnkKlTRKfb2pRQBejmWl/NfFy5wbYaq3a5ZJ7uLyvtRixNz7Y1O9XsBZcT6vKM=;\n\t7:xqtFq8n3vLilL51lawqMI/pi18Tlu+wIJLwXYFDvfIxhv7ipkRpNLwrA7NGU/FAQ8cFilw/5Zh+Le4Ig+M4t61lAcoQdo/zCGbOETUSDLwbwGV/wfYL+rxXm6hhI32gECs47iwv227c5B7kWsfmGbE4kNm5SHoosOyJo5cPUur6fuERjaPypUjK96/atntZWdGFEYH045D3QOrW6HMDrDPIaluXsgmYGCPvSbzAU054=","x-ms-exchange-antispam-srfa-diagnostics":"SSOS;","x-ms-office365-filtering-correlation-id":"ac0da896-60be-4394-04c4-08d4ff671374","x-ms-office365-filtering-ht":"Tenant","x-microsoft-antispam":"UriScan:; BCL:0; PCL:0;\n\tRULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);\n\tSRVR:DB6PR05MB3352; ","x-ms-traffictypediagnostic":"DB6PR05MB3352:","x-exchange-antispam-report-test":"UriScan:;","x-microsoft-antispam-prvs":"","x-exchange-antispam-report-cfa-test":"BCL:0; PCL:0;\n\tRULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(6055026)(6041248)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123562025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);\n\tSRVR:DB6PR05MB3352; BCL:0; PCL:0;\n\tRULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);\n\tSRVR:DB6PR05MB3352; ","x-forefront-prvs":"04359FAD81","x-forefront-antispam-report":"SFV:NSPM;\n\tSFS:(10009020)(6009001)(346002)(376002)(39860400002)(76104003)(199003)(189002)(55016002)(53936002)(101416001)(5660300001)(102836003)(6246003)(189998001)(68736007)(50986999)(54356999)(3846002)(76176999)(6116002)(107886003)(33656002)(2900100001)(478600001)(99286003)(9686003)(7696004)(2906002)(66066001)(25786009)(8936002)(6436002)(106356001)(575784001)(4326008)(3280700002)(81156014)(81166006)(105586002)(305945005)(86362001)(93886005)(97736004)(74316002)(5250100002)(3660700001)(229853002)(14454004)(8676002)(316002)(7736002)(2950100002)(6506006)(6636002)(110136005)(54906002)(41533002);\n\tDIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR05MB3352;\n\tH:DB6PR05MB3176.eurprd05.prod.outlook.com; FPR:; SPF:None;\n\tPTR:InfoNoRecords; A:1; MX:1; LANG:en; ","received-spf":"None (protection.outlook.com: mellanox.com does not designate\n\tpermitted sender hosts)","spamdiagnosticoutput":"1:99","spamdiagnosticmetadata":"NSPM","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"quoted-printable","MIME-Version":"1.0","X-OriginatorOrg":"Mellanox.com","X-MS-Exchange-CrossTenant-originalarrivaltime":"19 Sep 2017 14:02:33.8698\n\t(UTC)","X-MS-Exchange-CrossTenant-fromentityheader":"Hosted","X-MS-Exchange-CrossTenant-id":"a652971c-7d2e-4d9b-a6a4-d149256f461b","X-MS-Exchange-Transport-CrossTenantHeadersStamped":"DB6PR05MB3352","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1771975,"web_url":"http://patchwork.ozlabs.org/comment/1771975/","msgid":"<87zi9pbdtu.fsf@stressinduktion.org>","list_archive_url":null,"date":"2017-09-20T15:16:13","subject":"Re: [PATCH net-next 5/5] tls: Add generic NIC offload\n\tinfrastructure.","submitter":{"id":18284,"url":"http://patchwork.ozlabs.org/api/people/18284/","name":"Hannes Frederic Sowa","email":"hannes@stressinduktion.org"},"content":"Hello,\n\nBoris Pismenny writes:\n\n> Hello,\n>\n> Hannes Frederic Sowa writes:\n>> Hello,\n>> \n>> Ilya Lesokhin writes:\n>> \n>> > Hannes Frederic Sowa writes:\n>> >\n>> >> The user should be aware of that they can't migrate the socket to\n>> >> another interface if they got hw offloaded. This is not the case for\n>> software offload.\n>> >> Thus I think the user has to opt in and it shouldn't be a heuristic\n>> >> until we can switch back to sw offload path.\n>> >>\n>> >> Maybe change flowi_oif to sk_bound_dev_if and somwhow lock it against\n>> >> further changes if hw tls is in use?\n>> >>\n>> >\n>> > I'm not sure I follow.\n>> > We do set sk->sk_bound_dev_if to prevent further changes.\n>> >\n>> > Do you recommend we enable TLS offload only if SO_BINDTODEVICE\n>> > was previously used on that socket?\n>> > and prevent even users with CAP_NET_RAW from unbinding it?\n>> >\n>> > I would rather avoid requiring CAP_NET_RAW to use TLS offload.\n>> > But admittedly I'm not sure setting sk->sk_bound_dev_if without\n>> > CAP_NET_RAW like we do is legit either.\n>> >\n>> > Finally, the reason we made HW offload the default is that the user\n>> > can use sudo ethtool -K enp0s4 tls-hw-tx-offload off to opt out of HW\n>> > offload and we currently don't have anything equivalent for opting out of\n>> SW KTLS.\n>> \n>> IMHO the decision if a TCP flow should be bounded to hw and thus never\n>> push traffic to another interface should a decision the administrator and the\n>> application should opt in. You might have your management application\n>> which is accessible over multiple interfaces and your production application\n>> which might want to use hw offloaded tls. Thus I don't think only a single\n>> ethtool knob will do it.\n>\n> IMO the configuration knob should be at the kTLS level and not at the\n> HW vs. SW level. The management application shouldn't be using kTLS.\n> I'd like to view TLS offload similarly to LSO. The default is opt-in if\n> possible, and the Kernel decides that based on device capabilities.\n>\n>> \n>> I agree that SO_BINDTODEVICE is bad for this use case. First, the\n>> CAP_NET_RAW limitation seems annoying and we don't want to enforce TLS\n>> apps to have this capability. Second, the user space application doesn't care\n>> which interface it should talk to (maybe?) but leave the routing decision to\n>> the kernel and just opt in to TLS. SO_BINDTODEVICE doesn't allow this.\n>> \n>> sk_bound_dev_if can be rebound later with CAP_NET_RAW privileges, will\n>> this be a problem?\n>\n> Yes it is a problem and we have some ideas for a software fallback that should\n> catch this. \n\nOk.\n\n> Is the software fallback a prerequisite for kTLS offload in Kernel?\n\nI don't know. I would assume yes because it will change how uAPI will\nlook like?\n\n>> \n>> Have you thought how the user space will configure the various offloading\n>> features (sw, hw, none)? Will it in e.g. OpenSSL be part of the Cipher Spec or\n>> will there be new functions around SSL_CTX to do so?\n>> \n>> Maybe an enhancement of the TLS_TX setsockopt with a boolean for hw\n>> offload is a solution?\n>\n> Yes, we think that OpenSSL should first configure whether it complies with\n> kTLS support. Next, we thought of using an environment variable to control\n> kTLS globally in OpenSSL as follows:\n\n0. no kernel tls at all but use e.g. OpenSSL crypto code.\n\n> 1. only software kTLS\n> 2. only hardware kTLS - no fallback to software.\n> 3. Try to use hardware kTLS and if it isn't supported fallback to\n> software kTLS.\n\nHmm, environment variable and global control contradicts itself. ;)\n\nIn some form or another there is a need to have all options for\ndebugging. I also wonder if it makes sense to disable ktls based on\nreordering and fast path vs. slow path hit ratio. But that is something\nto think about later.\n\n> The above is something we plan for the future, assuming that kTLS\n> wouldn't fit for all use-cases. What do you think?\n>\n> If you'd like to have more fine-grained control of kTLS, e.g. per socket,\n> then the application would need to be modified to configure that,\n> which is something we try to avoid.\n\nThat is why I proposed signaling over ciphers(1) for openssl. If you\ne.g. look at apache/mod_ssl, they loop the cipher list from the\nconfiguration file directly to OpenSSL. Same for a lot of other web\nservers, nginx etc. Thus you just need to modify openssl and don't need\nto touch the users of the library.\n\nE.g. in Fedora/RHEL the crypto libs load a default cipher list from\n/etc/crypto-policies/, which you can update centrally with\nupdate-crypto-policies. Maybe the kTLS switches fit nicely in there?\n\nFor that to do, OpenSSL needs still to have more fine grain control over\nwhich kTLS sw/hw to use, right?\n\n>> \n>> Another question:\n>> \n>> How is the dependency management done between socket layer and driver\n>> layer? It seems a bit cyclic but judging from this code you don't hold\n>> references to the device (dev_hold) (which is good, you don't want to have\n>> users creating refs to devices). OTOH you somehow need to match sockets\n>> from the device layer up to the socket. Will those be reference counted or\n>> does that work without?\n>\n> Not sure I follow your question.\n> We use the socket from the device layer through the SKB that carries it,\n> so I think it should work without.\n> We don't attempt to perform a socket lookup or anything of this sort.\n\nThe socket from skb is only valid as long as you have the skb. Basically\nthe question is: do you ever increase the ref counter of sockets from\nthe device drivers?\n\nThanks,\nHannes","headers":{"Return-Path":"","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=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=stressinduktion.org\n\theader.i=@stressinduktion.org header.b=\"ESaZ680i\"; \n\tdkim=pass (2048-bit key;\n\tunprotected) header.d=messagingengine.com\n\theader.i=@messagingengine.com header.b=\"pSpv/8aS\"; \n\tdkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xy3H94Skzz9s78\n\tfor ;\n\tThu, 21 Sep 2017 01:16:21 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751842AbdITPQT (ORCPT );\n\tWed, 20 Sep 2017 11:16:19 -0400","from out1-smtp.messagingengine.com ([66.111.4.25]:53089 \"EHLO\n\tout1-smtp.messagingengine.com\" rhost-flags-OK-OK-OK-OK)\n\tby vger.kernel.org with ESMTP id S1751826AbdITPQS (ORCPT\n\t); Wed, 20 Sep 2017 11:16:18 -0400","from compute7.internal (compute7.nyi.internal [10.202.2.47])\n\tby mailout.nyi.internal (Postfix) with ESMTP id CA5A920EDC;\n\tWed, 20 Sep 2017 11:16:17 -0400 (EDT)","from frontend1 ([10.202.2.160])\n\tby compute7.internal (MEProxy); Wed, 20 Sep 2017 11:16:17 -0400","from z.localhost.stressinduktion.org (unknown [217.192.177.51])\n\tby mail.messagingengine.com (Postfix) with ESMTPA id 966707E202;\n\tWed, 20 Sep 2017 11:16:15 -0400 (EDT)"],"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=oPYVldZIZZg4YYVuXf\n\thE/xTIJhCdgqegtbOIfUKoE9w=; b=ESaZ680i8B98Ibe31BTKtMq5bCwHdDkqyp\n\ta6IHKOxwF6cyZawIgCI6fs1HtzH6po9rSsOhSYQs0dto+lx99s2wvUwe9++aam9q\n\tvuDTtJ/v+BK9IJkm9rHspWFq8HNvGrNpBqISN+6PR6IcJuSeF3ta/fuMWClOZqLC\n\tt0UEIhgw5uwLc690ItCjzI2zvlzQBt98Ls3FrJ9CCPFjFsQXMTFHhOUF/eKtGQdv\n\taUnli5iebOTQ5r0TOzy5xS6JsqyztBUf8GgEEKhiu825rRu9qHQIyiPhfrhl9tZL\n\tfWf9U7YuU4CnDzItqCISyM2uVlw5ZApE5a2INyYgSQ0fGmL74wdw==","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=oPYVldZIZZg4YYVuXf\n\thE/xTIJhCdgqegtbOIfUKoE9w=; b=pSpv/8aSoTlT6+irVTPTkKyIFhrQ9nz86s\n\txSs7jdKESu/+X3kYJnYRD0HtYsi/iNpM21XjT3w+qRxq06rUl+N6G1LVXxiuVvxO\n\tvoUEzlGj3NLQgJN5Y9YpRD2G6IFVBiGYs5RkLHJZxJbo+m0xFvste758j8d+KEOV\n\tRdVdfEsIfbTTeaYDKUiba00b1jnGSSOzs3krqZqLv9/yI2wCIdVW8T+Ba2PdfK6s\n\tFwNzV41q/rGlBlSfb49pi0N4+ENV81ppOYV24i/ugLTNwC9B+GDNzcFin3JJy9Gc\n\tKBj3HZDPVzNPWuBDUw5lhzeA5ikTp46fbyN4RXF17mnSSm87cFkw=="],"X-ME-Sender":"","X-Sasl-enc":"g4qU3ONq1jL/zih6Y+6h49csY4KaiSft7fLe+XLVV7uI 1505920577","From":"Hannes Frederic Sowa ","To":"Boris Pismenny ","Cc":"Ilya Lesokhin ,\n\t\"netdev\\@vger.kernel.org\" ,\n\t\"davem\\@davemloft.net\" ,\n\t\"davejwatson\\@fb.com\" ,\n\t\"tom\\@herbertland.com\" ,\n\tAviad Yehezkel , Liran Liss ","Subject":"Re: [PATCH net-next 5/5] tls: Add generic NIC offload\n\tinfrastructure.","References":"<1505385988-94522-1-git-send-email-ilyal@mellanox.com>\n\t<1505385988-94522-6-git-send-email-ilyal@mellanox.com>\n\t<87poaocb4q.fsf@stressinduktion.org>\n\t\n\t<87wp4vt4aa.fsf@stressinduktion.org>\n\t","Date":"Wed, 20 Sep 2017 17:16:13 +0200","In-Reply-To":"\n\t(Boris Pismenny's message of \"Tue, 19 Sep 2017 14:02:33 +0000\")","Message-ID":"<87zi9pbdtu.fsf@stressinduktion.org>","User-Agent":"Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)","MIME-Version":"1.0","Content-Type":"text/plain","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}}]