netdev - Re: [PATCH net-next] net: enable RPS on vlan devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 10 Oct 2018 09:18:05 -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/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?

sln