On Wed, Nov 23, 2016 at 5:23 AM gannega <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 ?
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
