On Nov 24, 2011, at 9:20 PM, Stephen Hemminger wrote:
>> This can be achieved easily with zero changes to the kernel code.
>> You need to have default filters that redirect flows to user space
>> when you fail to match.
>
> Actually, this is what puts me off on the current implementation.
> I would prefer that the kernel implementation was just a software
> implementation of a hardware OpenFlow switch. That way it would
> be transparent that the control plane in user space was talking to kernel
> or hardware.
A big difficulty is finding an appropriate hardware abstraction. I've worked
on porting Open vSwitch to a few different vendors' switching ASICs, and
they've all looked quite different from each other. Even within a vendor,
there can be fairly substantial differences. Packet processing is broken up
into stages (e.g., VLAN preprocessing, ingress ACL processing, L2 lookup, L3
lookup, packet modification, packet queuing, packet replication, egress ACL
processing, etc.) and these can be done in different orders and have quite
different behaviors. Also, the size of the various tables varies widely
between ASICs--even within the same family.
Hardware typically makes use of TCAMs, which support fast lookups of wildcarded
flows. They're expensive, though, so they're typically limited to entries in
the very low thousands. In software, we can trivially store 100,000s of
entries, but supporting wildcarded lookups is very slow. If we only use
exact-match flows in the kernel (and leave the wildcarding in userspace for
kernel misses), we can do extremely fast lookups with hashing on what becomes
the fastpath.
Using exact-match entries has another big advantage: we can innovate the
userspace portion without requiring changes to the kernel. For example, we
recently went from supporting a single OpenFlow table to 255 without any kernel
changes. This has an added benefit that a flow requiring multiple table
lookups becomes a single hash lookup in the kernel, which is a huge performance
gain in the fastpath. Another example is our introduction of a number of
metadata "registers" between tables that are never seen in the kernel, but open
up a lot of interesting applications for OpenFlow controller writers.
If you're interested, we include a porting guide in the distribution that
describes how one would go about bringing Open vSwitch to a new hardware or
software platform:
http://openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=blob;f=PORTING
Obviously, it's not that relevant here, since there's already a port to Linux.
:-) But we've iterated over a few different designs and worked on other ports,
and we've found this hardware/software abstraction layer to work pretty well.
In fact, multiple ports of Open vSwitch have been done by name-brand third
party vendors (this is the avenue most vendors use to get their OpenFlow
support) and are now shipping.
We're always open to discussing ways that we can improve this interfaces, too,
of course!
--Justin
_______________________________________________
dev mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/dev
