Peter Tribble wrote:
On Tue, Jul 21, 2009 at 4:48 AM, Darren Reed<[email protected]> wrote:
The below isn't meant to be a comprehensive kstat solution for ipnet,
but it at least gets it started so that we can at least start to
measure its behaviour.
If there are no objections, I'll file this as a one-pager sometime
tomorrow.
Darren
Problem
-------
Looking at ipnet, there is no instrumentation to tell an observer about
how it is functioning. No statistics are available about whether or not
it runs out of buffers, how many packets get accepted vs rejected, etc.
Proposal
--------
This document proposes to add kstats to ipnet to provide statistics
about how the ipnet module is performing. The statistics proposed at
this stage are will be provided per stack instance.
duplicationFail - packet duplicate prior to dispatch failed
dispatchOk - ddi_dispatch succeeded
dispatchFail - ddi_dispatch failed
dispatchHeaderDrop - ipnet_addheader caused packet to be dropped
dispatchPutDrop - packet dropped: cannot put packet on queue
dispatchDupDrop - packet dropped: copymsg/dupmsg fail in ipnet_dispatch
dispatchDeliver - packet delivered with putnext/putq
acceptOk - accept packet filter function wants the packet
acceptFail - accept packet filter function rejects the packet
The statistics will be local to each zone with its own stack instance.
Can each zone only have a single stack instance? (And thus only a
single set of kstats.)
Yes.
What does this look like in the global zone? Can I see all of the
separate stack instances?
No.
How are they identified? Just as separate kstat instances? In that
case, how do I map each
instance to a given stack instance and thus to a zone?
What is the nature of this question?
Administrative or programming?
If it is administrative, I think the answer to th above two questions
will answer the rest
of your questions here.
These kstats will be delivered under module "ipnet", name "ipnet_stats"
and class "misc".
Is anything else using the ipnet module?
I don't understand that question.
And can we do any better than class "misc"? (Not that it's that critical in this
particular case, as ipnet::ipnet_stats should be adequate to pick out the kstats
of interest.)
I suggest you look at the output of "kstat" and see what names are
used today. The names I chose were to be consistent with what is
already in use.
Darren
_______________________________________________
networking-discuss mailing list
[email protected]
