Hi Yalei, Pretty much. We supported nginx forking at one point, but that code was not maintained.
I’m now working on refactoring vcl and in the process adding multiple worker support in both vcl and the stack. The high level plan is pretty much the one I’ve stated on the list. I don’t have anything beyond that written down but if you have specific questions in mind, I’ll try to answer them :-) As for your question concerning Envoy, I’m tempted to answer yes, mainly because latency/throughput is important for it. Will it work with LDP after I finish the refactor? I don’t know! I’ve never looked at the code and how it uses the sockets. Who knows, we may get lucky :-) Florin > On Aug 2, 2018, at 11:18 PM, 汪亚雷 <wyland...@gmail.com> wrote: > > Hi Dave & Florin, > > I am curious about this line "(and only with single workers)." ? could you > light me some more? do you mean vcl support the APP which has one worker now, > the app could not 'fork'? > > And as you mentioned, refactoring VCL infrastructure, is there a detailed > plan? will it be completed in 18.10? > > If you advice "refactor legacy applications to use the VCL API directly." , > for the envoy integration, modification for envoy src code is necessary? > > Thank you all! > > /Yalei > > Dave Wallace <dwallac...@gmail.com <mailto:dwallac...@gmail.com>> > 于2018年8月1日周三 上午3:39写道： > Florin is correct. There is also a performance and/or scaling penalty due to > the need to handle both kernel socket based file descriptors and VCL/VPP > created file descriptors with the LD_PRELOAD callback functions. > > Thanks, > -daw- > > On 7/31/18 2:11 PM, Florin Coras wrote: >> Hi Matt, >> >> I’d say that trying to cover all possible combinations of POSIX calls is the >> main issue. Also, statically linked applications won’t work fine with >> ld_preload. But, I’ll let Dave provide more details since he is more closely >> involved with the effort. >> >> Florin >> >> >>> On Jul 31, 2018, at 7:01 AM, Matthew Smith <mgsm...@netgate.com >>> <mailto:mgsm...@netgate.com>> wrote: >>> >>> >>> Hi Florin and Dave, >>> >>> I’m curious what problems were observed with the LD_PRELOAD mechanism. Were >>> there performance issues? Or was it too difficult to try and cover >>> different usage of POSIX calls? Or something else? >>> >>> Thanks! >>> -Matt >>> >>> >>>> On Jul 30, 2018, at 10:39 AM, Florin Coras <fcoras.li...@gmail.com >>>> <mailto:fcoras.li...@gmail.com>> wrote: >>>> >>>> Prashant, >>>> >>>> Dave is exactly right. If you still want to try out the LDP layer, I >>>> wouldn’t set a global LD_PRELOAD variable because that will end up >>>> preloading all the applications and, inevitably, to some unsupported usage >>>> patterns and crashes. Instead, start only your app with LD_PRELOAD set, >>>> something like: >>>> >>>> LD_PRELOAD=../vpp/build-root/install-vpp_debug-native/vpp/lib64/libvcl_ldpreload.so >>>> <your_app> >>>> >>>> Note that we’re exercising both the vcl and ldp layers with our test >>>> infrastructure. So, you may also want to take a look at test_vcl for more >>>> details on how we use the ldp layer. >>>> >>>> Hope this helps, >>>> Florin >>>> >>>> >>>>> On Jul 30, 2018, at 8:09 AM, Dave Wallace <dwallac...@gmail.com >>>>> <mailto:dwallac...@gmail.com>> wrote: >>>>> >>>>> Prashant, >>>>> >>>>> The VCL LD_PRELOAD library is experimental and only works with a very >>>>> limited set of legacy POSIX sockets applications (and only with single >>>>> workers). >>>>> >>>>> The conclusion based on the results of the initial experimentation with >>>>> LD_PRELOAD is that it is not a viable mechanism for accelerating legacy >>>>> POSIX sockets based applications using the VPP host stack. The current >>>>> recommendation is to refactor legacy applications to use the VCL API >>>>> directly. >>>>> >>>>> You should also be aware that the VCL infrastructure is in the middle of >>>>> being refactored at this time and thus the VCL API may change. I'll let >>>>> Florin, who is doing the refactoring, add his input on the VCL API >>>>> roadmap. >>>>> >>>>> Thanks, >>>>> -daw- >>>>> >>>>> On 7/30/2018 7:21 AM, Prashant Upadhyaya wrote: >>>>>> Hi, >>>>>> >>>>>> I have compiled VPP and it's running. I have an interface up and can >>>>>> ping the IP applied there. >>>>>> >>>>>> Now I am trying to bring up a legacy application TCP server (the one >>>>>> which uses POSIX calls). So I set the LD_PRELOAD to point to >>>>>> .../vpp/build-root/install-vpp_debug-native/vpp/lib64/libvcl_ldpreload.so >>>>>> But the server application now crashes on startup. >>>>>> Even the ldd command starts crashing. >>>>>> >>>>>> Can somebody point me to the correct set of steps to be used for >>>>>> LD_PRELOAD to bring up my legacy tcp server which will then engage the >>>>>> VPP TCP stack instead of the kernel's >>>>>> >>>>>> Regards >>>>>> -Prashant >>>>>> >>>>>> >>>>>> -=-=-=-=-=-=-=-=-=-=-=- >>>>>> Links: You receive all messages sent to this group. >>>>>> >>>>>> View/Reply Online (#9971): https://lists.fd.io/g/vpp-dev/message/9971 >>>>>> <https://lists.fd.io/g/vpp-dev/message/9971> >>>>>> Mute This Topic: https://lists.fd.io/mt/23858819/675079 >>>>>> <https://lists.fd.io/mt/23858819/675079> >>>>>> Group Owner: vpp-dev+ow...@lists.fd.io <mailto:vpp-dev+ow...@lists.fd.io> >>>>>> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub >>>>>> <https://lists.fd.io/g/vpp-dev/unsub> [dwallac...@gmail.com >>>>>> <mailto:dwallac...@gmail.com>] >>>>>> -=-=-=-=-=-=-=-=-=-=-=- >>>>> >>>>> -=-=-=-=-=-=-=-=-=-=-=- >>>>> Links: You receive all messages sent to this group. >>>>> >>>>> View/Reply Online (#9973): https://lists.fd.io/g/vpp-dev/message/9973 >>>>> <https://lists.fd.io/g/vpp-dev/message/9973> >>>>> Mute This Topic: https://lists.fd.io/mt/23858819/675152 >>>>> <https://lists.fd.io/mt/23858819/675152> >>>>> Group Owner: vpp-dev+ow...@lists.fd.io <mailto:vpp-dev+ow...@lists.fd.io> >>>>> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub >>>>> <https://lists.fd.io/g/vpp-dev/unsub> [fcoras.li...@gmail.com >>>>> <mailto:fcoras.li...@gmail.com>] >>>>> -=-=-=-=-=-=-=-=-=-=-=- >>>> >>>> -=-=-=-=-=-=-=-=-=-=-=- >>>> Links: You receive all messages sent to this group. >>>> >>>> View/Reply Online (#9974): https://lists.fd.io/g/vpp-dev/message/9974 >>>> <https://lists.fd.io/g/vpp-dev/message/9974> >>>> Mute This Topic: https://lists.fd.io/mt/23858819/675725 >>>> <https://lists.fd.io/mt/23858819/675725> >>>> Group Owner: vpp-dev+ow...@lists.fd.io <mailto:vpp-dev+ow...@lists.fd.io> >>>> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub >>>> <https://lists.fd.io/g/vpp-dev/unsub> [mgsm...@netgate.com >>>> <mailto:mgsm...@netgate.com>] >>>> -=-=-=-=-=-=-=-=-=-=-=- >>> >> > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > > View/Reply Online (#9995): https://lists.fd.io/g/vpp-dev/message/9995 > <https://lists.fd.io/g/vpp-dev/message/9995> > Mute This Topic: https://lists.fd.io/mt/23858819/675329 > <https://lists.fd.io/mt/23858819/675329> > Group Owner: vpp-dev+ow...@lists.fd.io <mailto:vpp-dev%2bow...@lists.fd.io> > Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub > <https://lists.fd.io/g/vpp-dev/unsub> [wyland...@gmail.com > <mailto:wyland...@gmail.com>] > -=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#10033): https://lists.fd.io/g/vpp-dev/message/10033 Mute This Topic: https://lists.fd.io/mt/23858819/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
