This patch is implementing IPV6 RLB for balance-alb mode.

Sun Shouxin (4):
  net:ipv6:Add void *data to ndisc_send_na function
  net:ipv6:Refactor ndisc_send_na to support sending na by slave
    directly
  net:ipv6:Export inet6_ifa_finish_destroy and ipv6_get_ifaddr
  net:bonding:Add support for IPV6 RLB to balance-alb mode

 drivers/net/bonding/bond_3ad.c     |   2 +-
 drivers/net/bonding/bond_alb.c     | 612 ++++++++++++++++++++++++++++-
 drivers/net/bonding/bond_debugfs.c |  14 +
 drivers/net/bonding/bond_main.c    |   6 +-
 drivers/net/usb/cdc_mbim.c         |   3 +-
 include/net/bond_3ad.h             |   2 +-
 include/net/bond_alb.h             |   7 +
 include/net/bonding.h              |   6 +-
 include/net/ipv6_stubs.h           |   3 +-
 include/net/ndisc.h                |   9 +-
 net/ipv6/addrconf.c                |   4 +-
 net/ipv6/ndisc.c                   |  64 ++-
 12 files changed, 696 insertions(+), 36 deletions(-)


base-commit: 2af7e566a8616c278e1d7287ce86cd3900bed943
-- 
2.27.0

On 3/23/22 6:09 AM, Sun Shouxin wrote:
> This patch is implementing IPV6 RLB for balance-alb mode.
> 
> Sun Shouxin (4):
>   net:ipv6:Add void *data to ndisc_send_na function
>   net:ipv6:Refactor ndisc_send_na to support sending na by slave
>     directly
>   net:ipv6:Export inet6_ifa_finish_destroy and ipv6_get_ifaddr
>   net:bonding:Add support for IPV6 RLB to balance-alb mode
> 
>  drivers/net/bonding/bond_3ad.c     |   2 +-
>  drivers/net/bonding/bond_alb.c     | 612 ++++++++++++++++++++++++++++-
>  drivers/net/bonding/bond_debugfs.c |  14 +
>  drivers/net/bonding/bond_main.c    |   6 +-
>  drivers/net/usb/cdc_mbim.c         |   3 +-
>  include/net/bond_3ad.h             |   2 +-
>  include/net/bond_alb.h             |   7 +
>  include/net/bonding.h              |   6 +-
>  include/net/ipv6_stubs.h           |   3 +-
>  include/net/ndisc.h                |   9 +-
>  net/ipv6/addrconf.c                |   4 +-
>  net/ipv6/ndisc.c                   |  64 ++-
>  12 files changed, 696 insertions(+), 36 deletions(-)
> 
> 
> base-commit: 2af7e566a8616c278e1d7287ce86cd3900bed943

net-next is closed, so this set needs to be delayed until it re-opens.

On Wed, 23 Mar 2022 08:35:03 -0600 David Ahern wrote:
> On 3/23/22 6:09 AM, Sun Shouxin wrote:
> > This patch is implementing IPV6 RLB for balance-alb mode.
>
> net-next is closed, so this set needs to be delayed until it re-opens.

What I'm not sure of is why this gets reposted after Jiri nacked
it. A conclusion needs to be reached on whether we want this
functionality in the first place. Or someone needs to explain 
to me what the conclusion is if I'm not reading the room right :)

Jakub Kicinski <kuba@kernel.org> wrote:

>On Wed, 23 Mar 2022 08:35:03 -0600 David Ahern wrote:
>> On 3/23/22 6:09 AM, Sun Shouxin wrote:
>> > This patch is implementing IPV6 RLB for balance-alb mode.
>>
>> net-next is closed, so this set needs to be delayed until it re-opens.
>
>What I'm not sure of is why this gets reposted after Jiri nacked
>it. A conclusion needs to be reached on whether we want this
>functionality in the first place. Or someone needs to explain 
>to me what the conclusion is if I'm not reading the room right :)

	The summary (from my perspective) is that the alb/rlb technology
more or less predates LACP, and is a complicated method to implement
load balancing across a set of local network peers.  The existing
implementation for IPv4 uses per-peer tailored ARP messages to "assign"
particular peers on the subnet to particular bonding interfaces.  I do
encounter users employing the alb/rlb mode, but it is uncommon; LACP is
by far the most common mode that I see, with active-backup a distant
second.

	The only real advantage alb/rlb has over LACP is that the
balance is done via traffic monitoring (i.e., assigning new peers to the
least busy bond interface, with periodic rebalances) instead of a hash
as with LACP.  In principle, some traffic patterns may end up with hash
collisions on LACP, but will be more evenly balanced via the alb/rlb
logic (but this hasn't been mentioned by the submitter that I recall).
The alb/rlb logic also balances all traffic that will transit through a
given router together (because it works via magic ARPs), so the scope of
its utility is limited.

	As much as I'm all in favor of IPv6 being a first class citizen,
I haven't seen a compelling use case or significant advantage over LACP
stated for alb/rlb over IPv6 that justifies the complexity of the
implementation that will need to be maintained going forward.

	-J

---
	-Jay Vosburgh, jay.vosburgh@canonical.com

On Wed, 23 Mar 2022 09:38:45 -0700 Jay Vosburgh wrote:
> 	The summary (from my perspective) is that the alb/rlb technology
> more or less predates LACP, and is a complicated method to implement
> load balancing across a set of local network peers.  The existing
> implementation for IPv4 uses per-peer tailored ARP messages to "assign"
> particular peers on the subnet to particular bonding interfaces.  I do
> encounter users employing the alb/rlb mode, but it is uncommon; LACP is
> by far the most common mode that I see, with active-backup a distant
> second.
> 
> 	The only real advantage alb/rlb has over LACP is that the
> balance is done via traffic monitoring (i.e., assigning new peers to the
> least busy bond interface, with periodic rebalances) instead of a hash
> as with LACP.  In principle, some traffic patterns may end up with hash
> collisions on LACP, but will be more evenly balanced via the alb/rlb
> logic (but this hasn't been mentioned by the submitter that I recall).
> The alb/rlb logic also balances all traffic that will transit through a
> given router together (because it works via magic ARPs), so the scope of
> its utility is limited.
> 
> 	As much as I'm all in favor of IPv6 being a first class citizen,
> I haven't seen a compelling use case or significant advantage over LACP
> stated for alb/rlb over IPv6 that justifies the complexity of the
> implementation that will need to be maintained going forward.

That's pretty clear, thanks!

Sun Shouxin please do not post new revisions of the patches
unless you can convince Jay your use case is strong enough,
first.

在 2022/3/24 0:38, Jay Vosburgh 写道:
> Jakub Kicinski <kuba@kernel.org> wrote:
>
>> On Wed, 23 Mar 2022 08:35:03 -0600 David Ahern wrote:
>>> On 3/23/22 6:09 AM, Sun Shouxin wrote:
>>>> This patch is implementing IPV6 RLB for balance-alb mode.
>>> net-next is closed, so this set needs to be delayed until it re-opens.
>> What I'm not sure of is why this gets reposted after Jiri nacked
>> it. A conclusion needs to be reached on whether we want this
>> functionality in the first place. Or someone needs to explain
>> to me what the conclusion is if I'm not reading the room right :)
> 	The summary (from my perspective) is that the alb/rlb technology
> more or less predates LACP, and is a complicated method to implement
> load balancing across a set of local network peers.  The existing
> implementation for IPv4 uses per-peer tailored ARP messages to "assign"
> particular peers on the subnet to particular bonding interfaces.  I do
> encounter users employing the alb/rlb mode, but it is uncommon; LACP is
> by far the most common mode that I see, with active-backup a distant
> second.
>
> 	The only real advantage alb/rlb has over LACP is that the
> balance is done via traffic monitoring (i.e., assigning new peers to the
> least busy bond interface, with periodic rebalances) instead of a hash
> as with LACP.  In principle, some traffic patterns may end up with hash
> collisions on LACP, but will be more evenly balanced via the alb/rlb
> logic (but this hasn't been mentioned by the submitter that I recall).
> The alb/rlb logic also balances all traffic that will transit through a
> given router together (because it works via magic ARPs), so the scope of
> its utility is limited.
>
> 	As much as I'm all in favor of IPv6 being a first class citizen,
> I haven't seen a compelling use case or significant advantage over LACP
> stated for alb/rlb over IPv6 that justifies the complexity of the
> implementation that will need to be maintained going forward.
>
> 	-J


Our current online environment has been deployed with mode6, except that 
we have been running ipv4 services before.
Recently, we launched ipv6 service and found that there was no load 
sharing on the receiving direction of the bond interface,
which led to wasted bandwidth on the receiving direction.

We developed this feature to solve this problem.

I'm sure many people face the same problem of not being able to change 
the environment they are already running in.
It may be true that lacp is better than alb, but we also need to 
maintain for the business that is already running.


> ---
> 	-Jay Vosburgh, jay.vosburgh@canonical.com