On 06/03/2024 20:10, Andrew Lunn wrote:

quoted

quoted

quoted

Right, so this in general makes sense. The only question i have now
is, should you be using rtnl_link_stats64. That is the standard
structure for interface statistics.

@Andrew: do you see how I could return/send this object per-peer to
userspace?
I think the whole interface stats logic is based on the one-stats-per-device
concept. Hence, I thought it was meaningful to just send my own stats via
netlink.

Ah, interesting. I never looked at the details for
rtnl_link_stats64. It is buried in the middle of ifinfo. So not very
reusable :-(

Idea #2:

A peer is not that different to an interface queue. Jakub recently
posted some code for that:

https://lwn.net/ml/netdev/20240229010221.2408413-2-kuba@kernel.org/

Maybe there are ideas you can borrow from there.

But lets look at this from another direction. What are the use cases
for these statistics? Does the userspace daemon need them, e.g. to
detect a peer which is idle and should be disconnected? Are they
exported via an SNMP MIB?

Yes, they are used by userspace. Main usecases are:
* inactivity timeout (if configured, when less than N bytes are 
transferred in a given time the client will be disconnected)
* stats reporting during connection (during the life of a peer, stats 
can be periodically pulled by the user for reporting purposes)
* stats reporting at disconnection (stats are pulled upon disconnection 
in order to report the total traffic related to a peer)

These stats can be reported via a status file or via the "management 
interface" (an interactive interface that can be used to issue live 
commands to a running openvpn daemon).

How this data is actually used is up to the user.

Regards,

	Andrew

-- 
Antonio Quartulli
OpenVPN Inc.