[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20180228.113057.755675443499964734.davem@davemloft.net>
Date: Wed, 28 Feb 2018 11:30:57 -0500 (EST)
From: David Miller <davem@...emloft.net>
To: yuvalm@...lanox.com
Cc: netdev@...r.kernel.org, mlxsw@...lanox.com, kuznet@....inr.ac.ru,
yoshfuji@...ux-ipv6.org, nikolay@...ulusnetworks.com
Subject: Re: [PATCH net-next 00/11] ipmr, ip6mr: Align multicast routing
for IPv4 & IPv6
From: Yuval Mintz <yuvalm@...lanox.com>
Date: Tue, 27 Feb 2018 20:58:17 +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.
>
> Changes from previous versions
> ------------------------------
> RFC -> v1:
> - Corrected support for CONFIG_IP{,V6}_MROUTE_MULTIPLE_TABLES
> - Addressed a couple of kbuild test robot issues
Please address Nikolay's feedback on patch #7, but otherwise this
series looks fantastic, nice work!
Powered by blists - more mailing lists