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. > 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. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
