[ovs-dev] [ovs-discuss] Hackaton follow-up: DPI engine integration proposal

[Justin Pettit]

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