All of lore.kernel.org
 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: Wed, 24 Oct 2007 08:18:46 -0400	[thread overview]
Message-ID: <1193228326.4442.12.camel@localhost> (raw)
In-Reply-To: <200710241230.57571.nakam@linux-ipv6.org>

On Wed, 2007-24-10 at 12:30 +0900, Masahide NAKAMURA wrote:

> At IPsec point of view, actually "SPI mismatch" caused by user configuration
> cannot be identified easily since identify of SAD is consist of SPI, address and
> protocol(ESP/AH...) and linux SAD uses hash database. It is database identify
> mismatch. Then, SPI mismatch goes "NoStates" at my patch.
> OTOH Key mismatch goes "ProtoError" since esp[46]_input returns error.

Would be useful to just document what you said above so that user doesnt
have to intepret it.

> Thanks for pointing the RFC. I've read it, however, I cannot find them at the RFC.

My bad. 

> > 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.
> 

BTW, I meant "doesnt disqualify them" above;-> 

> How about assuming it as "private MIB" of linux?

Ok, makes sense to me now - that would be a good choice (i dont see any
confusion with enteprise mib). 

> Shouldn't we have something after XFRM_  to distinguish from other XFRM
> macros?
> 

It is not needed - I am sorry that i missed the "Linux MIB" part in your
emails so far. That would be good enough.

> > > > 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.
> 
> Thanks. After my first step is completed, could you write the netlink part?

Thanks.

cheers,
jamal


  reply	other threads:[~2007-10-24 12:18 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
2007-10-24  3:30             ` Masahide NAKAMURA
2007-10-24 12:18               ` jamal [this message]
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=1193228326.4442.12.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.