[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1902752B0C92F943AB7EA9EE13E2DEEC126DB580C0@HQ1-EXCH02.corp.brocade.com>
Date: Mon, 26 Aug 2013 18:52:42 -0700
From: Saurabh Mohan <saurabh.mohan@...tta.com>
To: Fan Du <fan.du@...driver.com>,
"steffen.klassert@...unet.com" <steffen.klassert@...unet.com>,
"herbert@...dor.hengli.com.au" <herbert@...dor.hengli.com.au>
CC: "davem@...emloft.net" <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [PATCH net-next] {ipv4,xfrm}: Introduce xfrm_tunnel_notifier
for xfrm tunnel mode callback
> -----Original Message-----
> From: Fan Du [mailto:fan.du@...driver.com]
> Sent: Thursday, August 22, 2013 11:47 PM
> To: steffen.klassert@...unet.com; Saurabh Mohan;
> herbert@...dor.hengli.com.au
> Cc: davem@...emloft.net; netdev@...r.kernel.org
> Subject: [PATCH net-next] {ipv4,xfrm}: Introduce xfrm_tunnel_notifier for
> xfrm tunnel mode callback
>
> 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.
>
> So this patch introduce xfrm_tunnel_notifier and meanwhile wipe out
> vti_erri code.
>
> Signed-off-by: Fan Du <fan.du@...driver.com>
Looks good. Thanks.
Reviewed-by: Saurabh Mohan <saurabh.mohan@...tta.com>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists