Re: [vpp-dev] Question about vlib_next_frame_change_ownership

Thanks for the clarify. Makes sense. 原始邮件 主题： Re: [vpp-dev] Question about vlib_next_frame_change_ownership 来自： Damjan Marion 发至： 2019年1月25日 下午10:56 抄送： Dave Barach Just to avoid potential confusion, my recent ethernet-input change mandates that frames are not aggregated

Re: [vpp-dev] How do I get the "dpdk-shared" in VPP ?

I tried the procedure here. The name of the directory "build" is arbitrary; I used "burt." Things worked (i.e., no build errors) when I located burt under vpp but when I tried locating it under ~, cmake complained that I was not inside a git space (which is true), due to the pack.cmake file. Burt

Re: [vpp-dev] RFC: buffer manager rework

Awesome! Looking forward to using it in the host stack ;-) Florin > On Jan 25, 2019, at 9:08 AM, Damjan Marion via Lists.Fd.Io > wrote: > > > I am very close to the finish line with buffer management rework patch, and > would like to > ask people to take a look before it is merged. > >

[vpp-dev] RFC: buffer manager rework

I am very close to the finish line with buffer management rework patch, and would like to ask people to take a look before it is merged. https://gerrit.fd.io/r/16638 It significantly improves performance of buffer alloc free and introduces numa awareness. On my skylake platinum 8180 system,

Re: [vpp-dev] How do I get the "dpdk-shared" in VPP ?

I tried doing this recently and it barfed. How did you get it working? Ray K > -Original Message- > From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Marco > Varlese > Sent: Friday 25 January 2019 12:38 > To: Damjan Marion > Cc: vpp-dev@lists.fd.io > Subject: Re:

[vpp-dev] Question about crypto dev queue pairs #vpp

Hello all, Just tracing a bit the code I noticed that there is a concept of "queue pair" and every crypto device allocates its own number of queue pairs. Two questions (version 19.01): 1. Regarding the max_res_idx (ipsec.c) calculation: max_res_idx = (dev->max_qp / 2) - 1;   (if dev->max_qp == 1

Re: [vpp-dev] Question about vlib_next_frame_change_ownership

Just to avoid potential confusion, my recent ethernet-input change mandates that frames are not aggregated when they are coming from input nodes. Reason for that is much faster processing of the frame when we know in advance that all packets in frame share same sw_if_index. In other words,

Re: [vpp-dev] Question about vlib_next_frame_change_ownership

Thanks, Dave. Crystally clear! It is a deliberate design, indeed. Regards, Kingwel 原始邮件 主题： RE: [vpp-dev] Question about vlib_next_frame_change_ownership 来自： "Dave Barach (dbarach)" 发至： 2019年1月25日 下午9:03 抄送： Kingwel Xie ,vpp-dev Dear Kingwei, On a per-thread basis, only one

Re: [vpp-dev] Question about vlib_next_frame_change_ownership

Dear Kingwei, On a per-thread basis, only one input node is active at a time. In the 2x active input node case you sketched, the second input node will take frame ownership of the ethernet input frame - which should be pending but not yet dispatched - and add more buffer indices to it. It’s

Re: [vpp-dev] How do I get the "dpdk-shared" in VPP ?

Never mind... I did find the issue. All good ;) Thank you Damjan!!! On 1/25/19 1:26 PM, Marco Varlese wrote: > > > On 1/25/19 11:14 AM, Damjan Marion wrote: >> >> >>> On 25 Jan 2019, at 10:49, Marco Varlese >> > wrote: >>> >>> Hi Damjan, >>> >>> On 1/24/19 10:46 PM,

Re: [vpp-dev] How do I get the "dpdk-shared" in VPP ?

On 1/25/19 11:14 AM, Damjan Marion wrote: > > >> On 25 Jan 2019, at 10:49, Marco Varlese > > wrote: >> >> Hi Damjan, >> >> On 1/24/19 10:46 PM, Damjan Marion via Lists.Fd.Io wrote: >>> >>> In theory like any other cmake project: >>> >>> $ mkdir build >>> $ cd build >>>

Re: [vpp-dev] one question about VPP IPsec implementaions

First, performance. Second, still performance, you can use QAT with dpdk IPSEC. Also note that dpdk ipsec doesn’t support AH. And, dpdk ipsec support GCM, but native one doesn’t. There is the 3rd one, ipsecmb ipsec, which provides even better performance if using SW ciphering/hashing only. It

[vpp-dev] one question about VPP IPsec implementaions

Hi VPP expert, When I look at the IPsec code，It looks that two implementations coexists in VPP. One is dpdk IPsec, and another is native IPsec. I wonder what’s difference between them from functionality perspective? Any input is appreciated. Regards Zhiyong

Re: [vpp-dev] How do I get the "dpdk-shared" in VPP ?

> On 25 Jan 2019, at 10:49, Marco Varlese wrote: > > Hi Damjan, > > On 1/24/19 10:46 PM, Damjan Marion via Lists.Fd.Io wrote: >> >> In theory like any other cmake project: >> >> $ mkdir build >> $ cd build >> $ cmake /path/to/vpp/src >> $ make >> $ make install > Hmmm, not sure if I

Re: [vpp-dev] Question about vlib_next_frame_change_ownership

Hi Dave, After checking the code and some debug sessions, I realized where the bug is – crypto-input, which is calling vlib_trace_buffer() earlier than get_next_frame/put_next_frame. Therefore, the next_frame->flag is overwritten by get_next_frame/change_owenrship. I’ve made a patch for it:

Re: [vpp-dev] How do I get the "dpdk-shared" in VPP ?

Hi Damjan, On 1/24/19 10:46 PM, Damjan Marion via Lists.Fd.Io wrote: > > In theory like any other cmake project: > > $ mkdir build > $ cd build > $ cmake /path/to/vpp/src > $ make > $ make install Hmmm, not sure if I explained myself in the right way. The problem today is that I cannot find a

Re: [vpp-dev] Configuring NAT and Policing together

Hi, I am checking whether policing feature is enabled or not in NAT with the following approach --- Did an extern declaration for policer_classify_main_t in nat/out2in.c if (pcm->classify_table_index_by_sw_if_index[0][sw_if_index0] != ~0) { /* feature is enabled */

Re: [vpp-dev] l2 input/output feature arcs

> With gigabytes of memory used for pools and other datastructs, node > memory structure overhead is negligible imho. Fair enough :) > Check the acl plugin. I have 8 nodes > and only one instance of actual “code”. Not to say that it works perfect but > maintenance wise it is quite reasonable.