Thread (8 messages) 8 messages, 5 authors, 2012-09-03

Re: [PATCH RFC 0/2] Interface for TCP Metrics

From: Julian Anastasov <ja@ssi.bg>
Date: 2012-08-23 16:24:28

	Hello,

On Thu, 23 Aug 2012, Stephen Hemminger wrote:
Some of netlink API comments:

1. My preference is to not make it so granular.
   I.e make things like RTT a structure with value and variance
   rather than lots of independent objects.
	Even the ip route used nested objects for metrics.
I preferred not to add fixed structure for them if that is
what you mean. I implemented it in the same way, just like
rtnetlink_put_metrics().
2. Make sure netlink API is symmetric. Get should report all
   values and Set should accept the same values (but ignore
   if value can not be modified).
	Will take care if one day we support SET request.
3. Try and make ip command output invertable, as in what you
   print is close to what ip command arguments are.
	Any example for what you mean?
4. What about monitoring changes?
	I preferred to avoid them because if the routes
are small number and can be monitored, these entries are
modified very often and to me it looked overkill to generate
notification for every update just to notice that nobody
listens for it.

	BTW, I noticed that the GENL part in iproute is
not separated in common place. Should we create common
place for functions like genl_ctrl_resolve_family and
genl_parse_getfamily ?

	Thanks for the comments!

Regards

--
Julian Anastasov [off-list ref]
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help