All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Lars Everbrand <lars.everbrand@protonmail.com>
Cc: linux-kernel@vger.kernel.org, Jay Vosburgh <j.vosburgh@gmail.com>,
	Veaceslav Falico <vfalico@gmail.com>,
	Andy Gospodarek <andy@greyhouse.net>,
	"David S. Miller" <davem@davemloft.net>,
	netdev@vger.kernel.org
Subject: Re: [PATCH net-next] bonding: correct rr balancing during link failure
Date: Sat, 5 Dec 2020 11:45:13 -0800	[thread overview]
Message-ID: <20201205114513.4886d15e@kicinski-fedora-pc1c0hjn.DHCP.thefacebook.com> (raw)
In-Reply-To: <X8f/WKR6/j9k+vMz@black-debian>

On Wed, 02 Dec 2020 20:55:57 +0000 Lars Everbrand wrote:
> This patch updates the sending algorithm for roundrobin to avoid
> over-subscribing interface(s) when one or more interfaces in the bond is
> not able to send packets. This happened when order was not random and
> more than 2 interfaces were used.
> 
> Previously the algorithm would find the next available interface
> when an interface failed to send by, this means that most often it is
> current_interface + 1. The problem is that when the next packet is to be
> sent and the "normal" algorithm then continues with interface++ which
> then hits that same interface again.
> 
> This patch updates the resending algorithm to update the global counter
> of the next interface to use.
> 
> Example (prior to patch):
> 
> Consider 6 x 100 Mbit/s interfaces in a rr bond. The normal order of links
> being used to send would look like:
> 1 2 3 4 5 6  1 2 3 4 5 6  1 2 3 4 5 6 ...
> 
> If, for instance, interface 2 where unable to send the order would have been:
> 1 3 3 4 5 6  1 3 3 4 5 6  1 3 3 4 5 6 ...
> 
> The resulting speed (for TCP) would then become:
> 50 + 0 + 100 + 50 + 50 + 50 = 300 Mbit/s
> instead of the expected 500 Mbit/s.
> 
> If interface 3 also would fail the resulting speed would be half of the
> expected 400 Mbit/s (33 + 0 + 0 + 100 + 33 + 33).
> 
> Signed-off-by: Lars Everbrand <lars.everbrand@protonmail.com>

Thanks for the patch!

Looking at the code in question it feels a little like we're breaking
abstractions if we bump the counter directly in get_slave_by_id.

For one thing when the function is called for IGMP packets the counter
should not be incremented at all. But also if packets_per_slave is not
1 we'd still be hitting the same leg multiple times (packets_per_slave
/ 2). So it seems like we should round the counter up somehow?

For IGMP maybe we don't have to call bond_get_slave_by_id() at all,
IMHO, just find first leg that can TX. Then we can restructure
bond_get_slave_by_id() appropriately for the non-IGMP case.

> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index e0880a3840d7..e02d9c6d40ee 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -4107,6 +4107,7 @@ static struct slave *bond_get_slave_by_id(struct bonding *bond,
>  		if (--i < 0) {
>  			if (bond_slave_can_tx(slave))
>  				return slave;
> +			bond->rr_tx_counter++;
>  		}
>  	}
>  
> @@ -4117,6 +4118,7 @@ static struct slave *bond_get_slave_by_id(struct bonding *bond,
>  			break;
>  		if (bond_slave_can_tx(slave))
>  			return slave;
> +		bond->rr_tx_counter++;
>  	}
>  	/* no slave that can tx has been found */
>  	return NULL;


  reply	other threads:[~2020-12-05 19:46 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-02 20:55 [PATCH net-next] bonding: correct rr balancing during link failure Lars Everbrand
2020-12-05 19:45 ` Jakub Kicinski [this message]
2020-12-08 21:46   ` Jay Vosburgh
2020-12-15 21:54     ` Lars Everbrand
2020-12-15 21:32   ` Lars Everbrand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201205114513.4886d15e@kicinski-fedora-pc1c0hjn.DHCP.thefacebook.com \
    --to=kuba@kernel.org \
    --cc=andy@greyhouse.net \
    --cc=davem@davemloft.net \
    --cc=j.vosburgh@gmail.com \
    --cc=lars.everbrand@protonmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=vfalico@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.