[{"id":1776654,"web_url":"http://patchwork.ozlabs.org/comment/1776654/","msgid":"<20170927230042-mutt-send-email-mst@kernel.org>","list_archive_url":null,"date":"2017-09-27T22:13:21","subject":"Re: [PATCH net-next 0/3] support changing steering policies in\n\ttuntap","submitter":{"id":2235,"url":"http://patchwork.ozlabs.org/api/people/2235/","name":"Michael S. Tsirkin","email":"mst@redhat.com"},"content":"On Wed, Sep 27, 2017 at 04:23:54PM +0800, Jason Wang wrote:\n> Hi all:\n> \n> We use flow caches based flow steering policy now. This is good for\n> connection-oriented communication such as TCP but not for the others\n> e.g connectionless unidirectional workload which cares only about\n> pps. This calls the ability of supporting changing steering policies\n> in tuntap which was done by this series.\n> \n> Flow steering policy was abstracted into tun_steering_ops in the first\n> patch. Then new ioctls to set or query current policy were introduced,\n> and the last patch introduces a very simple policy that select txq\n> based on processor id as an example.\n> \n> Test was done by using xdp_redirect to redirect traffic generated from\n> MoonGen that was running on a remote machine. And I see 37%\n> improvement for processor id policy compared to automatic flow\n> steering policy.\n\nFor sure, if you don't need to figure out the flow hash then you can\nsave a bunch of cycles. But I don't think the cpu policy is too\npractical outside of a benchmark.\n\nDid you generate packets and just send them to tun? If so, this is not a\ntypical configuration, is it? With packets coming e.g. from a real nic\nthey might already have the hash pre-calculated, and you won't\nsee the benefit.\n\n> In the future, both simple and sophisticated policy like RSS or other guest\n> driven steering policies could be done on top.\n\nIMHO there should be a more practical example before adding all this\nindirection. And it would be nice to understand why this queue selection\nneeds to be tun specific.\n\n> Thanks\n> \n> Jason Wang (3):\n> tun: abstract flow steering logic\n> tun: introduce ioctls to set and get steering policies\n> tun: introduce cpu id based steering policy\n> \n> drivers/net/tun.c | 151 +++++++++++++++++++++++++++++++++++++-------\n> include/uapi/linux/if_tun.h | 8 +++\n> 2 files changed, 136 insertions(+), 23 deletions(-)\n> \n> -- \n> 2.7.4","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=)","ext-mx06.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx06.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=mst@redhat.com"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y2XCP61zhz9t6C\n\tfor ;\n\tThu, 28 Sep 2017 08:13:37 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752402AbdI0WNZ (ORCPT );\n\tWed, 27 Sep 2017 18:13:25 -0400","from mx1.redhat.com ([209.132.183.28]:34268 \"EHLO mx1.redhat.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1752385AbdI0WNW (ORCPT );\n\tWed, 27 Sep 2017 18:13:22 -0400","from smtp.corp.redhat.com\n\t(int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14])\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 8350218C761;\n\tWed, 27 Sep 2017 22:13:22 +0000 (UTC)","from redhat.com (ovpn-123-149.rdu2.redhat.com [10.10.123.149])\n\tby smtp.corp.redhat.com (Postfix) with SMTP id 080A08B169;\n\tWed, 27 Sep 2017 22:13:21 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 8350218C761","Date":"Thu, 28 Sep 2017 01:13:21 +0300","From":"\"Michael S. Tsirkin\" ","To":"Jason Wang ","Cc":"netdev@vger.kernel.org, linux-kernel@vger.kernel.org","Subject":"Re: [PATCH net-next 0/3] support changing steering policies in\n\ttuntap","Message-ID":"<20170927230042-mutt-send-email-mst@kernel.org>","References":"<1506500637-13881-1-git-send-email-jasowang@redhat.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<1506500637-13881-1-git-send-email-jasowang@redhat.com>","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.14","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.30]);\n\tWed, 27 Sep 2017 22:13:22 +0000 (UTC)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1776691,"web_url":"http://patchwork.ozlabs.org/comment/1776691/","msgid":"","list_archive_url":null,"date":"2017-09-27T23:25:37","subject":"Re: [PATCH net-next 0/3] support changing steering policies in\n\ttuntap","submitter":{"id":67615,"url":"http://patchwork.ozlabs.org/api/people/67615/","name":"Willem de Bruijn","email":"willemdebruijn.kernel@gmail.com"},"content":">> In the future, both simple and sophisticated policy like RSS or other guest\n>> driven steering policies could be done on top.\n>\n> IMHO there should be a more practical example before adding all this\n> indirection. And it would be nice to understand why this queue selection\n> needs to be tun specific.\n\nI was thinking the same and this reminds me of the various strategies\nimplemented in packet fanout. tun_cpu_select_queue is analogous to\nfanout_demux_cpu though it is tun-specific in that it requires tun->numqueues.\n\nFanout accrued various strategies until it gained an eBPF variant. Just\nsupporting BPF is probably sufficient here, too.","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=gmail.com header.i=@gmail.com\n\theader.b=\"O/RDmdLY\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y2YqX3PPmz9t6C\n\tfor ;\n\tThu, 28 Sep 2017 09:26:32 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752365AbdI0X0T (ORCPT );\n\tWed, 27 Sep 2017 19:26:19 -0400","from mail-oi0-f45.google.com ([209.85.218.45]:53083 \"EHLO\n\tmail-oi0-f45.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1752231AbdI0X0S (ORCPT\n\t); Wed, 27 Sep 2017 19:26:18 -0400","by mail-oi0-f45.google.com with SMTP id p126so19072365oih.9;\n\tWed, 27 Sep 2017 16:26:18 -0700 (PDT)","by 10.168.31.195 with HTTP; Wed, 27 Sep 2017 16:25:37 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=Bihu6iZMLZxR8r0Si1sqoJwv7kD4AmyQZ9yfZrXHQeU=;\n\tb=O/RDmdLYSjSgmNNG4H8La0zLf2PnQYDENTCGfa+u636VgZYklVhRksEcSG5WR/+4t4\n\tUli9LxrK+g09zAiElqV8z6OiVCFGH2CbN/HvlkB6aCRKRm3EL1YZQfj+nsjnk0AKerSn\n\tiFSk1qihCj3EvQwj8sVDgMwGN7n3xlMQHjkAwCEOPbsbr0xceio0YC3kjCKmc9IgyNbk\n\t6lWfinz4uALEiXK7dg5xcg0B5Q+DJTW81UaaXQLrJ1VLvm1ilywhh6REhY7isJCdi8jU\n\tuZsOl2obJAcg9L5XdSv/NFlTmNM8j8WMtm9cIWzNjFilziyKSzBcPn4XCccefyLhvdk3\n\toPkg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=Bihu6iZMLZxR8r0Si1sqoJwv7kD4AmyQZ9yfZrXHQeU=;\n\tb=GZnqvbH7s77lugdgpXozuAqHYMDyfgNBW8xwXc+o73DSY2NEwKDPTjj9rA1IeOVISH\n\tWCR3UiOq2bQEC1HjFe1OZFxTnQD/YTCDB4XZLziBGDcWYjpfvSNjCYsk0de9xgub/JCf\n\tlFRUgPcUtBYy2RgR0JebASdFc+ZILus2DRUeXkeZ3VoRLMsJOURUh69Z4m7q4zMmwq5g\n\t5j/0Ctdy/xRIa6QUe05m3rm8DkxwgRuPPQ3UJo3o2S8nDq8IwajVKep0S9bFaoaRBlgo\n\tfeKJOkBNHyvzhWW0XAYs29k2Px3XvEazPMZ6GRSEpys1BE3aKux3OaQkXZ3k1YRxnLs7\n\tBTAg==","X-Gm-Message-State":"AMCzsaWEmFgwtETSTa+CflLWukHOYYP6/bnkLvj9oQJiA/315munupxV\n\tITl0FWtNuGtATEZtMBv6gSyQ5UzPyqv3hJlMAiQ=","X-Google-Smtp-Source":"AOwi7QCN/IDx9HTYcfFHx6CVdLnuL1677J8ooSIyjWqo57yxKS/RWmjLIBN5t2cyrl9H3f24FTy/RZvkAYLRZG6WqQo=","X-Received":"by 10.157.92.201 with SMTP id r9mr518399oti.8.1506554777507; Wed,\n\t27 Sep 2017 16:26:17 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<20170927230042-mutt-send-email-mst@kernel.org>","References":"<1506500637-13881-1-git-send-email-jasowang@redhat.com>\n\t<20170927230042-mutt-send-email-mst@kernel.org>","From":"Willem de Bruijn ","Date":"Wed, 27 Sep 2017 19:25:37 -0400","Message-ID":"","Subject":"Re: [PATCH net-next 0/3] support changing steering policies in\n\ttuntap","To":"\"Michael S. Tsirkin\" ","Cc":"Jason Wang ,\n\tNetwork Development ,\n\tLKML ","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1776773,"web_url":"http://patchwork.ozlabs.org/comment/1776773/","msgid":"","list_archive_url":null,"date":"2017-09-28T05:02:31","subject":"Re: [PATCH net-next 0/3] support changing steering policies in\n\ttuntap","submitter":{"id":65986,"url":"http://patchwork.ozlabs.org/api/people/65986/","name":"Tom Herbert","email":"tom@herbertland.com"},"content":"On Wed, Sep 27, 2017 at 4:25 PM, Willem de Bruijn\n wrote:\n>>> In the future, both simple and sophisticated policy like RSS or other guest\n>>> driven steering policies could be done on top.\n>>\n>> IMHO there should be a more practical example before adding all this\n>> indirection. And it would be nice to understand why this queue selection\n>> needs to be tun specific.\n>\n> I was thinking the same and this reminds me of the various strategies\n> implemented in packet fanout. tun_cpu_select_queue is analogous to\n> fanout_demux_cpu though it is tun-specific in that it requires tun->numqueues.\n>\n> Fanout accrued various strategies until it gained an eBPF variant. Just\n> supporting BPF is probably sufficient here, too.\n\n+1, in addition to packet fanout, we have SO_REUSEPORT with BPF, RPS,\nRFS, etc. It would be nice if existing packet steering mechanisms\ncould be leveraged for tun.","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=herbertland-com.20150623.gappssmtp.com\n\theader.i=@herbertland-com.20150623.gappssmtp.com\n\theader.b=\"nLLx2Hi1\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y2jHW37B1z9sPt\n\tfor ;\n\tThu, 28 Sep 2017 15:02:47 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751988AbdI1FCe (ORCPT );\n\tThu, 28 Sep 2017 01:02:34 -0400","from mail-qk0-f181.google.com ([209.85.220.181]:55154 \"EHLO\n\tmail-qk0-f181.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751773AbdI1FCc (ORCPT\n\t); Thu, 28 Sep 2017 01:02:32 -0400","by mail-qk0-f181.google.com with SMTP id d70so338910qkc.11\n\tfor ; Wed, 27 Sep 2017 22:02:32 -0700 (PDT)","by 10.237.61.196 with HTTP; Wed, 27 Sep 2017 22:02:31 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=herbertland-com.20150623.gappssmtp.com; s=20150623;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=/Ozxw6r5oxBMdsMcaTa1B4MVLVdLqsdbQA0t8v2Yo94=;\n\tb=nLLx2Hi1+d0NfZxnD5o/jhIFMoKe+IRnDsgvWfIqq0C7j5MjeD+f+TDgUukAExLHzA\n\tMFed0ooGQUni2fsK8b1tc4WqG0W4im5ZySBpV15Qwa7tyyJbiTPrbePuumth6Ut7Huuu\n\t3bPsCIb1dNlNrRxhHYeRED0YKBICh9qJXDPzVi78SLu5AXingYjwOaphV0gYRpHyRgqw\n\tBhgYeslW5SwiXyd4pZ2EYGugoYD2t9XReaM5b1TiV0Jx0bGPfoaUyM23Ljt8nVQt0OmG\n\tk0WB0ZNUVq5kWplTOz8UPfHwMSZtsyyn8/oLvMPlGU80U4ByaQY2Q8/sT5qGv6d2j1KP\n\tM8Gw==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=/Ozxw6r5oxBMdsMcaTa1B4MVLVdLqsdbQA0t8v2Yo94=;\n\tb=j5V0EddyDMFnZTnd1SfB98wulr6gyPTBU59smE1uHdaQ25bQnfg+kMI1FmEGJSiel5\n\t8YWc9ke4kmKesC7rnWlLavOJb4/9DHWatdwJ7oqi7gjDraqDd3dyngHOBjOmkzP7Evvx\n\tKWSPKi/Foh1ASKpwrRN1ROKF71iQZTQH2ht0Uum+rhSwTqiuSO1CzliotgGRNx47nr4E\n\tVJEvXQLUpJstwtwPe3fD2KFBegL/9GUODND5v7qACdZ71/LV5FEGYFU51T+lK8tOR4xx\n\tmcFH1CqEpWClxgAnVNnTpHJ5emlgVr5BdvAS98D8Jzb402kK8hrl/+rEU148Oyiv2Hth\n\tTR6w==","X-Gm-Message-State":"AMCzsaWruyGTECDXZr2L/7JaHySoC2ytIEvAgg51NPEDv0KqgO9uIwMv\n\t9EgORGTnRDXfbHaYUg92sYzXKFFXUOz29NZFwL/caQ==","X-Google-Smtp-Source":"AOwi7QAyoeuZvrnhQ/8LZ6PiHio43AzpdegxZWenk0xqxmI1oONY7n7Ko87de+vzijblLMAuS23Tlu7J/PJY6i/0sFQ=","X-Received":"by 10.55.109.131 with SMTP id i125mr5167534qkc.17.1506574951593; \n\tWed, 27 Sep 2017 22:02:31 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"","References":"<1506500637-13881-1-git-send-email-jasowang@redhat.com>\n\t<20170927230042-mutt-send-email-mst@kernel.org>\n\t","From":"Tom Herbert ","Date":"Wed, 27 Sep 2017 22:02:31 -0700","Message-ID":"","Subject":"Re: [PATCH net-next 0/3] support changing steering policies in\n\ttuntap","To":"Willem de Bruijn ","Cc":"\"Michael S. Tsirkin\" , Jason Wang ,\n\tNetwork Development ,\n\tLKML ","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1776798,"web_url":"http://patchwork.ozlabs.org/comment/1776798/","msgid":"<77e2149a-e2cc-cd18-039d-a202cd9f8b4c@redhat.com>","list_archive_url":null,"date":"2017-09-28T06:50:31","subject":"Re: [PATCH net-next 0/3] support changing steering policies in\n\ttuntap","submitter":{"id":5225,"url":"http://patchwork.ozlabs.org/api/people/5225/","name":"Jason Wang","email":"jasowang@redhat.com"},"content":"On 2017年09月28日 06:13, Michael S. Tsirkin wrote:\n> On Wed, Sep 27, 2017 at 04:23:54PM +0800, Jason Wang wrote:\n>> Hi all:\n>>\n>> We use flow caches based flow steering policy now. This is good for\n>> connection-oriented communication such as TCP but not for the others\n>> e.g connectionless unidirectional workload which cares only about\n>> pps. This calls the ability of supporting changing steering policies\n>> in tuntap which was done by this series.\n>>\n>> Flow steering policy was abstracted into tun_steering_ops in the first\n>> patch. Then new ioctls to set or query current policy were introduced,\n>> and the last patch introduces a very simple policy that select txq\n>> based on processor id as an example.\n>>\n>> Test was done by using xdp_redirect to redirect traffic generated from\n>> MoonGen that was running on a remote machine. And I see 37%\n>> improvement for processor id policy compared to automatic flow\n>> steering policy.\n> For sure, if you don't need to figure out the flow hash then you can\n> save a bunch of cycles. But I don't think the cpu policy is too\n> practical outside of a benchmark.\n\nWell, the aim of the series is to add methods to change the steering \npolicy, cpu policy is an example. Actually, it may make sense for some \ncards which guarantee that all packets belongs to a specific flow goes \ninto a specific cpu.\n\n>\n> Did you generate packets and just send them to tun? If so, this is not a\n> typical configuration, is it?\n\nThe test was done by:\n\n- generate UDP traffic from a remote machine\n- use xdp redirection to do mac swap in guest and forward it back to the \nremote machine\n\n> With packets coming e.g. from a real nic\n> they might already have the hash pre-calculated, and you won't\n> see the benefit.\n\nYes, I can switch to use this as a example policy.\n\nThanks\n\n>\n>> In the future, both simple and sophisticated policy like RSS or other guest\n>> driven steering policies could be done on top.\n> IMHO there should be a more practical example before adding all this\n> indirection. And it would be nice to understand why this queue selection\n> needs to be tun specific.\n\nActually, we can use fanout policy (as pointed out) by using the API \nintroduced in this series.\n\nThanks\n\n>\n>> Thanks\n>>\n>> Jason Wang (3):\n>> tun: abstract flow steering logic\n>> tun: introduce ioctls to set and get steering policies\n>> tun: introduce cpu id based steering policy\n>>\n>> drivers/net/tun.c | 151 +++++++++++++++++++++++++++++++++++++-------\n>> include/uapi/linux/if_tun.h | 8 +++\n>> 2 files changed, 136 insertions(+), 23 deletions(-)\n>>\n>> -- \n>> 2.7.4","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=)","ext-mx06.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx06.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=jasowang@redhat.com"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y2lhG0Thrz9t5C\n\tfor ;\n\tThu, 28 Sep 2017 16:50:54 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751511AbdI1Gul (ORCPT );\n\tThu, 28 Sep 2017 02:50:41 -0400","from mx1.redhat.com ([209.132.183.28]:58648 \"EHLO mx1.redhat.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751091AbdI1Guk (ORCPT );\n\tThu, 28 Sep 2017 02:50:40 -0400","from smtp.corp.redhat.com\n\t(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])\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 1F41E64DEB;\n\tThu, 28 Sep 2017 06:50:40 +0000 (UTC)","from [10.72.12.139] (ovpn-12-139.pek2.redhat.com [10.72.12.139])\n\tby smtp.corp.redhat.com (Postfix) with ESMTPS id 7E398822F9;\n\tThu, 28 Sep 2017 06:50:35 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 1F41E64DEB","Subject":"Re: [PATCH net-next 0/3] support changing steering policies in\n\ttuntap","To":"\"Michael S. Tsirkin\" ","Cc":"netdev@vger.kernel.org, linux-kernel@vger.kernel.org","References":"<1506500637-13881-1-git-send-email-jasowang@redhat.com>\n\t<20170927230042-mutt-send-email-mst@kernel.org>","From":"Jason Wang ","Message-ID":"<77e2149a-e2cc-cd18-039d-a202cd9f8b4c@redhat.com>","Date":"Thu, 28 Sep 2017 14:50:31 +0800","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<20170927230042-mutt-send-email-mst@kernel.org>","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Transfer-Encoding":"8bit","Content-Language":"en-US","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.12","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.30]);\n\tThu, 28 Sep 2017 06:50:40 +0000 (UTC)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1776820,"web_url":"http://patchwork.ozlabs.org/comment/1776820/","msgid":"<26f01b12-396e-6319-0eed-c987930e0ed9@redhat.com>","list_archive_url":null,"date":"2017-09-28T07:23:34","subject":"Re: [PATCH net-next 0/3] support changing steering policies in\n\ttuntap","submitter":{"id":5225,"url":"http://patchwork.ozlabs.org/api/people/5225/","name":"Jason Wang","email":"jasowang@redhat.com"},"content":"On 2017年09月28日 07:25, Willem de Bruijn wrote:\n>>> In the future, both simple and sophisticated policy like RSS or other guest\n>>> driven steering policies could be done on top.\n>> IMHO there should be a more practical example before adding all this\n>> indirection. And it would be nice to understand why this queue selection\n>> needs to be tun specific.\n> I was thinking the same and this reminds me of the various strategies\n> implemented in packet fanout. tun_cpu_select_queue is analogous to\n> fanout_demux_cpu though it is tun-specific in that it requires tun->numqueues.\n\nRight, the main idea is to introduce a way to change flow steering \npolicy for tun. I think fanout policy could be implemented through the \nAPI introduced in this series. (Current flow caches based automatic \nsteering method is tun specific).\n\n>\n> Fanout accrued various strategies until it gained an eBPF variant. Just\n> supporting BPF is probably sufficient here, too.\n\nTechnically yes, but for tun, it also serve for virt. We probably still \nneed some hard coded policy which could be changed by guest until we can \naccept an BPF program from guest I think?\n\nThanks","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=)","ext-mx09.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx09.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=jasowang@redhat.com"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y2mQN2GT3z9t5x\n\tfor ;\n\tThu, 28 Sep 2017 17:23:56 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752011AbdI1HXo (ORCPT );\n\tThu, 28 Sep 2017 03:23:44 -0400","from mx1.redhat.com ([209.132.183.28]:34090 \"EHLO mx1.redhat.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751618AbdI1HXn (ORCPT );\n\tThu, 28 Sep 2017 03:23:43 -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 204BD2CA614;\n\tThu, 28 Sep 2017 07:23:43 +0000 (UTC)","from [10.72.12.139] (ovpn-12-139.pek2.redhat.com [10.72.12.139])\n\tby smtp.corp.redhat.com (Postfix) with ESMTPS id C763717143;\n\tThu, 28 Sep 2017 07:23:39 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 204BD2CA614","Subject":"Re: [PATCH net-next 0/3] support changing steering policies in\n\ttuntap","To":"Willem de Bruijn ,\n\t\"Michael S. Tsirkin\" ","Cc":"Network Development ,\n\tLKML ","References":"<1506500637-13881-1-git-send-email-jasowang@redhat.com>\n\t<20170927230042-mutt-send-email-mst@kernel.org>\n\t","From":"Jason Wang ","Message-ID":"<26f01b12-396e-6319-0eed-c987930e0ed9@redhat.com>","Date":"Thu, 28 Sep 2017 15:23:34 +0800","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Transfer-Encoding":"8bit","Content-Language":"en-US","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.38]);\n\tThu, 28 Sep 2017 07:23:43 +0000 (UTC)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1776838,"web_url":"http://patchwork.ozlabs.org/comment/1776838/","msgid":"<075d507f-9666-f13d-11fa-1d0eb694a3f7@redhat.com>","list_archive_url":null,"date":"2017-09-28T07:53:58","subject":"Re: [PATCH net-next 0/3] support changing steering policies in\n\ttuntap","submitter":{"id":5225,"url":"http://patchwork.ozlabs.org/api/people/5225/","name":"Jason Wang","email":"jasowang@redhat.com"},"content":"On 2017年09月28日 13:02, Tom Herbert wrote:\n> On Wed, Sep 27, 2017 at 4:25 PM, Willem de Bruijn\n> wrote:\n>>>> In the future, both simple and sophisticated policy like RSS or other guest\n>>>> driven steering policies could be done on top.\n>>> IMHO there should be a more practical example before adding all this\n>>> indirection. And it would be nice to understand why this queue selection\n>>> needs to be tun specific.\n>> I was thinking the same and this reminds me of the various strategies\n>> implemented in packet fanout. tun_cpu_select_queue is analogous to\n>> fanout_demux_cpu though it is tun-specific in that it requires tun->numqueues.\n>>\n>> Fanout accrued various strategies until it gained an eBPF variant. Just\n>> supporting BPF is probably sufficient here, too.\n> +1, in addition to packet fanout, we have SO_REUSEPORT with BPF, RPS,\n> RFS, etc. It would be nice if existing packet steering mechanisms\n> could be leveraged for tun.\n\nThis could be done by using the API introduced in this series, I can try \nthis in V2.\n\nThanks","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=)","ext-mx03.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx03.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=jasowang@redhat.com"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y2n5p57vtz9t2c\n\tfor ;\n\tThu, 28 Sep 2017 17:54:38 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752543AbdI1HyY (ORCPT );\n\tThu, 28 Sep 2017 03:54:24 -0400","from mx1.redhat.com ([209.132.183.28]:56718 \"EHLO mx1.redhat.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751998AbdI1HyR (ORCPT );\n\tThu, 28 Sep 2017 03:54:17 -0400","from smtp.corp.redhat.com\n\t(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])\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 0D23A29A4E;\n\tThu, 28 Sep 2017 07:54:17 +0000 (UTC)","from [10.72.12.139] (ovpn-12-139.pek2.redhat.com [10.72.12.139])\n\tby smtp.corp.redhat.com (Postfix) with ESMTPS id D20FC82311;\n\tThu, 28 Sep 2017 07:54:10 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 0D23A29A4E","Subject":"Re: [PATCH net-next 0/3] support changing steering policies in\n\ttuntap","To":"Tom Herbert ,\n\tWillem de Bruijn ","Cc":"\"Michael S. Tsirkin\" ,\n\tNetwork Development ,\n\tLKML ","References":"<1506500637-13881-1-git-send-email-jasowang@redhat.com>\n\t<20170927230042-mutt-send-email-mst@kernel.org>\n\t\n\t","From":"Jason Wang ","Message-ID":"<075d507f-9666-f13d-11fa-1d0eb694a3f7@redhat.com>","Date":"Thu, 28 Sep 2017 15:53:58 +0800","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Transfer-Encoding":"8bit","Content-Language":"en-US","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.12","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.27]);\n\tThu, 28 Sep 2017 07:54:17 +0000 (UTC)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1777140,"web_url":"http://patchwork.ozlabs.org/comment/1777140/","msgid":"","list_archive_url":null,"date":"2017-09-28T16:09:05","subject":"Re: [PATCH net-next 0/3] support changing steering policies in\n\ttuntap","submitter":{"id":67615,"url":"http://patchwork.ozlabs.org/api/people/67615/","name":"Willem de Bruijn","email":"willemdebruijn.kernel@gmail.com"},"content":"On Thu, Sep 28, 2017 at 3:23 AM, Jason Wang wrote:\n>\n>\n> On 2017年09月28日 07:25, Willem de Bruijn wrote:\n>>>>\n>>>> In the future, both simple and sophisticated policy like RSS or other\n>>>> guest\n>>>> driven steering policies could be done on top.\n>>>\n>>> IMHO there should be a more practical example before adding all this\n>>> indirection. And it would be nice to understand why this queue selection\n>>> needs to be tun specific.\n>>\n>> I was thinking the same and this reminds me of the various strategies\n>> implemented in packet fanout. tun_cpu_select_queue is analogous to\n>> fanout_demux_cpu though it is tun-specific in that it requires\n>> tun->numqueues.\n>\n>\n> Right, the main idea is to introduce a way to change flow steering policy\n> for tun. I think fanout policy could be implemented through the API\n> introduced in this series. (Current flow caches based automatic steering\n> method is tun specific).\n>\n>>\n>> Fanout accrued various strategies until it gained an eBPF variant. Just\n>> supporting BPF is probably sufficient here, too.\n>\n>\n> Technically yes, but for tun, it also serve for virt. We probably still need\n> some hard coded policy which could be changed by guest until we can accept\n> an BPF program from guest I think?\n\nWhen would a guest choose the policy? As long as this is under control\nof a host user, possibly unprivileged, allowing BPF here is moot, as any\nuser can run socket filter BPF already. Programming from the guest is\nindeed different. I don't fully understand that use case.","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=gmail.com header.i=@gmail.com\n\theader.b=\"YjYDvSIL\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y305N3SXwz9t48\n\tfor ;\n\tFri, 29 Sep 2017 02:10:00 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751980AbdI1QJs (ORCPT );\n\tThu, 28 Sep 2017 12:09:48 -0400","from mail-oi0-f51.google.com ([209.85.218.51]:43571 \"EHLO\n\tmail-oi0-f51.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1750955AbdI1QJr (ORCPT\n\t); Thu, 28 Sep 2017 12:09:47 -0400","by mail-oi0-f51.google.com with SMTP id r20so3085848oie.0;\n\tThu, 28 Sep 2017 09:09:46 -0700 (PDT)","by 10.168.31.195 with HTTP; Thu, 28 Sep 2017 09:09:05 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc:content-transfer-encoding;\n\tbh=ZLf8Y8bhEp4YVYe195wM4my8/sUVJiT5Ay5yZS55ZRY=;\n\tb=YjYDvSILaYbFKZjs6NnSJFckGCJ1t/ok2qYGiIQwFWct1efVW5cpQ7ghVtvpWWR+0p\n\tXL5BOA12z8/sxLIEpFl5CW8AYfGIKTIb7UBKBBoBmjCGQu//dkCimlG26o3oHp5qHAKf\n\tO+EfE+0S/BMEhe7+hyqJ2FZxlUjZOrqWbMke35YIFvuyXpZNKgLccpLopGYwyphmdg+m\n\tJXXAa1DxfQHLsfGDMFMkKvq6TiahjZXkGPEFvuDpTlEy17Gr26w5IHXode4et4W8m2mP\n\tTWE9Yw9dz+3mj0IorwmAFryyJHiTR6aZNDuqtsBHk/4LktrEisR3jUHc9jqrlpMyHkVU\n\tR3bQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc:content-transfer-encoding;\n\tbh=ZLf8Y8bhEp4YVYe195wM4my8/sUVJiT5Ay5yZS55ZRY=;\n\tb=QoEm46arfJ5so85XiVYgPS7MOBQuSqjgkJDl/WCu4jODvg41nMpwM9f+ajm1O6ak83\n\taB17eusG5YsnvOHoWN4ZL/oxm9JS3xP+S/j4qfIyGur8nNJ0jp+PsRegMS1oBlL29WOk\n\tx5nXj8vw7qpTaWGQu20qJxPh+Vx294svvDo1IWdcE4JlERPfwDJuvsrbZc2+Ci3bwQ5u\n\tfVV3RVaS3e0pcVR2u2L/ttO4LnhDUc5+SzrY3LkKW8Xo/7bl/c8yw3y6qKPEdeXSfgCh\n\te7VX4FFRtlSiubi46bT3SwQyp+yzav5LuU7Je40NG8GGBDrA1QU+GW1JQR67lPxNGHYN\n\t4tkA==","X-Gm-Message-State":"AMCzsaW6DXlSq8eavrkvoY7A5F9e75/rfnC6BTLz4qsd/AQbWN8twqMq\n\tr8D0U4O5uFE4ToUFCdwGrDenz3FFomOdc2gZvc8=","X-Google-Smtp-Source":"AOwi7QDLWkfNDVXJgXENJbNQOn3E64S6UerOKNurSagVxwyVortPtH2pUx2cuCYKmAR+vXZ5Q1ru3bYHvl9EnrX8HLw=","X-Received":"by 10.202.75.137 with SMTP id y131mr622463oia.430.1506614986129; \n\tThu, 28 Sep 2017 09:09:46 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<26f01b12-396e-6319-0eed-c987930e0ed9@redhat.com>","References":"<1506500637-13881-1-git-send-email-jasowang@redhat.com>\n\t<20170927230042-mutt-send-email-mst@kernel.org>\n\t\n\t<26f01b12-396e-6319-0eed-c987930e0ed9@redhat.com>","From":"Willem de Bruijn ","Date":"Thu, 28 Sep 2017 12:09:05 -0400","Message-ID":"","Subject":"Re: [PATCH net-next 0/3] support changing steering policies in\n\ttuntap","To":"Jason Wang ","Cc":"\"Michael S. Tsirkin\" ,\n\tNetwork Development ,\n\tLKML ","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1777447,"web_url":"http://patchwork.ozlabs.org/comment/1777447/","msgid":"","list_archive_url":null,"date":"2017-09-29T09:41:40","subject":"Re: [PATCH net-next 0/3] support changing steering policies in\n\ttuntap","submitter":{"id":5225,"url":"http://patchwork.ozlabs.org/api/people/5225/","name":"Jason Wang","email":"jasowang@redhat.com"},"content":"On 2017年09月29日 00:09, Willem de Bruijn wrote:\n> On Thu, Sep 28, 2017 at 3:23 AM, Jason Wang wrote:\n>>\n>> On 2017年09月28日 07:25, Willem de Bruijn wrote:\n>>>>> In the future, both simple and sophisticated policy like RSS or other\n>>>>> guest\n>>>>> driven steering policies could be done on top.\n>>>> IMHO there should be a more practical example before adding all this\n>>>> indirection. And it would be nice to understand why this queue selection\n>>>> needs to be tun specific.\n>>> I was thinking the same and this reminds me of the various strategies\n>>> implemented in packet fanout. tun_cpu_select_queue is analogous to\n>>> fanout_demux_cpu though it is tun-specific in that it requires\n>>> tun->numqueues.\n>>\n>> Right, the main idea is to introduce a way to change flow steering policy\n>> for tun. I think fanout policy could be implemented through the API\n>> introduced in this series. (Current flow caches based automatic steering\n>> method is tun specific).\n>>\n>>> Fanout accrued various strategies until it gained an eBPF variant. Just\n>>> supporting BPF is probably sufficient here, too.\n>>\n>> Technically yes, but for tun, it also serve for virt. We probably still need\n>> some hard coded policy which could be changed by guest until we can accept\n>> an BPF program from guest I think?\n> When would a guest choose the policy? As long as this is under control\n> of a host user, possibly unprivileged, allowing BPF here is moot, as any\n> user can run socket filter BPF already. Programming from the guest is\n> indeed different. I don't fully understand that use case.\n\nThe problem is userspace (qemu) know little about what kind of workloads \nwill be done by guest, so we need guest controllable method here since \nit knows the best steering policy. Rethink about this, instead of \npassing eBPF from guest, qemu can have some pre-defined sets of polices. \nI will change the cpu id based to eBPF based in V2.\n\nThanks","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=)","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=jasowang@redhat.com"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y3RRL2Rqtz9t2r\n\tfor ;\n\tFri, 29 Sep 2017 19:42:06 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751874AbdI2Jly (ORCPT );\n\tFri, 29 Sep 2017 05:41:54 -0400","from mx1.redhat.com ([209.132.183.28]:44414 \"EHLO mx1.redhat.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1750926AbdI2Jlw (ORCPT );\n\tFri, 29 Sep 2017 05:41:52 -0400","from smtp.corp.redhat.com\n\t(int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14])\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 A032A80467;\n\tFri, 29 Sep 2017 09:41:52 +0000 (UTC)","from [10.72.12.103] (ovpn-12-103.pek2.redhat.com [10.72.12.103])\n\tby smtp.corp.redhat.com (Postfix) with ESMTPS id 1767A1815C;\n\tFri, 29 Sep 2017 09:41:46 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com A032A80467","Subject":"Re: [PATCH net-next 0/3] support changing steering policies in\n\ttuntap","To":"Willem de Bruijn ","Cc":"\"Michael S. Tsirkin\" ,\n\tNetwork Development ,\n\tLKML ","References":"<1506500637-13881-1-git-send-email-jasowang@redhat.com>\n\t<20170927230042-mutt-send-email-mst@kernel.org>\n\t\n\t<26f01b12-396e-6319-0eed-c987930e0ed9@redhat.com>\n\t","From":"Jason Wang ","Message-ID":"","Date":"Fri, 29 Sep 2017 17:41:40 +0800","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Transfer-Encoding":"8bit","Content-Language":"en-US","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.14","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.28]);\n\tFri, 29 Sep 2017 09:41:52 +0000 (UTC)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1777989,"web_url":"http://patchwork.ozlabs.org/comment/1777989/","msgid":"<20171001062520-mutt-send-email-mst@kernel.org>","list_archive_url":null,"date":"2017-10-01T03:28:04","subject":"Re: [PATCH net-next 0/3] support changing steering policies in\n\ttuntap","submitter":{"id":2235,"url":"http://patchwork.ozlabs.org/api/people/2235/","name":"Michael S. Tsirkin","email":"mst@redhat.com"},"content":"On Thu, Sep 28, 2017 at 12:09:05PM -0400, Willem de Bruijn wrote:\n> Programming from the guest is\n> indeed different. I don't fully understand that use case.\n\nGenerally programming host BPF from guest is a clear win - think DOS\nprotection. Guest runs logic to detect dos attacks, then passes the\nprogram to host. Afterwards, host does not need to enter guest if\nthere's a DOS attack. Saves a ton of cycles.\n\nThe difficulty is making it work well, e.g. how do we handle maps?","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=)","ext-mx02.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx02.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=mst@redhat.com"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y4W384dhmz9t2h\n\tfor ;\n\tSun, 1 Oct 2017 14:28:20 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751036AbdJAD2G (ORCPT );\n\tSat, 30 Sep 2017 23:28:06 -0400","from mx1.redhat.com ([209.132.183.28]:41312 \"EHLO mx1.redhat.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1750730AbdJAD2F (ORCPT );\n\tSat, 30 Sep 2017 23:28:05 -0400","from smtp.corp.redhat.com\n\t(int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])\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 73AB6883BD;\n\tSun, 1 Oct 2017 03:28:05 +0000 (UTC)","from redhat.com (ovpn-120-33.rdu2.redhat.com [10.10.120.33])\n\tby smtp.corp.redhat.com (Postfix) with SMTP id B77F16017C;\n\tSun, 1 Oct 2017 03:28:04 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 73AB6883BD","Date":"Sun, 1 Oct 2017 06:28:04 +0300","From":"\"Michael S. Tsirkin\" ","To":"Willem de Bruijn ","Cc":"Jason Wang ,\n\tNetwork Development ,\n\tLKML ","Subject":"Re: [PATCH net-next 0/3] support changing steering policies in\n\ttuntap","Message-ID":"<20171001062520-mutt-send-email-mst@kernel.org>","References":"<1506500637-13881-1-git-send-email-jasowang@redhat.com>\n\t<20170927230042-mutt-send-email-mst@kernel.org>\n\t\n\t<26f01b12-396e-6319-0eed-c987930e0ed9@redhat.com>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.11","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.26]);\n\tSun, 01 Oct 2017 03:28:05 +0000 (UTC)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}}]