Re: [vpp-dev] How vpp choose the default base va 0x130000000ULL

Got it. Thanks Dave! Dave Barach (dbarach) 于2018年9月21日周五 下午8:08写道： > Any address above the first 4gb would be fine. At this point, it’s a bit > like Avogadro’s number: when I see it, I know instantaneously which heap it > came from. > > > > If e.g. clib_mem_is_heap_object(...) ASSERTs on such

[vpp-dev] how to pull a 18.07 code??

Could someone tell me how do I pull the 18.07 code? I have never pulled tree with a label before so not sure how to do it. BTW, I pulled latest VPP (*git* clone http://gerrit.fd.io/r/vpp)and have run into the following cmake error: CMake Error at

Re: [vpp-dev] Odd problem in adding new session on vpp when its session table is full

Dear Rubina, On 9/24/18, Rubina Bianchi wrote: > Dear Andrew, > > It's hardcoded as it was simple and fast solution for our default scenario > implementation. > As you correctly mentioned in previous email one of the bug fixes was the > restriction. Also another one is preventing reply packets

[vpp-dev] Make test failures on ARM

Hi vpp-devs, Especially ARM vpp devs :) We're experiencing a number of failures on Cavium ThunderX and we'd like to fix the issues. I've created a number of Jira tickets: *GRE crash *SCTP failure/crash

Re: [vpp-dev] Support of dpdk rte_security library ?

Ok Thanks, Nitin On Monday 24 September 2018 05:36 PM, Damjan Marion wrote: External Email No AFAIK, we prefer to have native implementations. -- Damjan On 24 Sep 2018, at 13:16, Nitin Saxena > wrote: Hi, Is there any road map to support DPDK

Re: [vpp-dev] Support of dpdk rte_security library ?

No AFAIK, we prefer to have native implementations. -- Damjan > On 24 Sep 2018, at 13:16, Nitin Saxena wrote: > > Hi, > > Is there any road map to support DPDK rte_security library with IPSEC > protocol? > > Thanks, > Nitin > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent

Re: [vpp-dev] continuous decline in throughput with acl

Cool. Then it is probably indeed the session requeues that are not yet efficient... I have been looking at optimizing that. I have a draft in the works which should have less session requeues - I have just added you to it, could you give it a shot and see if it makes things better ? --a >

[vpp-dev] Support of dpdk rte_security library ?

Hi, Is there any road map to support DPDK rte_security library with IPSEC protocol? Thanks, Nitin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#10624): https://lists.fd.io/g/vpp-dev/message/10624 Mute This Topic:

Re: [vpp-dev] continuous decline in throughput with acl

yes, I confirm On Mon, Sep 24, 2018 at 2:08 PM Andrew  Yourtchenko wrote: > Okay, so what I think I am hearing - the gradual slowdown is/was always > there, and is somewhat more pronounced in master, right ? > > --a > > On 24 Sep 2018, at 11:49, khers wrote: > > I allways get SIGSEGV or

Re: [vpp-dev] continuous decline in throughput with acl

Okay, so what I think I am hearing - the gradual slowdown is/was always there, and is somewhat more pronounced in master, right ? --a > On 24 Sep 2018, at 11:49, khers wrote: > > I allways get SIGSEGV or 'worker thread dead lock' In 1804 with 1 or more > worker thread and 1 main, > but when

Re: [vpp-dev] Odd problem in adding new session on vpp when its session table is full

Dear Andrew, It's hardcoded as it was simple and fast solution for our default scenario implementation. As you correctly mentioned in previous email one of the bug fixes was the restriction. Also another one is preventing reply packets pass through even if those packets are matched with an acl

Re: [vpp-dev] continuous decline in throughput with acl

I allways get SIGSEGV or 'worker thread dead lock' In 1804 with 1 or more worker thread and 1 main, but when vpp using one cpu I hadn't any problem. In the 1807 multi core is stable i didn't see any of those problem but throughput is declining slowly. I ran another test with same version of last

[vpp-dev] VPP Release 18.10: API freeze (F0) is next week

Dear all, F0 deadline is next week (2018-10-03)!!! As of today, there is a substantial list of API changes which are pending merge in gerrit. Some of them have merge-conflict which needs author's attention. Please, remember that no API changes will be allowed after F0 deadline (2018-10- 03) so