PR https://github.com/vyos/vyos-1x/pull/4001

Is there any way to incentivize the addition of this?

A workaround doe DHCP client to make it work again: https://github.com/vyos/vyos-1x/pull/4002

A few immediate notes, before preparing the solution:
(1) this is independent of whether one is running under configd or not
(2) this is more easily triggered under 1.4/1.5, which has default ['system', 'conntrack', 'modules'] entries (fixed in current), though can be reproduced in current with the above and 'set ... conntrack modules ..'
(3) this was avoided in 1.4.0 by the global dependency pruning; that raised other serious issues, however (T6559), due to constraints of the legacy commit algorithm.

PR https://github.com/vyos/vyos-1x/pull/4000

It looks like you are already running this with a high reporting level. Are you seeing any/all the messages on stderr? I would try all of this on the command line first, and do the VyOS cli later.

possible fix

if 'source_interface' in config:
    # my code here
    config['ifname'] = config['source_interface']

The issue is not found in 1.3.8 version but found in 1.4.0 and latest 1.5 rolling release.

@shaneshort this might look like a trivial one but we've already checked it out

Tested in the latest version 1.5-rolling-202408200022, the renaming migration works and the configuration:

Merged PR https://github.com/vyos/vyos-1x/pull/3975

Yeah I was running lcdproc in a separate window in the foreground as well, and restarted it each time I change a setting in LCDd

I think it has a interesting option `ethtool -K ethX ntuple [on|offwhich is interesting has the knowledge , we can keep it as a part the main task .

Another note—our current RPS implementation intentionally excludes core 0 from packet processing. If we want the default RSS behavior to mimic, this might mean we should be using N-1 queues where N is the number of cores. Whether this makes sense to carry over to RSS I'll leave open for debate.

Should RSS/ntuple be the default or should it be an opt-in "offload" setting?

Ack, I'm inclined to close this as a duplicate. What's the best way to mark the ticket?

I need to reopen the code from the lcdproc project as well as the platform package from Lanner and "compare".

The LCDd exit with code 1 was resolved by simply changing Driver=cwlnx to Driver=CwLnx

I now have an appliance to use for testing. Tried setting the driver to hd44780 and nothing seems to happen. Set ReportLevel to 5 on both lcdproc and LCDd.
On lcdproc the only output is

this task is already created, it involved many offload/NIC tunning which are described on this :

Doesn't cloud-init fully cover this? We are provisioning our VPN endpoints fully via that and thus never need to touch the device once it is running. You need to provide an according config file + .iso at initial boot though, which might only be feasible when VyOS runs inside a VM.