From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759318AbcHDWy3 (ORCPT ); Thu, 4 Aug 2016 18:54:29 -0400 Received: from one.firstfloor.org ([193.170.194.197]:45285 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759275AbcHDWy2 (ORCPT ); Thu, 4 Aug 2016 18:54:28 -0400 Date: Thu, 4 Aug 2016 15:54:23 -0700 From: Andi Kleen To: Daniel Borkmann Cc: John Fastabend , kan.liang@intel.com, davem@davemloft.net, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, mingo@redhat.com, peterz@infradead.org, kuznet@ms2.inr.ac.ru, jmorris@namei.org, yoshfuji@linux-ipv6.org, kaber@trash.net, akpm@linux-foundation.org, keescook@chromium.org, viro@zeniv.linux.org.uk, gorcunov@openvz.org, john.stultz@linaro.org, aduyck@mirantis.com, ben@decadent.org.uk, decot@googlers.com, fw@strlen.de, alexander.duyck@gmail.com, tom@herbertland.com, rdunlap@infradead.org, xiyou.wangcong@gmail.com, hannes@stressinduktion.org, jesse.brandeburg@intel.com, andi@firstfloor.org Subject: Re: [RFC V2 PATCH 17/25] net/netpolicy: introduce netpolicy_pick_queue Message-ID: <20160804225423.GW5871@two.firstfloor.org> References: <1470339389-8542-1-git-send-email-kan.liang@intel.com> <1470339389-8542-18-git-send-email-kan.liang@intel.com> <57A3A3AC.4010307@gmail.com> <57A3C404.8010608@iogearbox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57A3C404.8010608@iogearbox.net> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > +1, I tried to bring this up here [1] in the last spin. I think only very > few changes would be needed, f.e. on eBPF side to add a queue setting > helper function which is probably straight forward ~10loc patch; and with > regards to actually picking it up after clsact egress, we'd need to adapt > __netdev_pick_tx() slightly when CONFIG_XPS so it doesn't override it. You're proposing to rewrite the whole net policy manager as EBPF and run it in a crappy JITer? Is that a serious proposal? It just sounds crazy to me. Especially since we already have a perfectly good compiler and programming language to write system code in. EBPF is ok for temporal instrumentation (if you somehow can accept its security challenges), but using it to replace core kernel functionality (which network policy IMHO is) with some bizarre JITed setup and multiple languages doesn't really make any sense. Especially it doesn't make sense for anything with shared state, which is the core part of network policy: it negotiates with multiple users. After all we're writing Linux here and not some research toy. Thanks, -Andi -- ak@linux.intel.com -- Speaking for myself only.