[RFC] Interface for TCP Metrics

[RFC] Interface for TCP Metrics

[Julian Anastasov]

	Hello,

	Once DaveM mentioned that TCP Metrics need their
own interface. I'm planning to implement such interface
but lets first decide how it should look. After little
research, here is my plan:

- will use genl with TCP_METRICS_GENL_NAME "tcp_metrics",
TCP_METRICS_GENL_VERSION 0x01

- 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

- Is command to delete cached entry needed? Delete will need
new rcu_head. Useful to flush the cache or to delete entries
with filter.

- 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 ?

- will provide support for ip tool:

ip tcpm[etrics] <cmd> ...
ip -6 tcpm[etrics] get <addr> => TCP_METRICS_CMD_GET for 1 entry
ip tcpm[etrics] list => dumpit

- any wishes how to look the output? How to select specific
values/metrics in output? For example, list only specified
named values: ip tcpm list [-o] rtt

- 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?

Regards

--
Julian Anastasov <ja@ssi.bg>

Re: [RFC] Interface for TCP Metrics

[Eric Dumazet]

On Sun, 2012-08-19 at 14:42 +0300, Julian Anastasov wrote:
> 	Hello,
> 
> 	Once DaveM mentioned that TCP Metrics need their
> own interface. I'm planning to implement such interface
> but lets first decide how it should look. After little
> research, here is my plan:
> 
> - will use genl with TCP_METRICS_GENL_NAME "tcp_metrics",
> TCP_METRICS_GENL_VERSION 0x01
> 
> - 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
> 
> - Is command to delete cached entry needed? Delete will need
> new rcu_head. Useful to flush the cache or to delete entries
> with filter.
> 
> - 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 ?
> 
> - will provide support for ip tool:
> 
> ip tcpm[etrics] <cmd> ...
> ip -6 tcpm[etrics] get <addr> => TCP_METRICS_CMD_GET for 1 entry
> ip tcpm[etrics] list => dumpit
> 
> - any wishes how to look the output? How to select specific
> values/metrics in output? For example, list only specified
> named values: ip tcpm list [-o] rtt
> 
> - 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?
> 
> Regards

One way to delete one or all entries would be good, for being able to
reproduce some tests from a known state.

Re: [RFC] Interface for TCP Metrics

[Stephen Hemminger]

On Sun, 19 Aug 2012 14:42:15 +0300 (EEST)
Julian Anastasov <ja@ssi.bg> wrote:

> 
> 	Hello,
> 
> 	Once DaveM mentioned that TCP Metrics need their
> own interface. I'm planning to implement such interface
> but lets first decide how it should look. After little
> research, here is my plan:
> 
> - will use genl with TCP_METRICS_GENL_NAME "tcp_metrics",
> TCP_METRICS_GENL_VERSION 0x01

Ok, but don't use libnl in iproute

> - 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

Doing filtering in use space is fine, no need to be too fancy.

> - Is command to delete cached entry needed? Delete will need
> new rcu_head. Useful to flush the cache or to delete entries
> with filter.
> 
> - 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 ?
> 
> - will provide support for ip tool:
> 

Re: [RFC] Interface for TCP Metrics

[David Miller]

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.