Hi Justin,

Thanks for your feedback!

>       - 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.

>       - 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).

>       - 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.

> 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

Reply via email to