netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ido Schimmel <idosch@idosch.org>
To: John Hurley <john.hurley@netronome.com>
Cc: netdev@vger.kernel.org, jiri@mellanox.com, ogerlitz@mellanox.com,
	jakub.kicinski@netronome.com, simon.horman@netronome.com
Subject: Re: [RFC net-next 0/6] offload linux bonding tc ingress rules
Date: Tue, 6 Mar 2018 09:49:40 +0200	[thread overview]
Message-ID: <20180306074940.GA14599@splinter> (raw)
In-Reply-To: <1520256514-27885-1-git-send-email-john.hurley@netronome.com>

On Mon, Mar 05, 2018 at 01:28:28PM +0000, John Hurley wrote:
> To prevent sync issues between the kernel and offload device, the linux
> bond driver is affectively locked when it has offloaded rules. i.e no new
> ports can be enslaved and no slaves can be released until the offload
> rules are removed. Similarly, if a port on a bond is deleted, the bond is
> destroyed, forcing a flush of all offloaded rules.

Hi John,

I understand where this is coming from, but I don't think these
semantics are acceptable. The part about not adding new slaves might
make sense, but one needs to be able to remove slaves at any time.

Anyway, it would be much better to handle this in a generic way that
team and other stacked devices can later re-use. There's a similar sync
issue with VLAN filtering, which is handled by bond/team by calling
vlan_vids_add_by_dev() and vlan_vids_del_by_dev() in their
ndo_add_slave() and ndo_del_slave(), respectively. You can do something
similar and call into TC to replay the necessary information to the
newly added slave?

      parent reply	other threads:[~2018-03-06  7:49 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-05 13:28 [RFC net-next 0/6] offload linux bonding tc ingress rules John Hurley
2018-03-05 13:28 ` [RFC net-next 1/6] drivers: net: bonding: add tc offload infastructure to bond John Hurley
2018-03-05 13:28 ` [RFC net-next 2/6] driver: net: bonding: allow registration of tc offload callbacks in bond John Hurley
2018-03-07 10:57   ` Jiri Pirko
2018-03-05 13:28 ` [RFC net-next 3/6] drivers: net: bonding: restrict bond mods when rules are offloaded John Hurley
2018-03-05 13:28 ` [RFC net-next 4/6] nfp: add ndo_set_mac_address for representors John Hurley
2018-03-05 21:39   ` Or Gerlitz
2018-03-05 23:20     ` John Hurley
2018-03-05 13:28 ` [RFC net-next 5/6] nfp: register repr ports for bond offloads John Hurley
2018-03-05 13:28 ` [RFC net-next 6/6] nfp: support offloading multiple rules with same cookie John Hurley
2018-03-05 21:43 ` [RFC net-next 0/6] offload linux bonding tc ingress rules Or Gerlitz
2018-03-05 23:57   ` John Hurley
2018-03-06  0:16     ` Jakub Kicinski
2018-03-05 22:08 ` Jakub Kicinski
2018-03-06  2:34   ` Roopa Prabhu
2018-03-06  7:49 ` Ido Schimmel [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=20180306074940.GA14599@splinter \
    --to=idosch@idosch.org \
    --cc=jakub.kicinski@netronome.com \
    --cc=jiri@mellanox.com \
    --cc=john.hurley@netronome.com \
    --cc=netdev@vger.kernel.org \
    --cc=ogerlitz@mellanox.com \
    --cc=simon.horman@netronome.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).