Thread (4 messages) flat view 4 messages, 4 authors, 2012-08-23

Re: [RFC] Interface for TCP Metrics

From: David Miller <davem@davemloft.net>
Date: 2012-08-23 05:48:00

From: Julian Anastasov <ja@ssi.bg>
Date: Sun, 19 Aug 2012 14:42:15 +0300 (EEST)
- will use genl with TCP_METRICS_GENL_NAME "tcp_metrics",
TCP_METRICS_GENL_VERSION 0x01
Sounds good.
- provide dumpit method and one cmd to read metrics by exact addr,
will use TCP_METRICS_CMD_{GET,...} and TCP_METRICS_ATTR_xxx in
new file include/linux/tcp_metrics.h
Ok.

Eric thinks we can filter in userspace, but since it's so easy to
lookup entries in the kernel and the demux for that is already there,
I have no objections to have a bonafide netlink operation for
getting a single entry.
- Is command to delete cached entry needed? Delete will need
new rcu_head. Useful to flush the cache or to delete entries
with filter.
Having a way to flush the entire table is useful.  Specific entries,
is less useful.
- without support for delete cmd, may be we can add command to
reset entry with default values from dst?

- Where to put the new netlink code?
tcp_metrics_netlink.c
tcp_metrics_nl.c
or just in current tcp_metrics.c ?
Put it in tcp_metrics.c, that way we don't need to export any
internals.
- command to modify specific metric for addr, by name? Only
for tcpm_vals? If not locked?

	Do we need modify/delete/reset support or just read
support is enough? Comments?
I would say that you can support fancy things as long as new
locking constraints are not added.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help