netdev - Re: [PATCH net-next] net: ipv6: Add early demux handler for UDP unicast

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]

Message-Id: <1492538948.1052073.948360488.79052FB2@webmail.messagingengine.com>
Date:   Tue, 18 Apr 2017 20:09:08 +0200
From:   Hannes Frederic Sowa <hannes@...essinduktion.org>
To:     David Miller <davem@...emloft.net>, simon.horman@...ronome.com
Cc:     eric.dumazet@...il.com, subashab@...eaurora.org,
        netdev@...r.kernel.org, netdev-owner@...r.kernel.org
Subject: Re: [PATCH net-next] net: ipv6: Add early demux handler for UDP unicast



On Tue, Apr 18, 2017, at 17:16, David Miller wrote:
> From: Simon Horman <simon.horman@...ronome.com>
> Date: Tue, 18 Apr 2017 17:09:04 +0900
> 
> > On Wed, Mar 08, 2017 at 11:22:01AM -0800, Eric Dumazet wrote:
> >> On Wed, 2017-03-08 at 12:11 -0700, Subash Abhinov Kasiviswanathan wrote:
> >> > On 2017-03-08 11:40, Eric Dumazet wrote:
> >> > > Well, this 'optimization' actually hurts when UDP sockets are not
> >> > > connected, since this adds an extra cache line miss per incoming 
> >> > > packet.
> >> > > 
> >> > > (DNS servers for example)
> >> > 
> >> > Hi Eric
> >> > 
> >> > Thanks for your comments. Would it be preferable to disable early demux 
> >> > for the
> >> > servers with large unconnected workloads in that case?
> >> 
> >> Well, many servers handle both TCP and UDP.
> >> 
> >> For TCP, there is no question about early demux, this is definitely a
> >> win.
> >> 
> >> We probably should have one sysctl to enable TCP early demux, one for
> >> UDP early demux.
> > 
> > If early demux is a clear win for TCP then I wonder if it is
> > unnecessary and by some leap also undesirable to have a configuration
> > knob for that case.
> 
> For forwarding workloads it is pure overhead since the early demux will
> never find a local socket, and therefore it is wasted work.

Also for some more complicated fib rules setups the early demux logic
could end up causing doing wrong lookups, because some route might not
be actually local in one fib rule but it is in another one.

Bye,
Hannes