During sudden burst of traffic, the TCP fifo gets full. When this happens the
openssl TLS app de-schedules the transport. But once the TCP data is sent out,
the TLS is not resuming. VPP ends up in a state where TCP fifo is empty, but
the TLS fifo is full and no more Tx happens on TLS fifo.
VPP
Hi Florin,
Thank you for explaining.
>
> Out of curiosity, any particular reason why you’re looking into this? Are
> you hitting any active open performance limitations with the latest
> version of vpp?
>
While going through code for understanding, I wondered why it is being done
this way rat
Hi Florin,
Digging further into this, I got to know that only the main core handles
`vnet_connect`. The TCP connection is owned by main core while it is in active
open state. But also I see that half open table as well as other data
structures are properly locked. So will it be possible to hand
Hi Florin,
Thank you for the insight. Really helpful.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19053): https://lists.fd.io/g/vpp-dev/message/19053
Mute This Topic: https://lists.fd.io/mt/81698902/21656
Mute #hoststack:https://lists.fd.io/g/vp
Dear All,
I have been reading VPP host stack and saw the example TCP proxy in
(src/plugins/hs_apps/proxy.c).
I understand that the main thread handles the CLI command and the callbacks are
registered for TCP proxy by main thread. Can anyone explain the thread/core
ownership during packet proces
Thanks Florin! That really helped.
>
> Yes, but keep in mind that’s an explicit proxy (client connects to the
> proxy’s ip).
Yes, you're right. How about a transparent one by listening on 0/0 all ports
and by modifying proxy to use src and dst ip dynamically for the other
connection?
>
> Not
