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 >>> >>> 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 <mailto:vpp-dev@lists.fd.io> >>> https://lists.fd.io/mailman/listinfo/vpp-dev >> > > -- > 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
