From: Ingo Oeser <netdev@axxeo.de>
To: Kumar Gala <galak@kernel.crashing.org>
Cc: Andrew Grover <andy.grover@gmail.com>,
"Chris Leech" <christopher.leech@intel.com>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH 1/9] [I/OAT] DMA memcpy subsystem
Date: Fri, 31 Mar 2006 10:26:33 +0200 [thread overview]
Message-ID: <200603311026.33391.netdev@axxeo.de> (raw)
In-Reply-To: <351C5BDA-D7E3-4257-B07E-ABDDCF254954@kernel.crashing.org>
Kumar Gala wrote:
> On Mar 30, 2006, at 12:36 PM, Andrew Grover wrote:
> > Well....it's true they're useful for debugging but I would put them in
> > the category of system statistics that shouldn't go in debugfs. I
> > think they are like /proc/interrupts' interrupt counts or the TX/RX
> > stats reported by ifconfig.
>
> Fair, but wouldn't it be better to have the association per client.
>
> Maybe leave the one as a summary and have a dir per client with
> similar stats that are for each client and add a per channel summary
> at the top level as well.
Such level of detail really belongs to debugging, IMHO.
I think, it would suffer to say, how many channels are in use.
So you can answer the question, whether your customers are actually
using this experimental technology.
If you want more, let them mount debugfs.
If it becomes really important, we can revisit this later.
Thats the advantage of files under debugfs
not being stable API in any way.
BTW: What is the actual frequency, at which such counters
will be incremented?
Regards
Ingo Oeser
next prev parent reply other threads:[~2006-03-31 8:26 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-29 22:55 [PATCH 0/9] I/OAT Chris Leech
2006-03-29 22:55 ` [PATCH 1/9] [I/OAT] DMA memcpy subsystem Chris Leech
2006-03-30 8:01 ` Kumar Gala
2006-03-30 18:36 ` Andrew Grover
2006-03-30 19:57 ` Kumar Gala
2006-03-31 8:26 ` Ingo Oeser [this message]
2006-03-31 20:04 ` Andrew Grover
2006-03-31 20:06 ` Kumar Gala
2006-03-31 20:27 ` Andrew Grover
2006-03-29 22:55 ` [PATCH 3/9] [I/OAT] Setup the networking subsystem as a DMA client Chris Leech
2006-03-29 22:55 ` [PATCH 4/9] [I/OAT] Utility functions for offloading sk_buff to iovec copies Chris Leech
2006-03-29 22:55 ` [PATCH 5/9] [I/OAT] Structure changes for TCP recv offload to I/OAT Chris Leech
2006-03-29 22:56 ` [PATCH 6/9] [I/OAT] Rename cleanup_rbuf to tcp_cleanup_rbuf and make non-static Chris Leech
2006-03-29 22:56 ` [PATCH 7/9] [I/OAT] make sk_eat_skb I/OAT aware Chris Leech
2006-03-29 22:56 ` [PATCH 8/9] [I/OAT] Add a sysctl for tuning the I/OAT offloaded I/O threshold Chris Leech
2006-03-29 22:56 ` [PATCH 9/9] [I/OAT] TCP recv offload to I/OAT Chris Leech
-- strict thread matches above, loose matches on Subject: below --
2006-05-08 22:16 [PATCH 0/9] I/OAT network recv copy offload Chris Leech
2006-05-08 22:17 ` [PATCH 1/9] [I/OAT] DMA memcpy subsystem Chris Leech
2006-05-24 0:16 [PATCH 0/9] I/OAT repost Chris Leech
2006-05-24 0:20 ` [PATCH 1/9] [I/OAT] DMA memcpy subsystem Chris Leech
2006-05-24 0:48 ` Andrew Morton
2006-05-24 6:31 ` Nathan Lynch
2006-05-24 0:51 ` Andrew Morton
2006-05-25 17:59 ` Olof Johansson
2006-05-25 18:09 ` Olof Johansson
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=200603311026.33391.netdev@axxeo.de \
--to=netdev@axxeo.de \
--cc=andy.grover@gmail.com \
--cc=christopher.leech@intel.com \
--cc=galak@kernel.crashing.org \
--cc=linux-kernel@vger.kernel.org \
--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).