All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lars Everbrand <lars.everbrand@protonmail.com>
To: Jakub Kicinski <kuba@kernel.org>
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: Tue, 15 Dec 2020 21:32:50 +0000	[thread overview]
Message-ID: <X9krelP/8MwGP0V5@black-debian> (raw)
In-Reply-To: <20201205114513.4886d15e@kicinski-fedora-pc1c0hjn.DHCP.thefacebook.com>

On Sat, Dec 05, 2020 at 11:45:13AM -0800, Jakub Kicinski wrote:
> Thanks for the patch!
Kind words for my first attempt at this. Sorry for answering a bit late,
proton-bridge is not my best friend lately.
> 
> 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.
My intention was to avoid a big change, and this was the easiest way. I
trust your opinion here.
> 
> 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?
I did not consider this case, I only test =1 and random. Yeah, it breaks
if the counter is updated per packet in any >1 case. 
> 
> 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.
I can have another look but my I am not confident that I am skilled
enough in this area to produce a larger overhaul... 


      parent reply	other threads:[~2020-12-15 21:35 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
2020-12-08 21:46   ` Jay Vosburgh
2020-12-15 21:54     ` Lars Everbrand
2020-12-15 21:32   ` Lars Everbrand [this message]

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=X9krelP/8MwGP0V5@black-debian \
    --to=lars.everbrand@protonmail.com \
    --cc=andy@greyhouse.net \
    --cc=davem@davemloft.net \
    --cc=j.vosburgh@gmail.com \
    --cc=kuba@kernel.org \
    --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.