On 9/18/23 20:24, Ilya Maximets wrote:
On 9/12/23 15:47, Eelco Chaudron wrote:
On 12 Sep 2023, at 15:19, Robin Jarry wrote:
Eelco Chaudron, Sep 12, 2023 at 09:17:
I feel like if we do need another way of getting (real time)
statistics out of OVS, we should use the same communication channel as
the other ovs-xxx utilities are using. But rather than returning
text-based responses, we might be able to make it JSON (which is
already used by the dbase). I know that Adrian is already
investigating machine-readable output for some existing utilities,
maybe it can be extended for the (pmd) statistics use case.
Using something like the DPDK telemetry socket, might not work for
other use cases where DPDK is not in play.
Maybe the telemetry socket code could be reused even when DPDK is not in
play.
Many distributions like Debian and Ubuntu do not even build their main
OVS packages with DPDK. They have a separate DPDK-enabled package. So,
this telemetry will not be available. Also, in order to use telemetry,
you need to initialize DPDK, which is a heavy and completely unnecessary
operation if DPDK is not going to be used.
It already has all the APIs to return structured data and
serialize it to JSON. It would be nice not to have to reinvent the
wheel.
Both OVSDB and appctl are literally JSON-RPC protocols. There is no need
to re-invent anything.
Right. Isn't appctl simpler in this case? IIUC, it would still satisfy the
requirements: client decides update interval, flexible schema, etc with the
benefits of incurring in less cost (no ovs-vswithcd <-> ovsdb communication, no
need to store data in both places) and probably involving less internal code change.
Just to clarify: I'm referring to allowing JSON output of the (already JSON-RPC)
appctl protocol.
But this is a new type of connecting into OVS, and I feel like we should keep
the existing infrastructure, and not add another connection type. This would
make it easy for existing tools to also benefit from the new format over the
existing connection methods.
Any input from others in the community?
I agree, addition of a new connection type doesn't look good to me either.
I had considered using ovsdb but it seemed to me
less suitable for a few reasons:
* I had understood that ovsdb is a configuration database, not a state
reporting database.
OVSDB already reports port statistics and some system stats, so
it's fine to expose things like that. They are usually ephemeral
columns that do not end up written on disk.
* To have reliable and up to date numbers, ovs would need to push them
at high rate to the database so that clients to get outdated cpu
usage. The DPDK telemetry socket is real-time, the current numbers are
returned on every request.
There is a mechanism to wait for ovs-vswitchd reply on request.
So, ovs-vswitch may update stats in the database the moment they
were requested by the client. Should not be an issue. This is
working today for port status and some other things.
* I would need to define a custom schema / table to store structured
information in the db. The DPDK telemetry socket already has a schema
defined for this.
It's true that we'll need some new columns and maybe a table, but
that should not be hard to do. And it's even better because we'll
be able to define columns that make sense for OVS.
* Accessing ovsdb requires a library making it more complex to use for
telemetry scrapers. The DPDK telemetry socket can be accessed with
a standalone python script with no external dependencies[1].
Accessing OVSDB doesn't require a library, it's just a JSON-RPC [1].
We do provide our own implementation of the protocol, but there
is no need to use it, especially for basic "list-all" type of requests.
Most languages like python have built-in JSON libraries. Some have
JSON-RPC libraries.
[1] https://www.rfc-editor.org/rfc/rfc7047
Best regards, Ilya Maximets.
--
Adrián Moreno
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
