From: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
To: Kalle Valo <kvalo@qca.qualcomm.com>
Cc: <ath10k@lists.infradead.org>, <linux-wireless@vger.kernel.org>,
Michal Kazior <michal.kazior@tieto.com>
Subject: Re: [PATCH v2] ath10k: handle ieee80211 header and payload tracing separately
Date: Tue, 4 Nov 2014 10:46:45 +0530 [thread overview]
Message-ID: <20141104051643.GA14509@qca.qualcomm.com> (raw)
In-Reply-To: <874muf7t9u.fsf@kamboji.qca.qualcomm.com>
On Tue, Nov 04, 2014 at 01:34:37AM +0200, Kalle Valo wrote:
> Rajkumar Manoharan <rmanohar@qti.qualcomm.com> writes:
>
> > For packet log, the transmitted frame 802.11 header alone is sufficient.
> > Recording entire packet is also consuming lot of disk space. To optimize
> > this, tx and rx data tracepoints are splitted into header and payload
> > tracepoints.
> >
> > -DECLARE_EVENT_CLASS(ath10k_data_event,
> > +#define ATH10K_FRM_HDR_LEN \
> > + ieee80211_hdrlen(((struct ieee80211_hdr *)data)->frame_control)
>
> This macro does not look good. I would recommend to follow what Johannes
> suggested:
>
> "It would be worth hiding that inside the tracepoint's assign function,
> so instead of passing data/len here you'd pass the full skb, or the full
> skb data/skb len, like this:
>
> ar, skb->data, skb->len
>
> to both tracers. Then inside the tracer you can do the hdrlen check, and
> that way move the code into the tracing so it's not hit when tracing is
> disabled."
v2 does the same. tracing functions just take ar, skb->data and skb->len.
header check is handled inside tracing funtions.
I do not understand your concerns. :(
-Rajkumar
next prev parent reply other threads:[~2014-11-04 5:15 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-30 9:28 [PATCH v2] ath10k: handle ieee80211 header and payload tracing separately Rajkumar Manoharan
2014-11-03 23:34 ` Kalle Valo
2014-11-04 5:16 ` Rajkumar Manoharan [this message]
2014-11-05 1:29 ` Kalle Valo
2014-11-05 9:44 ` Rajkumar Manoharan
2014-11-05 10:12 ` Johannes Berg
2014-11-05 10:44 ` Rajkumar Manoharan
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=20141104051643.GA14509@qca.qualcomm.com \
--to=rmanohar@qti.qualcomm.com \
--cc=ath10k@lists.infradead.org \
--cc=kvalo@qca.qualcomm.com \
--cc=linux-wireless@vger.kernel.org \
--cc=michal.kazior@tieto.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 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).