From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shannon Nelson Subject: Re: [PATCH net-next] net: enable RPS on vlan devices Date: Wed, 10 Oct 2018 11:23:00 -0700 Message-ID: <13b1a780-ebde-3f0c-65f3-72157bc23690@oracle.com> References: <1539132062-4348-1-git-send-email-shannon.nelson@oracle.com> <36675e01-e9be-2464-2ee1-2409ebc22223@oracle.com> <6b6794f4-fa61-a9bc-43ed-3c62eb680498@gmail.com> <6d7227d4-a7e0-0979-42bc-c7af61b35192@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Cc: silviu.smarandache@oracle.com To: Eric Dumazet , davem@davemloft.net, netdev@vger.kernel.org Return-path: Received: from userp2130.oracle.com ([156.151.31.86]:41148 "EHLO userp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726668AbeJKBq1 (ORCPT ); Wed, 10 Oct 2018 21:46:27 -0400 In-Reply-To: Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 10/10/2018 10:14 AM, Eric Dumazet wrote: > > On 10/10/2018 09:18 AM, Shannon Nelson wrote: >> On 10/9/2018 7:17 PM, Eric Dumazet wrote: >>> >>> >>> On 10/09/2018 07:11 PM, Shannon Nelson wrote: >>>> >>>> Hence the reason we sent this as an RFC a couple of weeks ago.  We got no response, so followed up with this patch in order to get some input. Do you have any suggestions for how we might accomplish this in a less ugly way? >>> >>> I dunno, maybe a modern way for all these very specific needs would be to use an eBPF >>> hook to implement whatever combination of RPS/RFS/what_have_you >>> >>> Then, we no longer have to review what various strategies are used by users. >> >> We're trying to make use of an existing useful feature that was designed for exactly this kind of problem.  It is already there and no new user training is needed.  We're actually fixing what could arguably be called a bug since the /sys/class/net//queues/rx-0/rps_cpus entry exists for vlan devices but currently doesn't do anything.  We're also addressing a security concern related to the recent L1TF excitement. >> >> For this case, we want to target the network stack processing to happen on a certain subset of CPUs.  With admittedly only a cursory look through eBPF, I don't see an obvious way to target the packet processing to an alternative CPU, unless we add yet another field to the skb that eBPF/XDP could fill and then query that field in the same time as we currently check get_rps_cpu().  But adding to the skb is usually frowned upon unless absolutely necessary, and this seems like a duplication of what we already have with RPS, so why add a competing feature? >> >> Back to my earlier question: are there any suggestions for how we might accomplish this in a less ugly way? > > > What if you want to have efficient multi queue processing ? > The Vlan device could have multiple RX queues, but you forced queue_mapping=0 This would be easy enough to change to a simple modulus of a recorded queue mapping with the number of queues in the vlan device. We can fix that. > > Honestly, RPS & RFS show their age and complexity (look at net/core/net-sysfs.c ...) > > We should not expand it, we should put in place a new infrastructure, fully expandable. > With socket lookups, we even can avoid having a hashtable for flow information, removing > one cache miss, and removing flow collisions. > > eBPF seems perfect to me. And yet specifying CPUs for processing is exactly what RPS was designed for. > > It is time that we stop adding core infra that most users do not need/use. > (RPS and RFS are default off) For that matter, lots of features are "default off" until someone configures them, and there are lots of features that are only used by a subset of users. In this case, we're trying to use something that already exists and arguably is broken for the vlan case. Are there some technical reasons why this is not a good solution? sln