From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <netdev-owner@vger.kernel.org>
Received: from shards.monkeyblade.net ([184.105.139.130]:35666 "EHLO
        shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1033225AbeCASUc (ORCPT
        <rfc822;netdev@vger.kernel.org>); Thu, 1 Mar 2018 13:20:32 -0500
Date: Thu, 01 Mar 2018 13:20:25 -0500 (EST)
Message-Id: <20180301.132025.1152945114197884448.davem@davemloft.net>
To: yuvalm@mellanox.com
Cc: netdev@vger.kernel.org, nikolay@cumulusnetworks.com,
        davem@damveloft.net, mlxsw@mellanox.com, kuznet@ms2.inr.ac.ru,
        yoshfuji@linux-ipv6.org
Subject: Re: [PATCH v2 net-next 00/11] ipmr, ip6mr: Align multicast routing
 for IPv4 & IPv6
From: David Miller <davem@davemloft.net>
In-Reply-To: <1519853379-1969-1-git-send-email-yuvalm@mellanox.com>
References: <1519853379-1969-1-git-send-email-yuvalm@mellanox.com>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

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.