All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lars Ellenberg <Lars.Ellenberg@linbit.com>
To: drbd-dev@lists.linbit.com
Subject: Re: [Drbd-dev] Proposed update to packet dumping code
Date: Thu, 10 Aug 2006 01:14:34 +0200	[thread overview]
Message-ID: <20060809231434.GF4555@soda.linbit> (raw)
In-Reply-To: <342BAC0A5467384983B586A6B0B3767103624D59@EXNA.corp.stratus.com>

/ 2006-08-09 18:50:56 -0400
\ Graham, Simon:
> I'm trying to track down a problem where I really need to get a dump of
> the packets sent back and forth and I also need to be able to control
> the output at run time - the attached is a proposed patch to the
> DUMP_EACH_PACKET code in trunk that does the following:
> 
> 1. I've fixed the code so it compiles and runs and updated it to include
> (some of) the new messages in drbd-8
> 
> 2. When you build with DUMP_EACH_PACKET defined, a module parameter
> dump_packets is added that can be set via sysfs. Values
>    are:
> 
> 	0 - no tracing of packets
> 	1 - summary tracing of key packets - no file/line # and no
> tracing of Ping packets
> 	2 - full tracing - trace includes file/line# and all packets are
> traced
> 	3 - max tracing -- info on set-in-sync and set-out-of-sync calls
> also included (this set-in-sync was in
> 		 the existing code, so I left it there but it's annoying
> in general!)
> 
> 3. I've split the code into an inline that does a quick check to see if
> the tracing is enabled and a global function
>    that does the work.
> 
> At the moment, this is still not on by default but my intention would be
> that you could use a driver with this turned on in production (and
> therefore be able to debug problems in the field).

yes, this would have been usefull at times.  since during normal
operation (no tracing) the perfomance impact would be not noticable,
we probably should do it that way.

> Let me know what you think and if anything else should be done.

nice. in fact somewhere on my todo list there is a
"FIXME: DUMP_EACH_PACKET" ...

I'd like to even be able to "echo $mask > sysfs", to select which
packets to dump. this could be done by reserving the lower values
(using the first few bits) for generic switching, and if you see a
higher number with all lower bits cleared, you'd shift it and interpret
it as a bitmask.  whether thats useful, I don't know...

-- 
: Lars Ellenberg                                  Tel +43-1-8178292-55 :
: LINBIT Information Technologies GmbH            Fax +43-1-8178292-82 :
: Schoenbrunner Str. 244, A-1120 Vienna/Europe   http://www.linbit.com :

  reply	other threads:[~2006-08-09 23:14 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-09 22:50 [Drbd-dev] Proposed update to packet dumping code Graham, Simon
2006-08-09 23:14 ` Lars Ellenberg [this message]
2006-08-10  9:39 ` Philipp Reisner
  -- strict thread matches above, loose matches on Subject: below --
2006-08-10  0:43 Graham, Simon
2006-08-10 19:41 Graham, Simon

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=20060809231434.GF4555@soda.linbit \
    --to=lars.ellenberg@linbit.com \
    --cc=drbd-dev@lists.linbit.com \
    /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.