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