netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: jamal <hadi@cyberus.ca>
To: Masahide NAKAMURA <nakam@linux-ipv6.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
	David Miller <davem@davemloft.net>,
	netdev@vger.kernel.org
Subject: Re: [RFC][PATCH 0/3][XFRM]: Support packet processing error statistics.
Date: Tue, 23 Oct 2007 15:47:33 -0400	[thread overview]
Message-ID: <1193168853.4415.56.camel@localhost> (raw)
In-Reply-To: <200710231608.34661.nakam@linux-ipv6.org>

On Tue, 2007-23-10 at 16:08 +0900, Masahide NAKAMURA wrote:

> Thanks. I would like you to find too much item at my patch
> for the statistics, too.

I am not anywhere close to a machine where i can give you precise
details to this; the one thing that sticks out in my brain cells is the
SPI mismatch. This (in static setups) seemed to be the most common
mistake i saw (other than a mismatched key). Your stats as you have them
now and as is will catch both in one spot - which is a good start.

> This point is one of what I want to hear comment.
> My patch uses "XFRM_MIB_XXX" because I found "LINUX_MIB_XXX" definition at
> include/linux/snmp.h for TCP extended statistics at /proc/net/netstat and
> it does not seem to be defined by any RFC specification. 

I thought those were part of some MIB somewhere. Doesnt RFC 4898 cover
them?
In any case, it seems to me to be more accurate to not call them MIB
stats if they are not. This doesnt qualify using the macros, utilities
etc used for MIBs.

> Then I feel it is not so bad to
> use _MIB_ for them. Maybe we have another idea to merge them into LINUX_MIB.
> 
> Now we have the following candidates:
> 
> (1) my patch		XFRM_MIB_INHDRERROR
> (2) some extender	XFRM_XXX_INHDRERROR	(XXX is requested)
> (3) not-mib extender	XFRM_NOTMIB_INHDRERROR
> (4) no extender		XFRM_INHDRERROR
> (5) merge linux-mib	LINUX_MIB_XFRMINHDRERROR
> 
> Comments?

I am very tempted to say #4. And when you push this to be a real MIB
stat then 

> 
> > 2) Why /proc? Are you going to make these available also via netlink? 
> 
> Because /proc is easy to see it without any modified application.
> If you want the netlink interface, I can do it as the next step. Do you want it?

Absolutely - it would be much appreciated. And if you dont have time, I
will write and test the user space part extension.

cheers,
jamal


  reply	other threads:[~2007-10-23 19:47 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-17 14:29 [0/11] Various xfrm fixes and clean-ups Herbert Xu
2007-10-17 14:34 ` [PATCH 1/11] [IPSEC]: Fix pure tunnel modes involving IPv6 Herbert Xu
2007-10-18  4:28   ` David Miller
2007-10-17 14:34 ` [PATCH 2/11] [IPSEC]: Move tunnel parsing for IPv4 out of xfrm4_input Herbert Xu
2007-10-18  4:29   ` David Miller
2007-10-17 14:34 ` [PATCH 3/11] [IPSEC]: Get nexthdr from caller in xfrm6_rcv_spi Herbert Xu
2007-10-18  4:29   ` David Miller
2007-10-17 14:34 ` [PATCH 4/11] [IPSEC]: Move ip_summed zapping out of xfrm6_rcv_spi Herbert Xu
2007-10-18  4:30   ` David Miller
2007-10-17 14:34 ` [PATCH 5/11] [IPSEC]: Fix length check in xfrm_parse_spi Herbert Xu
2007-10-18  4:30   ` David Miller
2007-10-17 14:34 ` [PATCH 6/11] [IPSEC]: Move type and mode map into xfrm_state.c Herbert Xu
2007-10-18  4:31   ` David Miller
2007-10-17 14:34 ` [PATCH 7/11] [IPSEC]: Add missing BEET checks Herbert Xu
2007-10-18  4:31   ` David Miller
2007-10-17 14:34 ` [PATCH 8/11] [IPSEC]: Store afinfo pointer in xfrm_mode Herbert Xu
2007-10-18  4:34   ` David Miller
2007-10-17 14:34 ` [PATCH 9/11] [IPSEC]: Use the top IPv4 route's peer instead of the bottom Herbert Xu
2007-10-18  4:34   ` David Miller
2007-10-17 14:34 ` [PATCH 10/11] [IPSEC]: Disallow combinations of RO and AH/ESP/IPCOMP Herbert Xu
2007-10-18  4:35   ` David Miller
2007-10-22  6:09     ` [PATCH] [IPSEC] IPV6: Fix to add tunnel mode SA correctly Masahide NAKAMURA
2007-10-22  8:37       ` Herbert Xu
2007-10-22  9:42         ` David Miller
2007-10-22  6:11     ` [RFC][PATCH 0/3][XFRM]: Support packet processing error statistics Masahide NAKAMURA
2007-10-22  8:50       ` Herbert Xu
2007-10-22  8:42         ` Masahide NAKAMURA
2007-10-22 12:28       ` jamal
2007-10-23  7:08         ` Masahide NAKAMURA
2007-10-23 19:47           ` jamal [this message]
2007-10-24  3:30             ` Masahide NAKAMURA
2007-10-24 12:18               ` jamal
2007-10-25  9:06                 ` Masahide NAKAMURA
2007-10-24  3:59           ` YOSHIFUJI Hideaki / 吉藤英明
2007-10-24 12:25             ` jamal
2007-10-22  6:11     ` [RFC][PATCH 1/3][XFRM]: Define packet processing statistics Masahide NAKAMURA
2007-10-22  6:11     ` [RFC][PATCH 2/3][XFRM]: Support to increment " Masahide NAKAMURA
2007-10-22  6:11     ` [RFC][PATCH 3/3][XFRM]: Add packet processing statistics option Masahide NAKAMURA
2007-10-17 14:34 ` [PATCH 11/11] [IPSEC]: Rename mode to outer_mode and add inner_mode Herbert Xu
2007-10-17 15:26   ` Herbert Xu
2007-10-18  4:36     ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1193168853.4415.56.camel@localhost \
    --to=hadi@cyberus.ca \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=nakam@linux-ipv6.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).