Franck BAUDIN wrote:
- It requires OVS to link against the library. We don't want to link
against third-party libraries, and I don't think this will work for most
distributions anyway, unless you're planning to upstream a library to the
various Linux distributions.
The DPI library itself is loaded via dlopen, so there is no "link" to a third
party library. Moreover, I propose a generic DPI API (BWT, comments welcome on the API!):
any DPI engine could be plugged via a thin wrapper to this simple and compact API. For
instance ndpi (open source DPI library) . Also, this API could be reused in any vswitch
or any stack.
This would still require some sort of stable API.
- It requires that new flows continue to be sent to userspace. This
may have worked before megaflows (although the performance would be
even worse, since we're delaying packet set up even longer), but it's
something that we can't go back to now. Performance is just too critical.
This can be addressed with the new Openflow "dpi" action: the megaflow could be
partially disabled by the action for the matching flow only (5-tuple only).
As mentioned below, this will still cause bad megaflows.
- Based on this mechanism, when you've white-listed a flow, it will be
based on at least a five-tuple, which means megaflows in the kernel will
always include the L4 port. This means when this is enabled, it will
essentially
bring the performance back to pre-megaflow levels.
You mean the datapath lookup, right?
Correct.
Based on a prior conversation, I thought we were looking at integrating in the
kernel. That still seems like the best approach, since it would take care of
these the above concerns.
The problem with this approach is that all flows will be processed by the DPI,
with performance impact. Targeted DPI is not possible in the case that you
propose, at least with an OpenFlow rule.
I was thinking that the kernel module would be responsible for
determining whether it needed to look at the packet itself. It could
contain a 5-tuple (or more likely a 5-tuple plus context) and ignore the
packet if classification has occurred. It wouldn't depend on OVS's flow
table.
I spoke with Jesse, and he thinks we could only
supply the necessary hooks, though, if the DPI engine (or at least the pass-
thru mechanism to the DPI engine in
userspace) was upstreamed. Have you looked into doing that?
Not yet, it would be great if Jesse gave me some insight about the
implementation he has in mind. Maybe there is an elegant way to implement
selective DPI, but I just don't see how now.
I think what he had in mind is that the kernel supports DPI, and then we
hook into that. Similar to what I proposed at the hackfast for
conntrack support.
With megaflows, on flow tables that looked at the L4 ports, we saw at
least an order of magnitude flow setup performance increase (and in some
cases orders of magnitude). Any proposal which removes the ability to
use megaflows for a significant number of flows is a non-starter.
(I moved the thread to the ovs-dev mailing list, since that's a more
natural place to have this.)
--Justin
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
