netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pavel Emelyanov <xemul@openvz.org>
To: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: akpm@linux-foundation.org, Ingo Molnar <mingo@elte.hu>,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [patch 37/37] LTTng instrumentation net
Date: Thu, 24 Apr 2008 20:30:56 +0400	[thread overview]
Message-ID: <4810B5C0.1080501@openvz.org> (raw)
In-Reply-To: <20080424161337.GA22874@Krystal>

Mathieu Desnoyers wrote:
> * Pavel Emelyanov (xemul@openvz.org) wrote:
>> Mathieu Desnoyers wrote:
>>> Network core events.
>>>
>>> Added markers :
>>>
>>> net_del_ifa_ipv4
>>> net_dev_receive
>>> net_dev_xmit
>>> net_insert_ifa_ipv4
>>> net_socket_call
>>> net_socket_create
>>> net_socket_recvmsg
>>> net_socket_sendmsg
>> Network "core" events are not limited with the above calls.
>>
> 
> True. This is by no mean an exhaustive list of network events. It just
> happens to be the ones which has been useful to LTT/LTTng users for the
> past ~10 years.

Do you mean, that we'll have these debris all over the networking code some day?

>> Besides, real "core" events already sent notifications about themselves.
>> Why do we need additional hooks?
>>
> 
> I doubt the current notification hooks have a performance impact as
> small as the proposed markers. Which notification mechanism do you refer
> to ? It could be interesting to put markers in there instead.

E.g. call_netdevice_notifiers and co. 
And they have nothing to do with performance, since configuration code is 
not supposed to have a rocket speed.

> The goal behind this is to feed information to a general purpose tracer
> like lttng, a scripting mechanism like systemtap or a special-purpose
> tracer like ftrace.
> 
> I think that the most important instrumentation in this patchset is the
> xmit/recv of a packet at the device level. The net_socket_*
> instrumentation could eventually be replaced by an architecture specfic
> system call parameters instrumentation.

I will not argue about the value of such hooks in xmit/recv paths, but
as far as the net_socket_xxx is concerned - there is already the
* ptrace
* security
* kprobes
way to screw the normal code flow up in these places.

> Mathieu
> 
>>> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
>>> CC: netdev@vger.kernel.org
>>> ---
>>>  net/core/dev.c     |    6 ++++++
>>>  net/ipv4/devinet.c |    6 ++++++
>>>  net/socket.c       |   19 +++++++++++++++++++
>>>  3 files changed, 31 insertions(+)
> 


      reply	other threads:[~2008-04-24 16:34 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20080424150324.802695381@polymtl.ca>
2008-04-24 15:04 ` [patch 37/37] LTTng instrumentation net Mathieu Desnoyers
2008-04-24 15:52   ` Pavel Emelyanov
2008-04-24 16:13     ` Mathieu Desnoyers
2008-04-24 16:30       ` Pavel Emelyanov [this message]

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=4810B5C0.1080501@openvz.org \
    --to=xemul@openvz.org \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@polymtl.ca \
    --cc=mingo@elte.hu \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).