Hi Hanlin, And here’s the patch [1].
Regards, Florin [1] https://gerrit.fd.io/r/c/vpp/+/30185 > On Nov 27, 2020, at 9:07 AM, Florin Coras via lists.fd.io > <fcoras.lists=gmail....@lists.fd.io> wrote: > > Hi Hanlin, > > Good point! I actually have that on my todo list to see how/if it affects > performance. The other way around we should be somewhat safer after the > switch to the new socket api (instead of the binary api with socket > transport). That is, vpp detects if an app goes down almost instantly. > > Regards, > Florin > >> On Nov 26, 2020, at 11:55 PM, wanghanlin <wanghan...@corp.netease.com >> <mailto:wanghan...@corp.netease.com>> wrote: >> >> Hi Florin， >> I have another problem about this, that is VPP crash with a mutex lock of >> svm_queue_t, then VCL hang when locking this mutex, vice versa. >> Should we use pthread_mutexattr_setrobust_np to solve this problem? >> >> Regards, >> Hanlin >> >> >> wanghanlin >> >> wanghan...@corp.netease.com >> >> <https://maas.mail.163.com/dashi-web-extend/html/proSignature.html?ftlId=1&name=wanghanlin&uid=wanghanlin%40corp.netease.com&iconUrl=https%3A%2F%2Fmail-online.nosdn.127.net%2Fqiyelogo%2FdefaultAvatar.png&items=%5B%22wanghanlin%40corp.netease.com%22%5D&logoUrl=https%3A%2F%2Fmail-online.nosdn.127.net%2Fqiyeicon%2F209a2912f40f6683af56bb7caff1cb54.png> >> 签名由 网易邮箱大师 <https://mail.163.com/dashi/dlpro.html?from=mail81> 定制 >> On 3/24/2020 19:56，Dave Barach (dbarach)<dbar...@cisco.com> >> <mailto:dbar...@cisco.com> wrote： >> This limitation should come as no surprise, and it’s hardly a “big” >> limitation. >> >> Options include building container images which match the host distro, or >> using a vpp snap image on the host which corresponds to the container images. >> >> Given that there are two ways to deal with the situation, pick your favorite >> and move on. >> >> From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> <vpp-dev@lists.fd.io >> <mailto:vpp-dev@lists.fd.io>> On Behalf Of wanghanlin >> Sent: Monday, March 23, 2020 10:16 PM >> To: fcoras.li...@gmail.com <mailto:fcoras.li...@gmail.com> >> Cc: vpp-dev@lists.fd.io >> Subject: Re: [vpp-dev] [VCL] Memory access error for different size of mutex >> with different glibc versions in VPP and VCL app >> >> Hi Florin, >> It's not only regarding compiled with the same glibc version, but running >> with the same glibc version also because libpthread is dynamically linked >> into VCL and VPP. >> This is really a big limitation. >> >> Regards, >> Hanlin >> >> >> wanghanlin >> >> wanghan...@corp.netease.com <mailto:wanghan...@corp.netease.com> >> 签名由 网易邮箱大师 <https://mail.163.com/dashi/dlpro.html?from=mail81> 定制 >> On 3/23/2020 23:31，Florin Coras<fcoras.li...@gmail.com> >> <mailto:fcoras.li...@gmail.com> wrote： >> Hi Hanlin, >> >> Unfortunately, you’ll have to make sure all code has been compiled with the >> same glibc version. I’ve heard that glibc changed in ubuntu 20.04 but I >> haven’t done any testing with it yet. >> >> Note that the binary api also makes use of svm_queue_t. >> >> Regards, >> Florin >> >> >> On Mar 22, 2020, at 10:49 PM, wanghanlin <wanghan...@corp.netease.com >> <mailto:wanghan...@corp.netease.com>> wrote: >> >> Hi All, >> Now, VCL app and VPP shared some data structures, such as svm_queue_t. In >> svm_queue_t, there are mutex and condvar variables that depends on specified >> glibc version. >> When VPP run in host and VCL app run in a docker container, glibc versions >> maybe different between VPP and VCL app, and then result in memory access >> error for different size of mutex and condvar. >> Has anyone noticed this? >> >> Regards, >> Hanlin >> >> wanghanlin >> >> wanghan...@corp.netease.com <mailto:wanghan...@corp.netease.com> >> 签名由 网易邮箱大师 <https://mail.163.com/dashi/dlpro.html?from=mail81> 定制 >> > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18202): https://lists.fd.io/g/vpp-dev/message/18202 Mute This Topic: https://lists.fd.io/mt/72485607/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
