> On Feb 28, 2020, at 5:06 AM, Neale Ranns (nranns) <nra...@cisco.com> wrote: > > > 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.
Ok. That's interesting. In the end this is about building things right? Here's my $.02: - VPP provides packet processing as part of this it: - Provides a FIB. - Owns and provides interfaces which have addresses - Moves packets between interfaces based on the FIB. - It does a ton of other really non-ASICy stuff too but let's keep it simple - A good interface for managing the above resources allows multiple non-conflicting clients. - Multiple clients should not have to have a full-mesh of connectivity and knowledge of each others state to infer the state that exists inside VPP. A good example of an API for the above is rtnetlink http://man7.org/linux/man-pages/man7/rtnetlink.7.html BSD has one as well https://www.freebsd.org/cgi/man.cgi?query=route&sektion=4&manpath=netbsd These APIs (to the same resources VPP provides -- FIB and Interfaces) work well and allow for multiple applications that do different things all to be written easily and be plugged together. This would not be possible if all those applications had to have intimate knowledge and communicate between of each other. It's just a good design. I would call this an API to a shared resource. Calling it a message bus feels more like the seed for an April 1st RFC. I don't think it helps get a good API built to focus on how it could be misused. Just because one *could* use an API to a shared resource to exchange information (odd as that would be to do) doesn't mean that the API is broken, it just means someone would be misusing it. Thanks, Chris. > 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 (#15605): https://lists.fd.io/g/vpp-dev/message/15605 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] -=-=-=-=-=-=-=-=-=-=-=-
