On Wed, Nov 23, 2016 at 6:15 AM 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. > Well... not exactly... there's lots of comments explaining what each field is union'd for. But there is an opaque2 you can use but its going to be on another cacheline... I'd suggest having a look at Dave Barach's metadata buffer video from devboot https://wiki.fd.io/view/Events/Training-2016-04-Content DevBoot 3.1 > > 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>> 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 https://lists.fd.io/mailman/listinfo/vpp-dev
