Re: Modifying the mbuf data structure?
Re: Modifying the mbuf data structure?
- Subject: Re: Modifying the mbuf data structure?
- From: "Justin C. Walker" <email@hidden>
- Date: Thu, 03 Dec 2009 07:19:11 -0800
Hey, Godfrey,
On Dec 3, 2009, at 06:59 , Godfrey van der Linden wrote:
For my Ph.D. research I wish to collect I/O statistics and then to
attribute them to the initiating process.
Ignoring the deep philosophical issues associated with this goal
(that's for your thesis :-})
I'm going to be building a new kernel that can track per-process I/O
stats. This is reasonably easy to do for raw IOKit memory
descriptor I/Os, I can tag the descriptor with a process tag and on
completion accumulate it into data. This should be a reasonably
narrow change primarily to IOKit.
However, the network stats presents a problem, the drivers where I
collect the data do not know which process attribute them to until
the top of the network stack. I've had an idea that may work but
I'd like real networking experts opinion.
A natural analog to memory descriptors in networking is the mbuf
structure. I'd like to add a new field for my research kernel that
points to the data collected by the driver. Then I'll modify the
top of the networking stack to accumulate it into per process data.
Is this the easiest way of doing this or is their an easier way?
Your opinions and advice will be gratefully received. Note the code
is very carefully written to be extremely light weight and lock-free
(in the sense that no additional locks are required over and above
the locks already used by networking. There will be some cache
invalidation which appears to be unavoidable).
It's been a while since I have looked at the code, but AIR, except at
the very bottom or top of the stack, mbuf users tend to rely on m_data
to find out where to put their data. If that be the case, then (since
you're at the very bottom [I assume]), you can just "steal" the space
you need by fiddling with that value. You would need a marker to tell
you when one of "your" mbufs passes by, but there may be flag space
available.
You'd need to spend some time tracing the use of that value in kernel,
NKEs, and drivers to be sure no one is "backing up" the m_data pointer.
Modifying the mbuf structure can be tricky, especially in a world of
plugins (and don't forget the possibility of the odd skanky user-mode
process that wants to paw through the entrails of the kernel, looking
for juicy bits of data).
Others on the list may have more current understanding of the state of
things.
HTH
Justin
--
Justin C. Walker, Curmudgeon-At-Large
Director
Institute for the Enhancement of the Director's Income
--------
"Weaseling out of things is what separates us from the animals.
Well, except the weasel."
- Homer J Simpson
--------
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden