From: Tom Herbert <tom@herbertland.com>
To: <davem@davemloft.net>, <agartrell@fb.com>, <maheshb@google.com>,
<tgraf@suug.ch>, <netdev@vger.kernel.org>
Subject: [RFC net-next 0/6] net: Identifier Locator Addressing
Date: Wed, 3 Jun 2015 12:58:16 -0700 [thread overview]
Message-ID: <1433361502-3478761-1-git-send-email-tom@herbertland.com> (raw)
This patch set provides rudimentary support for Identifier Locator
Addresssing or ILA. The basic concept of ILA is that we split and IPv6
in to a 64 bit locator and 64 bit identifier. The identifier is the
identity of an entity in communication ("who") and the locator
expresses a the location of the entity ("where"). Applications
use externally visible address that contains the identifier.
When a packet is actually sent, a translation is done that
overwrites the first 64 bits of the address with a locator.
The packet can the be forwarded over the network to the host where
the addressed entity is located. At the receiver, the reverse
transation is done so the that the application sees the original,
untranslated address. Presumably an external control plane will
provide identfier->locator mapping.
The data path for ILA is a simple NAT translation that only operates
on the upper 64 bits of a destination address in IPv6 packets. The
basic process is:
1) Lookup 64 bit identifier (lower 64 bits of destination) in a table
2) If a match is found
a) Overwrite locator (upper 64 bits of destination) with
new locator
b) Adjust any checksum that has destination address included in
pseudo header
3) Send or receive packet
ILA is a means to implement tunnels or network virtualization without
encapsulation. Since there is no encapsulation involved, we assume that
statelss support in the network for IPv6 (e.g. RSS, ECMP, TSO, etc.)
just works. Also, since we're minimally changing the packet many of
the worries about encapsulation (MTU, checksum, fragmentation) are
not relevant. The downside is that, ILA is not extensible like other
encapsulations (GUE for instance) so it might not be appropriate for
all use cases. Also, this only makes sense to do in IPv6!
A key aspect of ILA is performance. The intent is that ILA would be
used in data centers in virtualizing tasks or jobs. In the fullest
incarnation all intra data center communications might be targeted to
virtual ILA addresses. This is basically adding a new virtualization
capability to the existing services in a datacenter, so there is a
strong expectation is that this does not degrade performance
for applications.
Performance seems to be dependent on how ILA is hooked into kernel.
This patch set includes IPtables, hacked up IPvlan, and a "special
route" that calls directly into ILA module from where PRE and
POST routing NF_HOOKs are. The best of these performance-wise
is the special hook which seems to be ~2-3% loss of performance
compared to native non-ILA. The other two are ~5% loss. My hope is
to get a solution with <1% performance loss.
Performance testing:
Performing netperf TCP_RR with 200 clients:
Non-ILA baselin
83.95% CPU utilization
1729209.7 99.3 178.6 363.9
Special route
84.63% CPU utilization
1685847.2 tps -2.5%
102/182/367 50/90/99% latencies
IPVL hook
84.78% CPU utilization
1638595.9 -5.5%
106/187/374 50/90/99% latencies
IPtables
85.10% CPU utilization
1634015.5 tps -5.8%
105/188/380 50/90/99% latencies
References:
Slides from netfconf:
http://vger.kernel.org/netconf2015Herbert-ILA.pdf
Slides from presentation at IETF:
https://www.ietf.org/proceedings/92/slides/slides-92-nvo3-1.pdf
I-D:
https://tools.ietf.org/html/draft-herbert-nvo3-ila-00
Also, ILA is very much liek ILNP data plane.
Tom Herbert (6):
net: Checksum functions to replace 8 bytes at a time
net: Identfier Locator Addressing module
net: Special routing hook
net: ILA use special route hook
net: ILA iptables target
ipvlan: Call ILA in incoming and outgoing receive paths
drivers/net/ipvlan/ipvlan.h | 1 +
drivers/net/ipvlan/ipvlan_core.c | 27 ++-
drivers/net/ipvlan/ipvlan_main.c | 4 +
include/net/checksum.h | 3 +
include/net/ila.h | 7 +
include/net/ip6_route.h | 22 ++
net/core/utils.c | 19 ++
net/ipv6/Kconfig | 8 +
net/ipv6/Makefile | 1 +
net/ipv6/ila.c | 509 +++++++++++++++++++++++++++++++++++++++
net/ipv6/ip6_input.c | 3 +
net/ipv6/ip6_output.c | 24 +-
net/ipv6/route.c | 51 ++++
net/ipv6/xfrm6_input.c | 4 +
net/netfilter/Kconfig | 11 +
net/netfilter/Makefile | 1 +
net/netfilter/xt_ILA.c | 82 +++++++
17 files changed, 767 insertions(+), 10 deletions(-)
create mode 100644 include/net/ila.h
create mode 100644 net/ipv6/ila.c
create mode 100644 net/netfilter/xt_ILA.c
--
1.8.1
next reply other threads:[~2015-06-03 19:58 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-03 19:58 Tom Herbert [this message]
2015-06-03 19:58 ` [RFC net-next 1/6] net: Checksum functions to replace 8 bytes at a time Tom Herbert
2015-06-03 19:58 ` [RFC net-next 2/6] net: Identfier Locator Addressing module Tom Herbert
2015-06-04 8:58 ` Thomas Graf
2015-06-04 10:02 ` Hannes Frederic Sowa
2015-06-03 19:58 ` [RFC net-next 3/6] net: Special routing hook Tom Herbert
2015-06-04 7:40 ` Hannes Frederic Sowa
2015-06-03 19:58 ` [RFC net-next 4/6] net: ILA use special route hook Tom Herbert
2015-06-03 19:58 ` [RFC net-next 5/6] net: ILA iptables target Tom Herbert
2015-06-03 19:58 ` [RFC net-next 6/6] ipvlan: Call ILA in incoming and outgoing receive paths Tom Herbert
2015-06-04 8:58 ` Thomas Graf
2015-06-04 9:00 ` [RFC net-next 0/6] net: Identifier Locator Addressing Thomas Graf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1433361502-3478761-1-git-send-email-tom@herbertland.com \
--to=tom@herbertland.com \
--cc=agartrell@fb.com \
--cc=davem@davemloft.net \
--cc=maheshb@google.com \
--cc=netdev@vger.kernel.org \
--cc=tgraf@suug.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).