[vpp-dev] Coverity run FAILED as of 2020-01-10 14:00:24 UTC

[Noreply Jenkins]

Coverity run failed today.

Current number of outstanding issues are 2
Newly detected: 0
Eliminated: 0
More details can be found at  
https://scan.coverity.com/projects/fd-io-vpp/view_defects
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15129): https://lists.fd.io/g/vpp-dev/message/15129
Mute This Topic: https://lists.fd.io/mt/69600770/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] python api over tcp?

[Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via Lists.Fd.Io]

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.

Vratko.

From: Paul Vinciguerra 
Sent: Thursday, January 9, 2020 11:39 PM
To: Ole Troan 
Cc: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) ; 
Christian Hopps ; vpp-dev 
Subject: Re: [vpp-dev] python api over tcp?

My thought was to add a daemon that listened to tls and wrapped the shm 
transport/libapiclient, that would stay coresident with vpp then connect with 
the papi client from a remote system via tls.


On Jan 9, 2020, at 1:38 PM, Ole Troan 
mailto:otr...@employees.org>> wrote:

Hi Paul,


On 9 Jan 2020, at 19:10, Paul Vinciguerra 
mailto:pvi...@vinciconsulting.com>> wrote:

Sounds like a little scope creep going on there.
If you provide protobuf3 encoded api messages to/from vpp, I'll add a grpc 
listener option to vpp_papi, in the interim, I'd be glad to add a tls wrapped 
listener if there is interest.

Were you thinking of adding a simple tls/tcp to uds proxy? Must be something 
off the shelf that can be used. Netcat? Then you want to amend vpp_papi to be 
able to sit at the other end of that? What did you plan to do with security?

The grpc idea isn’t too dissimilar. Just pass vpp api messages encapsulated in 
grpc. One request, one reply and an event message.

Cheers
Ole




On Thu, Jan 9, 2020 at 12:00 PM Ole Troan 
mailto:otr...@employees.org>> wrote:



On 9 Jan 2020, at 16:50, Paul Vinciguerra 
mailto:pvi...@vinciconsulting.com>> wrote:

Is there any objection to adding a tls listener and an instance to the stats 
client to vpp_papi?

Use grpc as transport?

Cheers,
Ole




On Jan 9, 2020, at 6:45 AM, Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at 
Cisco) via Lists.Fd.Io 
mailto:cisco@lists.fd.io>> wrote:

CSIT uses VPP API via socket (tunneled over SSH) for most interactions.

We also read stats for just one (I think) purpose,
reading runtime stats (/sys/node).
The way we do that is historical and convoluted,
for the result see INFO line at [1].

Looking at the result, the appropriate API way
would be to use send some _dump message
and process the _details responses, one per node name.

Vratko.

[1] 
https://logs.fd.io/production/vex-yul-rot-jenkins-1/csit-vpp-perf-verify-master-2n-clx/58/archives/log.html.gz#s1-s1-s1-s1-s1-t1-k2-k9-k1-k1-k4-k1

From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Christian Hopps
Sent: Thursday, January 9, 2020 12:05 PM
To: Ole Troan mailto:otr...@employees.org>>
Cc: Christian Hopps mailto:cho...@chopps.org>>; vpp-dev 
mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] python api over tcp?



> On Jan 9, 2020, at 5:44 AM, Ole Troan 
> mailto:otr...@employees.org>> wrote:
>
> Christian,
>
>>> For exporting data out of the stats segment, I believe there is already 
>>> quite a few solutions.
>>> There's the (naive) prometheus example in the repo, vpp_get_stats, there is 
>>> a Telegraf plugin, a simple gNMI/gRPC plugin.
>>
>> Right I've used vpp_get_stats and may run that with ssh and awk. I guess it 
>> just seems odd on first encountering this that the CLI provided the data, 
>> but the binary API didn't. I suppose the view is that exposing the stats 
>> segment in shared memory *is* the binary API. :)
>
> What certainly would make sense to do, is to put a wrapper on top of 
> vpp_stats.py that gives you a higher level API of accessing the stats.
> E.g. a get_interface_counters(). The stat segment also contains the name to 
> interface index mapping (/if/names).
> Want to have a go?

I'm actually going to use vpp_get_stats (run remotely using ssh) for now. I'm 
using vpp_papi on a single testing serve

Re: [vpp-dev] python api over tcp?

[Paul Vinciguerra]

Hi Ole.

Where can we find the Telegraf plugin?

On Thu, Jan 9, 2020 at 5:44 AM Ole Troan  wrote:

> Christian,
>
> >> For exporting data out of the stats segment, I believe there is already
> quite a few solutions.
> >> There's the (naive) prometheus example in the repo, vpp_get_stats,
> there is a Telegraf plugin, a simple gNMI/gRPC plugin.
> >
> > Right I've used vpp_get_stats and may run that with ssh and awk. I guess
> it just seems odd on first encountering this that the CLI provided the
> data, but the binary API didn't. I suppose the view is that exposing the
> stats segment in shared memory *is* the binary API. :)
>
> What certainly would make sense to do, is to put a wrapper on top of
> vpp_stats.py that gives you a higher level API of accessing the stats.
> E.g. a get_interface_counters(). The stat segment also contains the name
> to interface index mapping (/if/names).
> Want to have a go?
>
> I am also exploring putting much more information into the stat segment,
> essentially making it into an operational data store (RFC8342). Don't hold
> your breath. But any help appreciated.
>
> Cheers,
> Ole
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15131): https://lists.fd.io/g/vpp-dev/message/15131
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]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] dpdk_early_init issue

[Christian Hopps]

I've been looking at dpdk_early_init. I think the only purpose of this function 
is to fail early and unload the plugin. I'm curious how important this might be 
(cant the user just disable it?) and if there might be some way to make it 
optional?

The use case i'm looking at is for testing dpdk crypto w/o root access. More 
broadly, aren't there other times when (e.g., when no physical devices are 
being used -- is this the case when "no-pci" is configured) it would be fine 
for dpdk to be used w/o pagemap access? I don't think the code has access to 
startup config this early to see if the user has configured things correctly, 
but if it does, could we check that before failing?

Thanks,
Chris.-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15132): https://lists.fd.io/g/vpp-dev/message/15132
Mute This Topic: https://lists.fd.io/mt/69615614/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-