All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fan Du <fan.du@windriver.com>
To: Steffen Klassert <steffen.klassert@secunet.com>
Cc: <herbert@gondor.hengli.com.au>, <davem@davemloft.net>,
	<netdev@vger.kernel.org>
Subject: Re: [PATCHv2 net-next] {ipv4,xfrm}: Introduce xfrm_tunnel_notifier for xfrm tunnel mode callback
Date: Fri, 30 Aug 2013 16:29:47 +0800	[thread overview]
Message-ID: <522057FB.2010306@windriver.com> (raw)
In-Reply-To: <20130830073801.GH7660@secunet.com>



On 2013年08月30日 15:38, Steffen Klassert wrote:
> On Wed, Aug 28, 2013 at 03:09:40PM +0800, Fan Du wrote:
>> Some thoughts on IPv4 VTI implementation:
>>
>> The connection between VTI receiving part and xfrm tunnel mode input process
>> is hardly a "xfrm_tunnel", xfrm_tunnel is used in places where, e.g ipip/sit
>> and xfrm4_tunnel, acts like a true "tunnel" device.
>>
>> In addition, IMHO, VTI doesn't need vti_err to do something meaningful, as all
>> VTI needs is just a notifier to be called whenever xfrm_input ingress a packet
>> to update statistics.
>>
>> A IPsec protected packet is first handled by protocol handlers, e.g AH/ESP,
>> to check packet authentication or encryption rightness. PMTU update is taken
>> care of in this stage by protocol error handler.
>>
>> Then the packet is rearranged properly depending on whether it's transport
>> mode or tunnel mode packed by mode "input" handler. The VTI handler code
>> takes effects in this stage in tunnel mode only. So it neither need propagate
>> PMTU, as it has already been done if necessary, nor the VTI handler is
>> qualified as a xfrm_tunnel.
>>
>> So this patch introduces xfrm_tunnel_notifier and meanwhile wipe out vti_err
>> code.
>>
>> Signed-off-by: Fan Du<fan.du@windriver.com>
>> Cc: Steffen Klassert<steffen.klassert@secunet.com>
>> Cc: David S. Miller<davem@davemloft.net>
>> Reviewed-by: Saurabh Mohan<saurabh.mohan@vyatta.com>
>
> Applied to ipsec-next, thanks a lot!
>

Hi, Steffen

Thanks for picking this up!

About "xfrm: Refactor xfrm_state timer management", Thomas objects adding notifier
at clock_was_set( https://lkml.org/lkml/2013/8/18/36 ), frankly speaking I'm not
experienced to argue with such high level person, neither could I convince David
that getting rid of wall clock in xfrm_state is the right thing to do.
So I really don't know what to do with this patch now :( scratching my head harder。。。

Is there any slim light of hope for me to keep working on this IPsec issue?
Or should I drop it?

Thanks

-- 
浮沉随浪只记今朝笑

--fan

      reply	other threads:[~2013-08-30  8:29 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-28  7:09 [PATCHv2 net-next] {ipv4,xfrm}: Introduce xfrm_tunnel_notifier for xfrm tunnel mode callback Fan Du
2013-08-30  7:38 ` Steffen Klassert
2013-08-30  8:29   ` Fan Du [this message]

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=522057FB.2010306@windriver.com \
    --to=fan.du@windriver.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.hengli.com.au \
    --cc=netdev@vger.kernel.org \
    --cc=steffen.klassert@secunet.com \
    /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.