From: Dominic Hamon <dhamon@twitter.com>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH net-next 2/3] Implementation of RFC 4898 Extended TCP Statistics (Web10G)
Date: Tue, 16 Dec 2014 14:09:46 -0800 [thread overview]
Message-ID: <20141216220946.GA19603@k9> (raw)
In-Reply-To: <20141216.151823.2276708539799601894.davem@davemloft.net>
On Tue, Dec 16, 2014 at 03:18:23PM -0500, David Miller wrote:
> From: rapier <rapier@psc.edu>
> Date: Tue, 16 Dec 2014 15:13:44 -0500
>
> > On 12/16/14, 3:03 PM, David Miller wrote:
> >
> >> You shouldn't need to export any symbols.
> >
> > As a point of clarification - is it acceptable to export symbols for
> > use with in tree modules such as tcp_htcp? We are more than willing to
> > do the work required to bring this in line with best practices.
>
> I'm saying for data and TCP statistics collection, you shouldn't need
> to add any new symbol exports.
>
> Keep this in the main kernel, nothing external should be needed.
>
> Extending tcp_info or similar is the only reasonable way to implement
> this stuff.
There are two aspects of the tcp_estats approach that I think are worth
considering separately:
- the breadth of instrumentation
- the access method through kernel module/netlink
I don't see any reason why we can't take the instrumentation parts of
these patches and plumb them in to tcp_info.
I would prefer if we can retain the nested structures and the sysctl
that controls the set of instruments collected as I think this key
feature gives plenty of flexibility to system operators in terms of an
overhead/instrumentation trade-off, however I recognise this complicates
how the socket option is returned, and how ss might report the metrics.
--
Dominic Hamon
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2014-12-16 22:09 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-16 18:24 [PATCH net-next 2/3] Implementation of RFC 4898 Extended TCP Statistics (Web10G) Alexei Starovoitov
2014-12-16 18:58 ` rapier
2014-12-16 19:11 ` David Miller
2014-12-16 19:09 ` David Miller
2014-12-16 20:01 ` rapier
2014-12-16 20:03 ` David Miller
2014-12-16 20:13 ` rapier
2014-12-16 20:18 ` David Miller
2014-12-16 21:02 ` rapier
2014-12-16 22:33 ` Eric Dumazet
2014-12-16 22:44 ` David Miller
2014-12-17 17:32 ` rapier
2014-12-16 22:09 ` Dominic Hamon [this message]
-- strict thread matches above, loose matches on Subject: below --
2014-12-16 17:50 rapier
2014-12-17 3:44 ` Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141216220946.GA19603@k9 \
--to=dhamon@twitter.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.