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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20180301.132025.1152945114197884448.davem@davemloft.net>
Date:   Thu, 01 Mar 2018 13:20:25 -0500 (EST)
From:   David Miller <davem@...emloft.net>
To:     yuvalm@...lanox.com
Cc:     netdev@...r.kernel.org, nikolay@...ulusnetworks.com,
        davem@...veloft.net, mlxsw@...lanox.com, kuznet@....inr.ac.ru,
        yoshfuji@...ux-ipv6.org
Subject: Re: [PATCH v2 net-next 00/11] ipmr, ip6mr: Align multicast routing
 for IPv4 & IPv6

From: Yuval Mintz <yuvalm@...lanox.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.