On Wed, Dec 03, 2025 at 02:59:17PM +0200, Kapetanakis Giannis wrote:
> 
> On 02/12/2025 09:14, David Gwynne wrote:
> > aggr(4) is a better option for LACP for several reasons:
> >
> > - in my experience aggr is better at following the standard
> >
> > it doesn't get into weird states that blackhole traffic at the worst
> > possible times.
> >
> > - aggr is mpsafe
> >
> > the last time i looked at trying to make the lacp code mpsafe in
> > trunk(4) i ended up writing aggr(4). this lack of mpsafety is now
> > making it hard to unlock more of the network stack.
> >
> > - aggr is faster than trunk
> >
> > looking at the benchmarking we did when i first introduced aggr,
> > it looks like using trunk(4) more than halved the pps you can
> > forward through a box, while aggr was more like a 10 to 15% hit.
> > switching from trunk to aggr in our environment doubled our firewall
> > performance.
> >
> > apart from these implementation differences, there's a few operational
> > ones too that sthen@ has pointed out:
> >
> > - aggr uses a random MAC by default, trunk uses the MAC of the first-
> >   added child port.
> >
> > - aggr does not bring the interface up automatically, you must use "up".
> 
> How about failover mode on trunk???

what about it?

> Is that mpsafe? Are there plans for this?

trunk_input() looks like it needs it a bit of work to be mpsafe.
the trunkproto input handlers (other than lacp), including the
failover input handler, are so simple that it would not take a lot
of effort to make it mpsafe.

trunk_input also appears to do a bunch of work that the stack will
do for it anyway, so it could also be cut down.

the only reason i would do this work is if i can make pf_test safe to
call without the net lock, which would leave trunk as the only thing
holding us back from running the l2 processing completely unlocked. i
would also do as little as possible to get it over the line.

however, if someone is interested in working on this, id be happy to
help them.