Sebastien Roy wrote: > On Tue, 2009-07-21 at 09:43 -0700, Darren Reed wrote: > >> I'm filing this as self sponsored fast track. This case seeks minor >> binding; there are no plans to backport it to an update release. >> > > Regardless, the ipnet case itself (2006/475) has Patch binding, and it > would be silly to backport that without its kstats... I'd suggest > declaring Patch binding on this case with a case dependency on 2006/475. >
Well, the intention is for the changes responsible to go back as part of a project that does not have patch binding... but I suppose that someone might want to do the work to make it happen. >> 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 and will be visible >> inside the respective zone. >> >> duplicationFail - packet duplicate prior to dispatch failed >> dispatchOk - ddi_dispatch succeeded >> dispatchFail - ddi_dispatch failed >> > > Do you mean ddi_taskq_dispatch? > Yes >> 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 >> > > Packets are only delivered using putnext(). putq() is only used for > flow-control in ipnet's read-queue, and those packets are eventually > "devlivered" using putnext() in ipnet_rsrv(). So it would make more > semantic sense to only bump this for packets that are actually delivered > up to a consumer using putnext(). > And "dispatchPutDrop" needs to be removed. Comment updated for dispatchDeliver. >> acceptOk - accept packet filter function wants the packet >> acceptFail - accept packet filter function rejects the packet >> > > You're defining these as Uncommitted Public interfaces, but I don't > think these can be publicly documented as-is (I'm guessing you're > documenting these in the ipnet(7D) man page). There's currently no intention to document them. > For example, the "accept > packet filter function" is an ipnet.c implementation detail that is not > part of a public interface. Same with the use of a taskq for various > purposes, which the dispatch* kstats you define are tied to. If the > internal implementation of ipnet.c changes, these kstats will no longer > make sense. So they can't be Uncommitted by definition. > > I'd suggest either dropping this to Project-Private. > That's fine. Updated text below. Darren I'm filing this as self sponsored fast track. This case seeks patch binding. Although there are no plans to backport this an update release, should someone seek to backport ipnet (PSARC/2006/475), which has patch binding, it is reasonable to assume they may wish to backport these kstats. As the nature of this case is extremely straight forward, it is being submitted as an automatic, closed, case. 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 and will be visible inside the respective zone. duplicationFail - packet duplicate prior to dispatch failed dispatchOk - ddi_dispatch succeeded dispatchFail - ddi_dispatch failed dispatchHeaderDrop - ipnet_addheader caused packet to be dropped dispatchDupDrop - packet dropped: copymsg/dupmsg fail in ipnet_dispatch dispatchDeliver - packet delivered with putnext 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. These kstats will be delivered under module "ipnet", name "ipnet_stats" and class "misc". All of the interfaces being introduced are project private.
