Out of scope for VyOS

@Viacheslav yes I do understand that, but why not just keep it Open here until then? BTW, this upstream has close ties to VyOS - see https://github.com/orgs/accel-ppp/people
But there is also the original author's repo, since 2010 - https://github.com/xebd/accel-ppp - the two seem to be developed in parallel, it's a bit of a mystery to me.
While I'm in the process of moving away from VyOS (because of the recent changes, updated LTS can't be built from source anymore), I still use accel-ppp and want to help.

@marekm It has to be solved in the upstrem, https://github.com/accel-ppp/accel-ppp
It cannot be fixed otherwise.

Thanks for the contribution.

https://github.com/vyos/vyos-build/pull/828

I think @Viacheslav is right here, I added the ethernet interfaces instead and now it works. I guess maybe add something that prevents adding bonds to flowtable, and instead directs the user to add the member interfaces?

@syncer I do not think this is worthwhile/advisable to backport changes for 1.3.x, given that there is an easy workaround.

Mechanism for adding kernel boot parameters in T5979/T5980

fixed in https://vyos.dev/T2180

Just do not use bond in the flow
Use native ethernet interfaces

This was supposed to be fixed in https://vyos.dev/T5794
We may need to double check once again

Looks like it is related to T5324

Why wontfix? Does this mean that even if a fix will be available, you don't want to accept it? I'm slow but still working on it.

We not target embedded systems

Changed it to wontfix

@syncer In my opinion, it is better to have a CLI that can process network interrupts only by the local NUMA node.
As I remember, the set system option performance xxx option overrides some sysctl options if it is not fixed.
Otherwise, we have to use customer scripts to balance interrupts on the required cores.

@Viacheslav, maybe we should just run the script on such platforms instead of doing CLI?

It´s not feasible to implement this.
We may come back to it in 2.0