On 03/27/2014 06:27 PM, Franck BAUDIN wrote:
Hi Justin,
Thanks for your feedback!
I see you are coding as root. I too like to live dangerously ;-)
- 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.
Decoupled from the kernel vs user space discussion:
Did you consider reversing the API and allowing for external modules to
register a callback function for a specific hook? That would allow for
multiple modules to use a hook at the same time.
- 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).
Do you intend to insert a dpi action for every unknown flow or are you
only interested in targeted DPI for very specific flows?
It would be great if you could provide some additional details here.
From what I've read so far it is unclear to me how new flows can be
selected for DPI without negating the megaflow performance gains.
- 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?
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.
One possible idea that comes to mind is a DPI table that is inserted
before the first wildcard table that is used to do selective DPI by
inserting flows with userspace actions. These flows get removed after
inspection.
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.
Best Regards,
Franck
This message and any attachments (the "message") are confidential, intended
solely for the addressees. If you are not the intended recipient, please notify the
sender immediately by e-mail and delete this message from your system. In this case, you
are not authorized to use, copy this message and/or disclose the content to any other
person. E-mails are susceptible to alteration. Neither Qosmos nor any of its subsidiaries
or affiliates shall be liable for the message if altered, changed or falsified.
Ce message et toutes ses pièces jointes (ci-après le "message")sont
confidentiels et établis à l'intention exclusive de ses destinataires. Si vous avez reçu
ce message par erreur, merci d’en informer immédiatement son émetteur par courrier
électronique et d’effacer ce message de votre système. Dans cette hypothèse, vous n’êtes
pas autorisé à utiliser, copier ce message et/ou en divulguer le contenu à un tiers. Tout
message électronique est susceptible d'altération. Qosmos et ses filiales déclinent toute
responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié.
_______________________________________________
discuss mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/discuss
_______________________________________________
discuss mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/discuss
