> This should be done as an intermediate agent. I have a hypothetical question. (I am not trying to be cheeky. I feel there may be a difference, I just do not see it.)
Imagine a world where VPP supports (CLI via vppctl and) binary API only over shared memory. No support for binary API over Unix Domain Socket. (Sockets are only used for getting file descriptors, so interaction via shared memory can start.) And imagine there is a discussion on how to make binary API available for remote users. Somebody suggests adding UDS as the new way to exchange binary API messages (in network byte order). Would that suggestion also result in "This should be done as an intermediate agent." and "I don't think this should go into the main VPP executable."? Vratko. From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Ole Troan Sent: Tuesday, January 14, 2020 12:29 PM To: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpo...@cisco.com> Cc: Paul Vinciguerra <pvi...@vinciconsulting.com>; Christian Hopps <cho...@chopps.org>; vpp-dev <vpp-dev@lists.fd.io> Subject: Re: [vpp-dev] python api over tcp? Hi Vratko, > In my eyes, this e-mail thread contains two largely independent questions. > > The first question is how we can make stats available over a "wire". > Remote user asks over the wire, the request is seen on VPP side of the wire > as a byte sequence. > Some (currently missing) VPP code parses that request, > looks into the shared memory, and serializes the requested stats > into a response (sequence of bytes), put to the wire for user to read from. > > Ssh + vpp_get_stats acts as a wire, but the format is human (not machine) > friendly. > Similarly to how CLI is less machine friendly than binary API. > > I expect the first implementation of machine friendly "stats over wire" > to use Unix Domain Socket as the wire, just because VPP already has > a dispatcher for handling binary messages of prescribed type there. > Also, UDS has smaller overhead than other wires, > especially if VPP is in a container. > > A sub-question is whether to support explicit polling, > or subscribing for notifications (or both). > In CSIT we want explicit polling. > > The second question is what wire is the best for stats transport. > (And whether we should add support for more wire types.) > > There's the (naive) prometheus example in the repo, vpp_get_stats, > > there is a Telegraf plugin, a simple gNMI/gRPC plugin. > > I suspect the Prometheus example is for publish/subscribe, > and vpp_get_stats is for explicit polling. > Not sure about the others. This should be done as an intermediate agent. E.g. like: https://github.com/vpp-telemetry-pfe/gnmi-grpc Or the example Prometheus server. I'd imagine both push and pull would have to be supported. But I don't think this should go into the main VPP executable. Best regards, Ole
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15159): https://lists.fd.io/g/vpp-dev/message/15159 Mute This Topic: https://lists.fd.io/mt/69538850/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
