netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Xin Long <lucien.xin@gmail.com>
To: netdev@vger.kernel.org
Cc: Jakub Kicinski <jakub.kicinski@netronome.com>,
	Steffen Klassert <steffen.klassert@secunet.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	"David S. Miller" <davem@davemloft.net>,
	Sabrina Dubroca <sd@queasysnail.net>
Subject: [PATCHv2 ipsec-next 00/10] xfrm: support ipip and ipv6 tunnels in vti and xfrmi
Date: Tue, 30 Jun 2020 15:36:25 +0800	[thread overview]
Message-ID: <cover.1593502515.git.lucien.xin@gmail.com> (raw)

Now ipip and ipv6 tunnels processing is supported by xfrm4/6_tunnel,
but not in vti and xfrmi. This feature is needed by processing those
uncompressed small fragments and packets when using comp protocol.
It means vti and xfrmi won't be able to accept small fragments or
packets when using comp protocol, which is not expected.

xfrm4/6_tunnel eventually calls xfrm_input() to process ipip and ipv6
tunnels with an ipip/ipv6-proto state (a child state of comp-proto
state), and vti and xfrmi should do the same.

The extra things for vti to do is:

  - vti_input() should be called before xfrm_input() to set
    XFRM_TUNNEL_SKB_CB(skb)->tunnel.ip4/6 = tunnel. [A]

  - vti_rcv_cb() should be called after xfrm_input() to update
    the skb->dev. [B]

And the extra things for xfrmi to do is:

   - The ipip/ipv6-proto state should be assigned if_id from its
     parent's state. [C]

   - xfrmi_rcv_cb() should be called after xfrm_input() to update
     the skb->dev. [D]


Patch 4-7 does the things in [A].

To implement [B] and [D], patch 1-3 is to build a callback function
for xfrm4/6_tunnel, which can be called after xfrm_input(), similar
to xfrm4/6_protocol's .cb_handler. vti and xfrmi only needs to give
their own callback function in patch 4-7 and 9-10, which already
exists: vti_rcv_cb() and xfrmi_rcv_cb().

Patch 8 is to do the thing in [C] by assigning child tunnel's if_id
from its parent tunnel.

With the whole patch series, the segments or packets with any size
can work with ipsec comp proto on vti and xfrmi.

v1->v2:
  - See Patch 2-3.

Xin Long (10):
  xfrm: add is_ipip to struct xfrm_input_afinfo
  tunnel4: add cb_handler to struct xfrm_tunnel
  tunnel6: add tunnel6_input_afinfo for ipip and ipv6 tunnels
  ip_vti: support IPIP tunnel processing with .cb_handler
  ip_vti: support IPIP6 tunnel processing
  ip6_vti: support IP6IP6 tunnel processing with .cb_handler
  ip6_vti: support IP6IP tunnel processing
  ipcomp: assign if_id to child tunnel from parent tunnel
  xfrm: interface: support IP6IP6 and IP6IP tunnels processing with
    .cb_handler
  xfrm: interface: support IPIP and IPIP6 tunnels processing with
    .cb_handler

 include/net/xfrm.h        |  5 ++++-
 net/ipv4/ip_vti.c         | 49 +++++++++++++++++++-----------------------
 net/ipv4/ipcomp.c         |  1 +
 net/ipv4/tunnel4.c        | 35 +++++++++++++++++++++++++++++-
 net/ipv6/ip6_vti.c        | 31 +++++++++++++++++++++++++++
 net/ipv6/ipcomp6.c        |  1 +
 net/ipv6/tunnel6.c        | 34 +++++++++++++++++++++++++++++
 net/xfrm/xfrm_input.c     | 24 +++++++++++----------
 net/xfrm/xfrm_interface.c | 54 +++++++++++++++++++++++++++++++++++++++++++++++
 9 files changed, 194 insertions(+), 40 deletions(-)

-- 
2.1.0


             reply	other threads:[~2020-06-30  7:36 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-30  7:36 Xin Long [this message]
2020-06-30  7:36 ` [PATCHv2 ipsec-next 01/10] xfrm: add is_ipip to struct xfrm_input_afinfo Xin Long
2020-06-30  7:36   ` [PATCHv2 ipsec-next 02/10] tunnel4: add cb_handler to struct xfrm_tunnel Xin Long
2020-06-30  7:36     ` [PATCHv2 ipsec-next 03/10] tunnel6: add tunnel6_input_afinfo for ipip and ipv6 tunnels Xin Long
2020-06-30  7:36       ` [PATCHv2 ipsec-next 04/10] ip_vti: support IPIP tunnel processing with .cb_handler Xin Long
2020-06-30  7:36         ` [PATCHv2 ipsec-next 05/10] ip_vti: support IPIP6 tunnel processing Xin Long
2020-06-30  7:36           ` [PATCHv2 ipsec-next 06/10] ip6_vti: support IP6IP6 tunnel processing with .cb_handler Xin Long
2020-06-30  7:36             ` [PATCHv2 ipsec-next 07/10] ip6_vti: support IP6IP tunnel processing Xin Long
2020-06-30  7:36               ` [PATCHv2 ipsec-next 08/10] ipcomp: assign if_id to child tunnel from parent tunnel Xin Long
2020-06-30  7:36                 ` [PATCHv2 ipsec-next 09/10] xfrm: interface: support IP6IP6 and IP6IP tunnels processing with .cb_handler Xin Long
2020-06-30  7:36                   ` [PATCHv2 ipsec-next 10/10] xfrm: interface: support IPIP and IPIP6 " Xin Long
2020-07-02 23:54                   ` [PATCHv2 ipsec-next 09/10] xfrm: interface: support IP6IP6 and IP6IP " kernel test robot
2020-07-05 16:57                     ` Xin Long
2020-07-02 22:20             ` [PATCHv2 ipsec-next 06/10] ip6_vti: support IP6IP6 tunnel " kernel test robot
2020-07-02 23:33             ` kernel test robot
2020-07-05 16:57               ` Xin Long
2020-07-02 20:46     ` [PATCHv2 ipsec-next 02/10] tunnel4: add cb_handler to struct xfrm_tunnel kernel test robot
2020-07-02 20:53     ` kernel test robot
2020-07-05 18:30       ` Xin Long

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=cover.1593502515.git.lucien.xin@gmail.com \
    --to=lucien.xin@gmail.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=jakub.kicinski@netronome.com \
    --cc=netdev@vger.kernel.org \
    --cc=sd@queasysnail.net \
    --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 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).