netdev - [PATCH net-next 0/2] ufp: UDP Fast Port

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>] [day] [month] [year] [list]

Date:	Sat, 26 Jul 2014 15:29:18 -0700 (PDT)
From:	Tom Herbert <therbert@...gle.com>
To:	davem@...emloft.net, netdev@...r.kernel.org
Subject: [PATCH net-next 0/2] ufp: UDP Fast Port

This patch set implements a fast path for UDP receive and enables
that for VXLAN. The idea is to perform a simple demux lookup on
the received destination port which is done in lieu of performing a
normal socket lookup on a match. This is modeled after the packet_type
lookup mechanism (including registeration functions). The advantage of
this is that we don't need to perform a socket lookup or access the
socket (paricularly avoids expensive socket references).

The primary use of this is expected to be UDP tunneling where the
UDP header is nothing more than a shim and demux is always done on
destination port. The mechanism is essentially equivalent to binding
to the port and INADDR_ANY. When used this will overshadow connected
sockets on the same port, and more specific bindings (like local
address). A user of this interface should do a normal bind to the
port and INADDR_ANY before registering the port for UFP.

Performance results with VXLAN using UFP. Tested with super_netperf
using 200 TCP_RR streams.

Without UFP
  94.57 CPU utilization
  153/245/455 90/95/995% latencies
  1.18699e+06 tps

With UFP enabled
  94.58 CPU utilization
  147/230/408 90/95/995% latencies
  1.20311e+06 tps

Also verified no noticeable regression using normal UDP sockets.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html