Hi, I updated the flowtable on github <https://github.com/GabrielGanne/vpp-flowtable> and on vppsb (in review) to take all these remarks into account.
The flowtable had some dependencies on the test node I used (portmirroring) which should now be fixed. It should be completely independent now. I'll see how to make sure the portmirroring node behaves correctly depending on its position in the graph node later. Best Regards, On 11/25/16 14:22, gannega wrote: > Thanks Damjan. > > I'll keep those examples in mind to make sure nothing bad can happen. > > > On 11/25/16 14:09, Damjan Marion wrote: >> As long as you have good understanding what nodes in the middle are doing >> you should be fine. >> >> Likely most complicated case is with node A before FIB lookup and node C >> after. FIB >> might send your frames to different encap nodes which may overwrite opaque, >> one candidate >> is definitely ipsec which uses opaque for storing security associations. >> >> >>> On 24 Nov 2016, at 13:27, gannega <gabriel.ga...@qosmos.com> wrote: >>> >>> The flowtable uses the opaque buffer for two things: >>> - it provides a flow id, and a flow state >>> - it provides an opaque buffer to be filled with information external to >>> vpp (which in my case is dpi metadatas, but it could be anything) using >>> the binary API. >>> >>> So the flowtable (node A) alone will provides flow-level information, >>> but does not do anything with them, and any other subsequent node (node >>> C) can make use of this data. >>> >>> In my specific use case, there is nothing between A and C, and all the >>> packets go from A to C. >>> But, if a node B were to overwrite the data written by the flowtable, >>> then it would be up to C to know it and act consequently, right ? >>> >>> Regards, >>> >>> On 11/24/16 12:36, Damjan Marion wrote: >>>> both opaque and opaque2 are shared resource. There is no guarantee >>>> that node in the middle will not overwrite it. >>>> >>>> Is your situation really a case where node A needs to send some >>>> information to node C and there is >>>> unknown B or many Bs in the middle? >>>> >>>> >>>>> On 23 Nov 2016, at 15:15, gannega <gabriel.ga...@qosmos.com >>>>> <mailto:gabriel.ga...@qosmos.com>> wrote: >>>>> >>>>> Thanks for the explanation. >>>>> >>>>> So I can use anything I want within the opaque buffer as long as I don't >>>>> presume what happens next. >>>>> >>>>> And ... I'm actually doing things I should not in the flowtable (which >>>>> wasn't obvious to me until you explained it that way) ... so I'll go fix >>>>> that. >>>>> >>>>> >>>>> Thanks again, >>>>> >>>>> Best regards, >>>>> >>>>> >>>>> On 11/23/16 14:55, Keith Burns wrote: >>>>>> On Wed, Nov 23, 2016 at 5:23 AM gannega <gabriel.ga...@qosmos.com >>>>>> <mailto:gabriel.ga...@qosmos.com> >>>>>> <mailto:gabriel.ga...@qosmos.com>> wrote: >>>>>> >>>>>> Hi Keith, >>>>>> >>>>>> This is a kind reminder. >>>>>> >>>>>> >>>>>> Apologies for tardiness... >>>>>> >>>>>> >>>>>> Also, I stumbled upon VPP-320, and especially >>>>>> https://gerrit.fd.io/r/#/c/1676/ which adds a 6 Bytes of >>>>>> plugin_metadata >>>>>> in the opaque1 union, which has been reopened for nsh-proxy. >>>>>> >>>>>> >>>>>> I guess the real issue here is that we should only presume the >>>>>> existence of things that we know to exist :-P (Oooooohhhhhm, tree >>>>>> falling in the woods, sound of one hand clapping). >>>>>> >>>>>> Simply put, lets assume nodes A -> B -> C -> D (in that order). >>>>>> >>>>>> Ideally opaque metadata from node A -> "something else" should only >>>>>> tell "something else" about some kind of state from node A. >>>>>> >>>>>> ie node A writes into opaque "the state of A is red" with the >>>>>> intention that this means something to a later node (ie node C drops >>>>>> packets when state is "red") >>>>>> >>>>>> What it should avoid doing is: >>>>>> >>>>>> node A writes into opaque "node C should do this". >>>>>> >>>>>> In the case where node C is a plugin, which are by definition >>>>>> "optional", this should be verboten. >>>>>> >>>>>> At some point we may want to add/subtract nodes from the graph post >>>>>> run-time init. If we have a scheme that assumes the existence of some >>>>>> later node "bad things" (tm) will happen, IMHO. >>>>>> >>>>>> So node A exists, (Cogito, ergo sum... or maybe "Puto esse ego" - I >>>>>> think I exist?) therefore it's ok for it to say things about it's >>>>>> state or the things preceding it. >>>>>> >>>>>> >>>>>> I feel this might be a good way to go which would ensure no collision >>>>>> between the uses of the flowtable and the rest of vpp (if such was >>>>>> indeed your fear). >>>>>> >>>>>> >>>>>> Collisions can be avoided with interface feature awareness, no ? >>>>>> >>>>>> >>>>> -- >>>>> Gabriel Ganne >>> -- >>> Gabriel Ganne >>> > -- > Gabriel Ganne -- Gabriel Ganne 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é. _______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
