[RFC] net/bonding: support limited datapath in secondary process

[RFC] net/bonding: support limited datapath in secondary process

[Weijun Pan]

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

Re: [RFC] net/bonding: support limited datapath in secondary process

[Stephen Hemminger]

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.