Hi Chris, In my opinion it would be contrary to the design philosophy.
My reasoning is this. VPP is a forwarder, it's place in the network stack is the SW ASIC equivalent. It's primary goal is thus to forward packets as fast as possible, it's secondary goal is to be programmable as fast as possible (particularly for routes, of which there can be millions). Any other functions that might be expected of VPP that run against these objectives are not 'allowed'. Being a messages bus, netlink broadcaster etc is against its second objective - we don't want to spend cycles broadcasting/multicasting notifications from client x to a set of clients y through a set of filters z. Of course that's not to say one can't build a multicasting layer on top of VPP, in a separate process, that performs these functions. Please also note: https://wiki.fd.io/view/VPP/RM when considering using multiple clients with VPP. Naturally, my opinion is but one of many... /neale On 27/02/2020 17:56, "Christian Hopps" <cho...@chopps.org> wrote: > 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 (#15603): https://lists.fd.io/g/vpp-dev/message/15603 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] -=-=-=-=-=-=-=-=-=-=-=-
