From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vlad Yasevich Date: Mon, 29 Oct 2012 20:11:50 +0000 Subject: Re: [PATCH net-next] sctp: support per-association stats via a new SCTP_GET_ASSOC_STATS call Message-Id: <508EE306.9080608@gmail.com> List-Id: References: <1351258973-17227-1-git-send-email-michele@acksyn.org> <20121026143704.GC25087@hmsreliant.think-freely.org> <20121027113541.GA7966@marquez.int.rhx> <20121029163808.GB10177@hmsreliant.think-freely.org> In-Reply-To: <20121029163808.GB10177@hmsreliant.think-freely.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Neil Horman Cc: Michele Baldessari , "linux-sctp@vger.kernel.org" , "David S. Miller" , "netdev@vger.kernel.org" , Thomas Graf On 10/29/2012 12:38 PM, Neil Horman wrote: > On Sat, Oct 27, 2012 at 11:48:33AM -0400, Vlad Yasevich wrote: >> >> >> >> >> On Oct 27, 2012, at 7:35 AM, Michele Baldessari wrote: >> >>> Hi Neil & Vlad, >>> >>> On Fri, Oct 26, 2012 at 10:37:04AM -0400, Neil Horman wrote: >>>> We already have files in /proc/net/sctp to count snmp system-wide totals, >>>> per-endpoint totals, and per association totals. Why do these stats differently >>>> instead of just adding them the per-association file? I get that solaris does >>>> this, but its not codified in any of the RFC's or other standards. I would >>>> really rather see something like this go into the interfaces we have, rather >>>> than creating a new one. >>>> >>>> I also am a bit confused regarding the stats themselves. Most are fairly clear, >>>> but some seem lacking (you count most things sent and received, but only count >>>> received gap acks). Others seems vague and or confusing (when counting >>>> retransmitted chunks and packets, how do you count a packet that has both new >>>> and retransmitted chunks)? And the max observed rto stat is just odd. Each >>>> transport has an rto value, not each association, and you cal already see the >>>> individual transport rto values in /proc/net/sctp/remaddr. >>> >>> thanks a lot for your time reviewing this. I will try to address all >>> your comments in a second version of the patch. One thing I am not too >>> sure though: do you prefer me extending /proc/net/sctp/* or implement a >>> new call. >>> >>> I ask because from a previous private communication with Vlad the new >>> socket option seemed to be the preferred approach. >>> I am fine either way just let me know ;) >> >> >> socket option is preferable as /proc doesn't scale very well as number of associations grows. >> >> -Vlad >> > I completely agree with that notion, but at the same time, the socket option is > limited in that these stats will only be accessible to the process that owns the > socket. I imagine that someone will eventually ask for these stats to be made > available to utilities outside of the owning socket. > Neil I am sure they will, but I know of several applications that as part of debugging information periodically fetch the stats. For them it is much simpler to use socket options. -vlad > >>> >>> cheers, >>> -- >>> Michele Baldessari >>> C2A5 9DA3 9961 4FFB E01B D0BC DDD4 DCCB 7515 5C6D >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >>