From: David Gwynne Subject: Re: trunk(4): deprecate LACP mode To: Kapetanakis Giannis Cc: tech@openbsd.org Date: Fri, 12 Dec 2025 16:37:11 +1000 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.