Re: sctp snmp mib stats in /proc/net/snmp

[Nivedita Singhvi <niv@us.ibm.com>]

Nivedita Singhvi wrote:
> 
> "David S. Miller" wrote:

> > Where will sctp_statistics be defined?  If it will be in net/sctp/*.c,
> > then you will need to ifdef this ipv4 procfs code on CONFIG_IP_SCTP
> 
> Rats, yes, it is in net/sctp/protocol.c. I'll move it under the ifdef
> and make up a complete patch with the dependent code for review
> purposes and repost. Thanks for the catch!

My apologies for the latency in getting back on this (critical 
interrupts from other directions)..

We're considering a modification to the original proposal, which 
was to display SCTP SNMP stats in /proc/net/snmp along with the
other AF_INET protocols currently being displayed. 

We're now considering simply displaying the sctp stats structures
(snmp and other extended) under the /proc/net/sctp/ subdirectory.

This is due to several reasons - one is that the CONFIG_IP_SCTP
def isnt enough. SCTP can also be compiled as a module, and may
or may not be loaded. We cant make assumptions in net/ipv4/proc.c
about whether the sctp_statistics structure is available or not..
Note #if defined (CONFIG_IP_SCTP) || defined (CONFIG_IP_SCTP_MODULE)
isnt enough. A clean way to do this would be to have an af_inet
top level registration process and have the sctp module register
when loaded, as is typical elsewhere. We really dont want to do
this at this point, and introduce too many dependencies on directories
outside of net/sctp at this time.

Secondly, the SCTP MIB is still being formed, and we're probably 
going to need additions/changes to the spec. In the interim, (or
possibly, permanently) we're going to need extended sctp stats which
arent in the spec, much like the current linux mib struct which 
defines a set of extended TCP counters. 

It would be easier to manage this under the sctp subdirectory
altogether. i.e. We diplay the SCTP SNMP and other extended stats
as /proc/net/sctp/snmp and /proc/net/sctp/sctp_mib or some such
name (which would be somewhat dynamic short term). This would also
solve unnecessary duplication for AF_INET6 for us.

Any issues, thoughts, suggestions? 

thanks,
Nivedita