> On Feb 27, 2020, at 11:45 AM, Neale Ranns (nranns) <nra...@cisco.com> wrote: > > > Hi Chris, > > There is a design philosophy against sending notifications to agents about > information that comes from agents. This is in contrast to notifications to > agents about events that occur in the data-plane, like DHCP lease, new > ARP/ND, learned L2 addresses, etc.
That doesn't really help me understand and worries me more. Would providing the same functionality as exists in the netlink socket (for routes and interfaces) be against VPP design philosophy? Thanks, Chris. > > /neale > > From: <vpp-dev@lists.fd.io> on behalf of Christian Hopps <cho...@chopps.org> > Date: Thursday 27 February 2020 at 16:32 > To: "Neale Ranns (nranns)" <nra...@cisco.com> > Cc: Christian Hopps <cho...@chopps.org>, "vpp-dev@lists.fd.io" > <vpp-dev@lists.fd.io> > Subject: Re: [vpp-dev] Can I submit some API changes for 19.08, et al. > release branches? > > > > > On Feb 27, 2020, at 9:41 AM, Neale Ranns via Lists.Fd.Io > > <nranns=cisco....@lists.fd.io> wrote: > > > > > > > > From: <vpp-dev@lists.fd.io> on behalf of Christian Hopps <cho...@chopps.org> > > Date: Thursday 27 February 2020 at 15:16 > > To: "Neale Ranns (nranns)" <nra...@cisco.com> > > Cc: Christian Hopps <cho...@chopps.org>, Andrew 👽 Yourtchenko > > <ayour...@gmail.com>, "Dave Barach (dbarach)" <dbar...@cisco.com>, vpp-dev > > <vpp-dev@lists.fd.io> > > Subject: Re: [vpp-dev] Can I submit some API changes for 19.08, et al. > > release branches? > > > > [snip] > > > > > > In my case we're not really talking about an API that is "bleeding edge", > > > but rather "waited around for someone to need/implement it". Doing a > > > route/fib entry lookup isn't very bleeding edge given what VPP does. :) > > > > > > True 😊 but the general usage model for VPP is that there is one > > > agent/client giving it all the state it needs to function. So why would > > > that agent need lookup functions, it has all the data already. The dump > > > APIs serve to repopulate the agent with all state should it crash. > > > > I suppose that's why I needed to add this API then. :) > > > > We're using VPP more like a replacement for the kernel networking stack, > > with multiple networking clients interfacing to it, rather than just one > > monolithic application. > > > > Ok. Just don’t fall into the pit that is ‘I want VPP to tell client X when > > client Y does something’ – VPP is not a message bus 😊 > > I'd like to be careful here. If VPP is serving as a replacement for the > networking stack with multiple clients interfacing to it, then it does serve > as the single-source-of-truth on things like interface state, routes, etc. > So, I do want to hear inside my IKE daemon from VPP that a route, intefrace, > etc, may have changed, I don't want to have to interface the IKE daemon to N > possible pieces of software that might modify routes, interfaces, etc. > > I'm only being careful here b/c if one looks at e.g., netlink functionality > and then at the VPP api there are some gaps (e.g., interface address add/del > and route add delete events are missing I believe). I'm assuming that these > gaps exist b/c, as you say, people have generally not needed them, but not > b/c there a design philosophy against them. > > Thanks, > Chris. > > > > > /neale > > > > > > Thanks, > > Chris. > > > > > > > > /neale > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15596): https://lists.fd.io/g/vpp-dev/message/15596 Mute This Topic: https://lists.fd.io/mt/71535081/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
