mbox series

[v2,net-next,00/11] ipmr, ip6mr: Align multicast routing for IPv4 & IPv6

Message ID 1519853379-1969-1-git-send-email-yuvalm@mellanox.com
Headers show
Series ipmr, ip6mr: Align multicast routing for IPv4 & IPv6 | expand

Message

Yuval Mintz Feb. 28, 2018, 9:29 p.m. UTC
Historically ip6mr was based [cut-n-paste] on ipmr and the two have not
diverged too much. Apparently as ipv4 multicast routing is more common
than its ipv6 brethren modifications since then are mostly one-way,
affecting ipmr while leaving ip6mr unchanged.

This series is meant to re-factor both ipmr and ip6mr into having common
structures [and some functionality], adding 2 new common files -
mroute_base.h and ipmr_base.c.

The series begins by bringing ip6mr up to speed to some of the changes
applied in the past to ipmr [#2, #3].
It is then possible to re-factor a lot of the common structures - 
vif devices [#1], mr_table [#4] mfc_cache [#6], and use the common
structures in both ipmr and ip6mr.

The rest of the patches re-factor some choice flows used by both ipmr
and ip6mr and eliminates duplicity.

This series would later allow for easy extension of ipmr offloading
to support ip6mr offloading as well, as almost all structures
related to the offloading would be shared between the two protocols.

Changes from previous versions
------------------------------
v2:
  - #6 Corrected reporting logic when hitting an unresolved cache
  - #7 Addressed kernel doc style [Thanks Nikolay]

RFC -> v1:
  - Corrected support for CONFIG_IP{,V6}_MROUTE_MULTIPLE_TABLES
  - Addressed a couple of kbuild test robot issues

Yuval Mintz (11):
  ipmr,ipmr6: Define a uniform vif_device
  ip6mr: Make mroute_sk rcu-based
  ip6mr: Align hash implementation to ipmr
  mroute*: Make mr_table a common struct
  ipmr, ip6mr: Unite creation of new mr_table
  ipmr, ip6mr: Make mfc_cache a common structure
  ipmr, ip6mr: Unite logic for searching in MFC cache
  ipmr, ip6mr: Unite mfc seq logic
  ipmr, ip6mr: Unite vif seq functions
  ip6mr: Remove MFC_NOTIFY and refactor flags
  ipmr, ip6mr: Unite dumproute flows

 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c |  21 +-
 include/linux/mroute.h                            |  88 +-
 include/linux/mroute6.h                           |  62 +-
 include/linux/mroute_base.h                       | 346 ++++++++
 include/net/netns/ipv6.h                          |   2 +-
 net/ipv4/Kconfig                                  |   5 +
 net/ipv4/Makefile                                 |   1 +
 net/ipv4/ipmr.c                                   | 582 ++++---------
 net/ipv4/ipmr_base.c                              | 323 +++++++
 net/ipv6/Kconfig                                  |   1 +
 net/ipv6/ip6_output.c                             |   2 +-
 net/ipv6/ip6mr.c                                  | 988 ++++++++--------------
 12 files changed, 1249 insertions(+), 1172 deletions(-)
 create mode 100644 include/linux/mroute_base.h
 create mode 100644 net/ipv4/ipmr_base.c

Comments

David Miller March 1, 2018, 6:20 p.m. UTC | #1
From: Yuval Mintz <yuvalm@mellanox.com>
Date: Wed, 28 Feb 2018 23:29:28 +0200

> Historically ip6mr was based [cut-n-paste] on ipmr and the two have not
> diverged too much. Apparently as ipv4 multicast routing is more common
> than its ipv6 brethren modifications since then are mostly one-way,
> affecting ipmr while leaving ip6mr unchanged.
> 
> This series is meant to re-factor both ipmr and ip6mr into having common
> structures [and some functionality], adding 2 new common files -
> mroute_base.h and ipmr_base.c.
> 
> The series begins by bringing ip6mr up to speed to some of the changes
> applied in the past to ipmr [#2, #3].
> It is then possible to re-factor a lot of the common structures - 
> vif devices [#1], mr_table [#4] mfc_cache [#6], and use the common
> structures in both ipmr and ip6mr.
> 
> The rest of the patches re-factor some choice flows used by both ipmr
> and ip6mr and eliminates duplicity.
> 
> This series would later allow for easy extension of ipmr offloading
> to support ip6mr offloading as well, as almost all structures
> related to the offloading would be shared between the two protocols.

Series applied, thank you.