> 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 (#15592): https://lists.fd.io/g/vpp-dev/message/15592
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]
-=-=-=-=-=-=-=-=-=-=-=-
  • ... Christian Hopps
    • ... Dave Barach via Lists.Fd.Io
      • ... Andrew Yourtchenko
        • ... Christian Hopps
          • ... Andrew Yourtchenko
            • ... Christian Hopps
              • ... Andrew Yourtchenko
              • ... Neale Ranns via Lists.Fd.Io
                • ... Christian Hopps
                • ... Neale Ranns via Lists.Fd.Io
                • ... Christian Hopps
                • ... Neale Ranns via Lists.Fd.Io
                • ... Christian Hopps
                • ... Neale Ranns via Lists.Fd.Io
                • ... Christian Hopps
                • ... Neale Ranns via Lists.Fd.Io
              • ... Neale Ranns via Lists.Fd.Io
        • ... Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via Lists.Fd.Io
          • ... Andrew Yourtchenko
            • ... Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via Lists.Fd.Io
            • ... Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via Lists.Fd.Io

Reply via email to