[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 10 Oct 2018 11:23:00 -0700
From: Shannon Nelson <shannon.nelson@...cle.com>
To: Eric Dumazet <eric.dumazet@...il.com>, davem@...emloft.net,
netdev@...r.kernel.org
Cc: silviu.smarandache@...cle.com
Subject: Re: [PATCH net-next] net: enable RPS on vlan devices
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/<dev>/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
Powered by blists - more mailing lists