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

[Justin Pettit]

Thanks for the patch, Franck.  I had a look, and I noticed a few things:

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

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

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

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

--Justin


Franck BAUDIN wrote:
> Hi,
>
> Please find attached a patch proposal adding a DPI engine in
> openvswitch. The patch doesn’t include the DPI engine and has been
> tested with Qosmos ixEngine, but is not tight to Qosmos in any way: see
> lib/dpi.h and lib/dpi.c in the patch.
>
> This tiny patch demonstrates how to inject just enough packet in the DPI
> engine (as DPI processing can be CPU consuming), but is hooked on all
> new flow creation. But it would be better to inject only targeted
> packets in the DPI, by adding a new OpenFlow non terminal “dpi” output
> action. For instance:
>
> ovs-ofctl add-flow br0 in_port=1,action=dpi,resubmit(,1)
>
> To keep in mind for later discussions: how can we extend OpenFlow
> matcher with the DPI classification result? Via new OXM that we could
> call Application eXtensible Matchers (AXM)? For instance:
>
> ovs-ofctl add-flow br0 dpi_appid=0x1234/0xF000,action=resubmit(,2)
>
> 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
> discuss at openvswitch.org
> http://openvswitch.org/mailman/listinfo/discuss