search

florincoras / envoy-vpp

Apache License 2.0
16 stars 4 forks source link

[not a real issue] question: how about the possibility put envoy-vpp into a service mesh (istio) #3

Closed KfreeZ closed 3 years ago

KfreeZ commented 3 years ago

Hi Florin,

Thanks for your exploring of envoy-vpp.

We also suffered from envoy's performance issue in our istio service mesh, I see VPP is a good solution for data path acceleration, but I think it seems a little heavy, it would be ok working with stand alone envoy. But do you see any possibility to put this solution into a service mesh? Or do you have any suggestion?

Looking forward your comments and thanks in advance.

florincoras commented 3 years ago

Hi Cliff,

Thanks for checking out the project! You're exactly right that the initial goal was to help speed up standalone envoy deployments. Consequently, I haven't yet really put enough thought into the implications of using it as part of a service mesh. When you say it's a little heavy, are you thinking about the fact that, because of device drivers, vpp will be forced to work in poll mode, i.e., cpu consumption, or about the size of the binary and memory requirements?

The good news is that the former is now solvable because 1) some device drivers, including dpdk with a subset of nics, can run in interrupt mode 2) the host stack, session layer to be precise, can also run in interrupt mode.

KfreeZ commented 3 years ago

Hi Cliff,

Thanks for checking out the project! You're exactly right that the initial goal was to help speed up standalone envoy deployments. Consequently, I haven't yet really put enough thought into the implications of using it as part of a service mesh. When you say it's a little heavy, are you thinking about the fact that, because of device drivers, vpp will be forced to work in poll mode, i.e., cpu consumption, or about the size of the binary and memory requirements?

The good news is that the former is now solvable because 1) some device drivers, including dpdk with a subset of nics, can run in interrupt mode 2) the host stack, session layer to be precise, can also run in interrupt mode.

Thanks for your reply Florin!

My first thought was if every sidecar inside the service mesh is an envoy-vpp, it would be too "heavy" because of the VPP's polling mode and taking over CPU core, that's why I raise this question.

Then I realized, it could be unnecessary run VPP in every pod, I think the it's possible that we run a VPP instance as vSwitch, exposing the VCL to the envoy, in this way, envoys links to this same vSwitch can talks to each other via the share memory by leveraging the VCL, do you think this is reasonable?

florincoras commented 3 years ago

Absolutely! Cut-through sessions, which avoid protocol overhead and exchange data over shared memory buffers, are possible between the envoys. And yes, it's enough to run vpp as a vswitch in this scenario.

KfreeZ commented 3 years ago

thanks for you answer, Florin! Great work on the envoy-vpp !!!

KfreeZ commented 2 years ago

hi Florin, I see the VCL is offical integrated with envoy, congratulations! Do you have any videos of examples of setting up the whole enviorment ?

florincoras commented 2 years ago

Thanks, Cliff! There's not much documentation but hopefully this will help.