g transports (see for instance the TLS implementation).
Until today [1] the stack did allow for excessive batching (generation of
multiple frames in one dispatch loop) but we’re now restricting that to one.
This is still far from proper pacing which is on our todo list.
Florin
[1] https://gerr
ay [1] the stack did allow for excessive batching (generation of
multiple frames in one dispatch loop) but we’re now restricting that to one.
This is still far from proper pacing which is on our todo list.
Florin
[1] https://gerrit.fd.io/r/#/c/12439/
On May 9, 2018, at 4:21 AM, Luca Muscariello
ststack-kc-eu-18.pdf
On May 7, 2018, at 11:35 AM, Luca Muscariello (lumuscar)
mailto:lumus...@cisco.com>> wrote:
Florin,
So the TCP stack does not connect to VPP using memif.
I’ll check the shared memory you mentioned.
For our transport stack we’re using memif. Nothing to
do with TCP th
has to
packetize that data.
Florin
On May 7, 2018, at 10:29 AM, Luca Muscariello (lumuscar)
mailto:lumus...@cisco.com>> wrote:
Hi Florin
Thanks for the info.
So, how do you explain VPP TCP stack beats Linux
implementation by doubling the goodput?
Does it come from vectorization?
Any s
Hi Florin
Thanks for the info.
So, how do you explain VPP TCP stack beats Linux
implementation by doubling the goodput?
Does it come from vectorization?
Any special memif optimization underneath?
Luca
On 7 May 2018, at 18:17, Florin Coras
mailto:fcoras.li...@gmail.com>> wrote:
Hi Luca,
We do
