Assistance with VPP VCL and HAProxy Multi-thread Configuration Issue

[GeekPwnStyle]

I am currently working on a project involving VPP VCL and HAProxy. I’ve encountered an issue when trying to configure both VCL and HAProxy to run in multi-threaded mode.

In my vcl.conf, I have set multi-thread-workers, and in the haproxy.conf, I have configured nbthread 4. However, when I attempt to run HAProxy with this configuration, I encounter an error with VCL. Interestingly, if I change nbthread to 1, everything works as expected, except that I am unable to use HAProxy in daemon mode.

Would you be able to provide any guidance on resolving this issue, or suggest any potential solutions that might allow me to use multi-threading with HAProxy and VCL together?

Your help would be greatly appreciated!

[KrishMMavani]

i got the same issue....have u found any solution?

[Khalid-essaghiry]

Hi @GeekPwnStyle,
I ran into the exact same problem recently and wanted to share what I found, since this discussion is still unanswered.
Root cause: nbthread > 1 in HAProxy doesn't work with VCL because VCL sessions are bound to the worker/thread that created them. When HAProxy's threading model tries to hand off a connection between its OS threads (which it does even with multi-thread-workers set in vcl.conf), VCL rejects it with:

I reproduced this consistently — nbthread 4 always failed the same way, while nbthread 1 worked reliably. multi-thread-workers in vcl.conf seems to only prepare VCL to accept multiple distinct worker registrations (e.g. multiple separate processes), not intra-process thread migration within a single HAProxy instance.
About daemon mode: I found the same limitation — HAProxy's master-worker/daemon mode does fork()/exec(), which breaks the LD_PRELOAD VCL context in the child (it doesn't cleanly re-establish the VPP app registration). Running in foreground (-db) and managing the process lifecycle externally (systemd, supervisor, etc.) worked around it.
What actually gives you parallelism: instead of one HAProxy process with nbthread N, run N separate HAProxy processes, each with nbthread 1 and its own VCL_CONFIG. Each one registers as its own app in VPP (visible via vppctl show app), so there's no cross-thread session migration involved. You can either bind them to different ports/frontends behind an upstream LB, or (if your VCL build supports it) use SO_REUSEPORT so VPP's session layer spreads new connections across the processes itself.
One more thing that cost me a lot of debugging time: make sure VCL_CONFIG is exported in the exact shell/process context before the LD_PRELOAD launch — a missing/unset VCL_CONFIG causes a silent-ish failure (vcl_bapi_init: ERROR couldn't connect to VPP!, ldp_constructor: failed!) that can look like a threading issue at first glance if you're testing things in the same terminal session.
Happy to share my full vcl.conf/haproxy.cfg/reproduction steps if that's useful — this looks like it might be worth an actual GitHub issue rather than a discussion, since it's a hard limitation rather than a config mistake.

[Khalid-essaghiry]

https://github.com/Khalid-essaghiry/vpp-vcl-haproxy-multithread/blob/main/vpp-vcl-haproxy-config.md