Re: Modifying the mbuf data structure?
Re: Modifying the mbuf data structure?
- Subject: Re: Modifying the mbuf data structure?
- From: Josh Graessley <email@hidden>
- Date: Thu, 3 Dec 2009 08:44:59 -0800
It may be possible to use mbuf tags. Mbuf tags allow you to attach
additional information to an mbuf. The downside is that mbuf tags are
not as light weight as they ought to be. Internally the stack
allocates another mbuf for the tag.
I think you'll need to go in to each protocol at the socket layer and
modify the code to add the tag. That may also require modifying the
socket to track the current owning process. Some sockets are shared
across processes. The most common example are sockets created in
launchd for incoming connections and then handed off to another
process to handle the socket. If I remember correctly, the new
connection is created in the kernels context and placed on the
listening queue. The listening socket is shared with another process
which is responsible for calling accept. The process of calling accept
probably creates the new socket.
One other example if sharing sockets is a helper utility that runs as
root to create a socket and bind it to a low numbered port and then
hand it off to another process. The stack doesn't currently track the
notion of the owning process for a given socket so handling this could
be tricky.
Sent from my iPhone
On Dec 3, 2009, at 6:59, Godfrey van der Linden <email@hidden> wrote:
G'day, Kernel dudes.
For my Ph.D. research I wish to collect I/O statistics and then to
attribute them to the initiating process.
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).
Cheers
Godfrey
_______________________________________________
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
_______________________________________________
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