DPDK-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: Weijun Pan <wpan3636@gmail.com>
Cc: dev@dpdk.org, chas3@att.com, humin29@huawei.com
Subject: Re: [RFC] net/bonding: support limited datapath in secondary process
Date: Sat, 4 Jul 2026 09:09:18 -0700	[thread overview]
Message-ID: <20260704090918.04fc3ec7@phoenix.local> (raw)
In-Reply-To: <CAMEmXsxzEfsu1boqPrYtTbuf3j9VM0vb8JBzC-NKm4YXJFVPNw@mail.gmail.com>

On Sat, 4 Jul 2026 11:00:42 -0500
Weijun Pan <wpan3636@gmail.com> wrote:

> Hi,
> 
> I am looking into Bugzilla 1900 and real secondary-process datapath
> support for the bonding PMD.
> 
> The current secondary attach path is safe by default: secondary Rx/Tx
> uses blackhole burst functions instead of installing real per-mode
> bonding burst functions. This avoids crashes because the internal
> bonding state is not valid in the secondary process.
> 
> However, this also means that a secondary process cannot perform real
> Rx/Tx through a bonding device. This is the issue described in
> Bugzilla 1900.
> 
> I would like to discuss whether a limited secondary datapath model
> would be acceptable, without fully sharing all bonding state across
> processes.
> 
> The proposed model is:
> 
> * the primary process owns the bonding control plane;
> * the primary process owns the LACP state machine for mode 4 / 802.3ad;
> * secondary processes cannot change bond mode, add/remove members, or
> enable/disable dedicated LACP queues;
> * the primary process publishes only a minimal shared datapath state snapshot;
> * secondary processes only read this shared state for Rx/Tx decisions;
> * blackhole burst functions remain the fallback when real secondary
> datapath support is not available.
> 
> For mode 4, the shared snapshot could initially include only the state
> required by the datapath, such as the active member list and
> per-member collecting/distributing state.
> 
> This would make the secondary process a datapath consumer of
> primary-maintained bonding state, rather than a second owner of the
> bonding control plane.
> 
> Questions:
> 
> 1. Should real secondary datapath support be considered at all, or
> should bonding secondary support remain limited to safe blackhole
> Rx/Tx?
> 2. If real secondary datapath support is considered, is this limited
> secondary datapath model acceptable for the bonding PMD?
> 
> I would like to work on this if the direction sounds reasonable.
> 
> Thanks,
> Weijun

It would be great to allow secondary to do Rx/Tx. 
But it needs to be safe against primary changing datapath.

The important part is that is better to return an error or blackhole
data rather than causing crashes. If you require primary to do all
control plane; then all secondary requests need to return an error.

      reply	other threads:[~2026-07-04 16:09 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-04 16:00 [RFC] net/bonding: support limited datapath in secondary process Weijun Pan
2026-07-04 16:09 ` Stephen Hemminger [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=20260704090918.04fc3ec7@phoenix.local \
    --to=stephen@networkplumber.org \
    --cc=chas3@att.com \
    --cc=dev@dpdk.org \
    --cc=humin29@huawei.com \
    --cc=wpan3636@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox