Re: [vpp-dev] Regarding /var/run/.rte_config

[Prashant Upadhyaya]

Hi again Damjan,

I am currently using VPP release 18.01 which just has the tx capture
functionality.
I see that VPP release 18.07 has introduced the rx capture functionality.

At the moment, upgrading my release to 18.01 is not an option.
Can you please advise how easy or difficult it will be to backport the
rx capture functionality and add it as a patch to 18.01.

Regards
-Prashant

On Thu, Jul 26, 2018 at 4:56 PM, Prashant Upadhyaya
 wrote:
> Thanks Damjan,
>
> I had a temporary brain-freeze, I do see there is a max parameter as well.
>
> Regards
> -Prashant
>
>
> On Thu, Jul 26, 2018 at 4:46 PM, Prashant Upadhyaya
>  wrote:
>> Hi Damjan,
>>
>> Thanks for your CLI pointers.
>> It seems there is a limit of 100 packets which would work against my
>> requirements.
>> If you have any suggestions there before I look into the code to
>> tinker with the 100, please do let me know.
>>
>> Regards
>> -Prashant
>>
>>
>> On Thu, Jul 26, 2018 at 4:24 PM, Damjan Marion  wrote:
>>> Dear Prashant,
>>>
>>> Try "pcap rx trace" and "pcap tx trace" command.
>>>
>>> https://git.fd.io/vpp/tree/src/plugins/dpdk/device/cli.c#n373
>>>
>>> Also please note that VPP packet generator (pg) supports both pcap play and
>>> capture...
>>>
>>> --
>>> Damjan
>>>
>>> On 26 Jul 2018, at 12:42, Prashant Upadhyaya  wrote:
>>>
>>> Hi Damjan,
>>>
>>> I was hoping to use the dpdk-pdump utility (built as part of DPDK) to
>>> generate the pcap files for traffic passing through the various ports.
>>> I have used that successfully with pure vanilla DPDK primary processes
>>> (non VPP usecases). It runs as a secondary process.
>>>
>>> Well, my requirement is to generate pcap's for ports on both tx and rx
>>> -- if you have an alternate VPP-core solution, that would be great.
>>>
>>> Regards
>>> -Prashant
>>>
>>>
>>> On Wed, Jul 25, 2018 at 11:32 PM, Damjan Marion  wrote:
>>>
>>>
>>> Dear Prashant,
>>>
>>> We had lot of operational issues with dpdk leftover files in the past, so
>>> we took special care to made them disappear ASAP.
>>>
>>> Even if they are present you will not be able to use secondary process,
>>> we simply don't support that use case. Secondary process will not be
>>> able to access buffer memory as buffer memory is allocated by VPP and not by
>>> DPDK.
>>>
>>> Please note that VPP is not application built on top of DPDK, for us DPDK is
>>> just
>>> source of device drivers wit a bit of weight around them. Typical VPP
>>> feature
>>> code can work even without DPDK being present.
>>>
>>> If you explain your use case we might be able to advise you how to approach
>>> your problem
>>> in a way native to VPP,  without relying on DPDK legacy features.
>>>
>>> Regards,
>>>
>>> --
>>> Damjan
>>>
>>> On 25 Jul 2018, at 13:11, Prashant Upadhyaya  wrote:
>>>
>>> Hi,
>>>
>>> I am running VPP with DPDK plugin.
>>> I see that when I normally run other non VPP DPDK applications, they
>>> create a file called /var/run/.rte_config
>>> But VPP running as a DPDK application (and calling rte_eal_init) does
>>> not create this file.
>>>
>>> There are consequences of the above in certain usecases where
>>> secondary processes try to look at this file.
>>>
>>> Can somebody advise why this file is not created when VPP is run with
>>> DPDK plugin. Or what needs to be done so that it does get created, or
>>> perhaps it is getting created somewhere that I am not aware of. I am
>>> running VPP as root.
>>>
>>> Regards
>>> -Prashant
>>> -=-=-=-=-=-=-=-=-=-=-=-
>>> Links: You receive all messages sent to this group.
>>>
>>> View/Reply Online (#9929): https://lists.fd.io/g/vpp-dev/message/9929
>>> Mute This Topic: https://lists.fd.io/mt/23811660/675642
>>> Group Owner: vpp-dev+ow...@lists.fd.io
>>> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [dmar...@me.com]
>>> -=-=-=-=-=-=-=-=-=-=-=-
>>>
>>>
>>>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#9957): https://lists.fd.io/g/vpp-dev/message/9957
Mute This Topic: https://lists.fd.io/mt/23811660/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Regarding /var/run/.rte_config

[Damjan Marion via Lists.Fd.Io]

Dear Prashant,

"git blame" is your friend. He can easily tell you which patch introduced that 
functionality.
And than you can try to cherry-pick it on top of 18.01

-- 
Damjan

> On 28 Jul 2018, at 07:27, Prashant Upadhyaya  wrote:
> 
> Hi again Damjan,
> 
> I am currently using VPP release 18.01 which just has the tx capture
> functionality.
> I see that VPP release 18.07 has introduced the rx capture functionality.
> 
> At the moment, upgrading my release to 18.01 is not an option.
> Can you please advise how easy or difficult it will be to backport the
> rx capture functionality and add it as a patch to 18.01.
> 
> Regards
> -Prashant
> 
> On Thu, Jul 26, 2018 at 4:56 PM, Prashant Upadhyaya
>  wrote:
>> Thanks Damjan,
>> 
>> I had a temporary brain-freeze, I do see there is a max parameter as well.
>> 
>> Regards
>> -Prashant
>> 
>> 
>> On Thu, Jul 26, 2018 at 4:46 PM, Prashant Upadhyaya
>>  wrote:
>>> Hi Damjan,
>>> 
>>> Thanks for your CLI pointers.
>>> It seems there is a limit of 100 packets which would work against my
>>> requirements.
>>> If you have any suggestions there before I look into the code to
>>> tinker with the 100, please do let me know.
>>> 
>>> Regards
>>> -Prashant
>>> 
>>> 
>>> On Thu, Jul 26, 2018 at 4:24 PM, Damjan Marion  wrote:
 Dear Prashant,
 
 Try "pcap rx trace" and "pcap tx trace" command.
 
 https://git.fd.io/vpp/tree/src/plugins/dpdk/device/cli.c#n373
 
 Also please note that VPP packet generator (pg) supports both pcap play and
 capture...
 
 --
 Damjan
 
 On 26 Jul 2018, at 12:42, Prashant Upadhyaya  
 wrote:
 
 Hi Damjan,
 
 I was hoping to use the dpdk-pdump utility (built as part of DPDK) to
 generate the pcap files for traffic passing through the various ports.
 I have used that successfully with pure vanilla DPDK primary processes
 (non VPP usecases). It runs as a secondary process.
 
 Well, my requirement is to generate pcap's for ports on both tx and rx
 -- if you have an alternate VPP-core solution, that would be great.
 
 Regards
 -Prashant
 
 
 On Wed, Jul 25, 2018 at 11:32 PM, Damjan Marion  wrote:
 
 
 Dear Prashant,
 
 We had lot of operational issues with dpdk leftover files in the past, so
 we took special care to made them disappear ASAP.
 
 Even if they are present you will not be able to use secondary process,
 we simply don't support that use case. Secondary process will not be
 able to access buffer memory as buffer memory is allocated by VPP and not 
 by
 DPDK.
 
 Please note that VPP is not application built on top of DPDK, for us DPDK 
 is
 just
 source of device drivers wit a bit of weight around them. Typical VPP
 feature
 code can work even without DPDK being present.
 
 If you explain your use case we might be able to advise you how to approach
 your problem
 in a way native to VPP,  without relying on DPDK legacy features.
 
 Regards,
 
 --
 Damjan
 
 On 25 Jul 2018, at 13:11, Prashant Upadhyaya  
 wrote:
 
 Hi,
 
 I am running VPP with DPDK plugin.
 I see that when I normally run other non VPP DPDK applications, they
 create a file called /var/run/.rte_config
 But VPP running as a DPDK application (and calling rte_eal_init) does
 not create this file.
 
 There are consequences of the above in certain usecases where
 secondary processes try to look at this file.
 
 Can somebody advise why this file is not created when VPP is run with
 DPDK plugin. Or what needs to be done so that it does get created, or
 perhaps it is getting created somewhere that I am not aware of. I am
 running VPP as root.
 
 Regards
 -Prashant
 -=-=-=-=-=-=-=-=-=-=-=-
 Links: You receive all messages sent to this group.
 
 View/Reply Online (#9929): https://lists.fd.io/g/vpp-dev/message/9929
 Mute This Topic: https://lists.fd.io/mt/23811660/675642
 Group Owner: vpp-dev+ow...@lists.fd.io
 Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [dmar...@me.com]
 -=-=-=-=-=-=-=-=-=-=-=-
 
 
 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#9958): https://lists.fd.io/g/vpp-dev/message/9958
Mute This Topic: https://lists.fd.io/mt/23811660/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [csit-dev] [vpp-dev] Parallel test execution in VPP Test Framework

[Dave Barach via Lists.Fd.Io]

Guys,

The current behavior is probably not what the code author intended. It’s easy 
to change. I’ve already offered under separate cover to push a draft patch 
which won’t do this under any circumstances, so folks can kick the tires.

In its final form, a command-line argument of the form “... cpu { 
no-thread-affinity } ...”

HTH... Dave

From: vpp-dev@lists.fd.io  On Behalf Of Peter Mikus via 
Lists.Fd.Io
Sent: Friday, July 27, 2018 2:46 PM
To: Maciek Konstantynowicz (mkonstan) ; Alec Hothan 
(ahothan) ; Juraj Linkeš ; 
vpp-dev@lists.fd.io
Cc: vpp-dev@lists.fd.io
Subject: Re: [csit-dev] [vpp-dev] Parallel test execution in VPP Test Framework

Hello,


  *   What is the “significant problem” you’re running into?

The problem can be better described as: When python is spawning N instances of 
VPP process, all processes are from unknown reason placed with affinity 0x2 
(bin 10). This can be verified by taskset –p . CFS is then placing all 
VPP process to the same core, making it inefficient on multicore jenkins slave 
container.
The default vpp startup.conf is not modified thus there is no input to know 
where to pin the vpp threads. Simply one can said or think that this is related 
to python multiprocess/subprocess.popen code, which is hard-setting affinity 
mask to 0x2.

There are multiple solutions for workaround that Juraj proposed or Maciek, but 
none of them is answering why is this happening.

Peter Mikus
Engineer – Software
Cisco Systems Limited

From: csit-...@lists.fd.io 
[mailto:csit-...@lists.fd.io] On Behalf Of Maciek Konstantynowicz (mkonstan) 
via Lists.Fd.Io
Sent: Friday, July 27, 2018 6:53 PM
To: Alec Hothan (ahothan) mailto:ahot...@cisco.com>>; Juraj 
Linkeš mailto:juraj.lin...@pantheon.tech>>
Cc: csit-...@lists.fd.io
Subject: Re: [csit-dev] [vpp-dev] Parallel test execution in VPP Test Framework

Alec, This is about make test and not real packet forwarding. Per Juraj’s patch 
[1]

Juraj, My understanding is that if you’re starting VPP without specifying core 
placement in startup.conf [2] cpu {..}, then Linux CFS will be placing the 
threads onto available cpu core resources. If you’re saying this is not the 
case, and indeed the wiki comment indicates this, then the way to address it is 
to specify different core for main.c thread per vpp instance.

What is the “significant problem” you’re running into? Are tests not executing 
in parallel using python multiprocessing, are vpp’s having issues, else? Could 
you describe it a bit more?

-Maciek

[1] https://gerrit.fd.io/r/#/c/13491/
[2] https://git.fd.io/vpp/tree/src/vpp/conf/startup.conf

On 27 Jul 2018, at 17:23, Alec Hothan (ahothan) 
mailto:ahot...@cisco.com>> wrote:

Hi Juraj,
How many instances and what level of performance are you looking at?
Even if you assign different cores to each VPP instance, results can be skewed 
due to interference at the LLC and PCIe/NIC level (this can be somewhat 
mitigated by running on separate sockets)

   Alec


From: mailto:vpp-dev@lists.fd.io>> on behalf of Juraj 
Linkeš mailto:juraj.lin...@pantheon.tech>>
Date: Friday, July 27, 2018 at 7:25 AM
To: "Maciek Konstantynowicz (mkonstan)" 
mailto:mkons...@cisco.com>>
Cc: "vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>, csit-dev 
mailto:csit-...@lists.fd.io>>
Subject: Re: [vpp-dev] Parallel test execution in VPP Test Framework

Hi Maciek and vpp-devs,

I've run into a significant problem regarding VPP assignment to cores. All VPPs 
that are spawned are assigned to core 1. I looked at 
https://wiki.fd.io/view/VPP/Command-line_Arguments and I guess it's because 
that's the default behavior of VPP (dpdk coremask is not configured and  Note 
that the "main" thread always occupies the lowest core-id specified in the DPDK 
[process-level] coremask.").

Is my reading of the config options accurate?

Obviously, all VPP instances running on the same core goes against running the 
tests on multiple cores. There are a couple of solutions that come to mind:
• Assign VPP instances to cores manually. With possible multiple jobs 
running on a given host, this creates a situation where the different jobs 
don't know cores are already occupied (and by how many VPP instances) and thus 
introduces additional challenges to solve.
• Add an option to override this default behavior and let the Linux CFS 
scheduler assign VPPs to cores or something similar where VPPs would land on 
different cores.

Is there some other solution?

Vpp-devs, what do you think about the second solution? What it be possible?

Thanks,
Juraj

From: Maciek Konstantynowicz (mkonstan) [mailto:mkons...@cisco.com]
Sent: Wednesday, July 25, 2018 1:10 PM
To: Juraj Linkeš mailto:juraj.lin...@pantheon.tech>>
Cc: vpp-dev@lists.fd.io; csit-dev 
mailto:csit-...@lists.fd.io>>
Subject: Re: [vpp-dev] Parallel test execution in VPP Test Framework





On 19 Jul 2018, at 15:44, Jura

Re: [csit-dev] [vpp-dev] Parallel test execution in VPP Test Framework

[Damjan Marion via Lists.Fd.Io]

Dear All,

My personal preference is that make test  framework implements cpu assignment 
code.
It should't be rocket science to parse /sys/devices/system/cpu/online and give 
one cpu to each instance.
It will also help to test framework to understand how many parallel jobs it can 
run...

Enforcing single cpu assignment in vpp is done intentionally, to avoid cross 
numa memory allocation.
If main-core is not specified, vpp simply uses cpu core 1 (unless only 0 
exists).
While adding something like "cpu { main-core any} " should be quite straight 
forward, it will have broken
behaviour when dpdk is loaded and it will just confuse people. Also, we will 
need to come back to the
drawing board when we decide to run multiple workers in make test, as logic 
there is more complex and will likely require 
rework of the thread placement code.

-- 
Damjan

> On 27 Jul 2018, at 20:46, Peter Mikus via Lists.Fd.Io 
>  wrote:
> 
> Hello,
>  
> Ø  What is the “significant problem” you’re running into?
>  
> The problem can be better described as: When python is spawning N instances 
> of VPP process, all processes are from unknown reason placed with affinity 
> 0x2 (bin 10). This can be verified by taskset –p . CFS is then 
> placing all VPP process to the same core, making it inefficient on multicore 
> jenkins slave container.
> The default vpp startup.conf is not modified thus there is no input to know 
> where to pin the vpp threads. Simply one can said or think that this is 
> related to python multiprocess/subprocess.popen code, which is hard-setting 
> affinity mask to 0x2. 
>  
> There are multiple solutions for workaround that Juraj proposed or Maciek, 
> but none of them is answering why is this happening.
>  
> Peter Mikus
> Engineer – Software
> Cisco Systems Limited
>  
> From: csit-...@lists.fd.io  
> [mailto:csit-...@lists.fd.io ] On Behalf Of 
> Maciek Konstantynowicz (mkonstan) via Lists.Fd.Io
> Sent: Friday, July 27, 2018 6:53 PM
> To: Alec Hothan (ahothan) mailto:ahot...@cisco.com>>; 
> Juraj Linkeš mailto:juraj.lin...@pantheon.tech>>
> Cc: csit-...@lists.fd.io 
> Subject: Re: [csit-dev] [vpp-dev] Parallel test execution in VPP Test 
> Framework
>  
> Alec, This is about make test and not real packet forwarding. Per Juraj’s 
> patch [1]
>  
> Juraj, My understanding is that if you’re starting VPP without specifying 
> core placement in startup.conf [2] cpu {..}, then Linux CFS will be placing 
> the threads onto available cpu core resources. If you’re saying this is not 
> the case, and indeed the wiki comment indicates this, then the way to address 
> it is to specify different core for main.c thread per vpp instance.
>  
> What is the “significant problem” you’re running into? Are tests not 
> executing in parallel using python multiprocessing, are vpp’s having issues, 
> else? Could you describe it a bit more? 
>  
> -Maciek 
>  
> [1] https://gerrit.fd.io/r/#/c/13491/ 
> [2] https://git.fd.io/vpp/tree/src/vpp/conf/startup.conf 
> 
> 
> 
> On 27 Jul 2018, at 17:23, Alec Hothan (ahothan)  > wrote:
>  
> Hi Juraj,
> How many instances and what level of performance are you looking at?
> Even if you assign different cores to each VPP instance, results can be 
> skewed due to interference at the LLC and PCIe/NIC level (this can be 
> somewhat mitigated by running on separate sockets)
>  
>Alec
>  
>  
> From: mailto:vpp-dev@lists.fd.io>> on behalf of Juraj 
> Linkeš mailto:juraj.lin...@pantheon.tech>>
> Date: Friday, July 27, 2018 at 7:25 AM
> To: "Maciek Konstantynowicz (mkonstan)"  >
> Cc: "vpp-dev@lists.fd.io "  >, csit-dev  >
> Subject: Re: [vpp-dev] Parallel test execution in VPP Test Framework
>  
> Hi Maciek and vpp-devs,
>  
> I've run into a significant problem regarding VPP assignment to cores. All 
> VPPs that are spawned are assigned to core 1. I looked at 
> https://wiki.fd.io/view/VPP/Command-line_Arguments 
>  and I guess it's because 
> that's the default behavior of VPP (dpdk coremask is not configured and  Note 
> that the "main" thread always occupies the lowest core-id specified in the 
> DPDK [process-level] coremask.").
>  
> Is my reading of the config options accurate?
>  
> Obviously, all VPP instances running on the same core goes against running 
> the tests on multiple cores. There are a couple of solutions that come to 
> mind:
> · Assign VPP instances to cores manually. With possible multiple jobs 
> running on a given host, this creates a situation where the different jobs 
> don't know cores are already occupied (and by how many VPP instances) and 
> thus introduces additional challenges to solve.
> 

Re: [vpp-dev] Regarding /var/run/.rte_config

[Dave Barach via Lists.Fd.Io]

If you want to attempt a manual cherry-pick: https://gerrit.fd.io/r/#/c/13745 - 
merged a couple of days ago - would be the right place to start.

D.

From: vpp-dev@lists.fd.io  On Behalf Of Damjan Marion via 
Lists.Fd.Io
Sent: Saturday, July 28, 2018 7:20 AM
To: Prashant Upadhyaya 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Regarding /var/run/.rte_config

Dear Prashant,

"git blame" is your friend. He can easily tell you which patch introduced that 
functionality.
And than you can try to cherry-pick it on top of 18.01

--
Damjan


On 28 Jul 2018, at 07:27, Prashant Upadhyaya 
mailto:praupadhy...@gmail.com>> wrote:

Hi again Damjan,

I am currently using VPP release 18.01 which just has the tx capture
functionality.
I see that VPP release 18.07 has introduced the rx capture functionality.

At the moment, upgrading my release to 18.01 is not an option.
Can you please advise how easy or difficult it will be to backport the
rx capture functionality and add it as a patch to 18.01.

Regards
-Prashant

On Thu, Jul 26, 2018 at 4:56 PM, Prashant Upadhyaya
mailto:praupadhy...@gmail.com>> wrote:

Thanks Damjan,

I had a temporary brain-freeze, I do see there is a max parameter as well.

Regards
-Prashant


On Thu, Jul 26, 2018 at 4:46 PM, Prashant Upadhyaya
mailto:praupadhy...@gmail.com>> wrote:

Hi Damjan,

Thanks for your CLI pointers.
It seems there is a limit of 100 packets which would work against my
requirements.
If you have any suggestions there before I look into the code to
tinker with the 100, please do let me know.

Regards
-Prashant


On Thu, Jul 26, 2018 at 4:24 PM, Damjan Marion 
mailto:dmar...@me.com>> wrote:

Dear Prashant,

Try "pcap rx trace" and "pcap tx trace" command.

https://git.fd.io/vpp/tree/src/plugins/dpdk/device/cli.c#n373

Also please note that VPP packet generator (pg) supports both pcap play and
capture...

--
Damjan

On 26 Jul 2018, at 12:42, Prashant Upadhyaya 
mailto:praupadhy...@gmail.com>> wrote:

Hi Damjan,

I was hoping to use the dpdk-pdump utility (built as part of DPDK) to
generate the pcap files for traffic passing through the various ports.
I have used that successfully with pure vanilla DPDK primary processes
(non VPP usecases). It runs as a secondary process.

Well, my requirement is to generate pcap's for ports on both tx and rx
-- if you have an alternate VPP-core solution, that would be great.

Regards
-Prashant


On Wed, Jul 25, 2018 at 11:32 PM, Damjan Marion 
mailto:dmar...@me.com>> wrote:


Dear Prashant,

We had lot of operational issues with dpdk leftover files in the past, so
we took special care to made them disappear ASAP.

Even if they are present you will not be able to use secondary process,
we simply don't support that use case. Secondary process will not be
able to access buffer memory as buffer memory is allocated by VPP and not by
DPDK.

Please note that VPP is not application built on top of DPDK, for us DPDK is
just
source of device drivers wit a bit of weight around them. Typical VPP
feature
code can work even without DPDK being present.

If you explain your use case we might be able to advise you how to approach
your problem
in a way native to VPP,  without relying on DPDK legacy features.

Regards,

--
Damjan

On 25 Jul 2018, at 13:11, Prashant Upadhyaya 
mailto:praupadhy...@gmail.com>> wrote:

Hi,

I am running VPP with DPDK plugin.
I see that when I normally run other non VPP DPDK applications, they
create a file called /var/run/.rte_config
But VPP running as a DPDK application (and calling rte_eal_init) does
not create this file.

There are consequences of the above in certain usecases where
secondary processes try to look at this file.

Can somebody advise why this file is not created when VPP is run with
DPDK plugin. Or what needs to be done so that it does get created, or
perhaps it is getting created somewhere that I am not aware of. I am
running VPP as root.

Regards
-Prashant
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#9929): https://lists.fd.io/g/vpp-dev/message/9929
Mute This Topic: https://lists.fd.io/mt/23811660/675642
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [dmar...@me.com]
-=-=-=-=-=-=-=-=-=-=-=-



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#9961): https://lists.fd.io/g/vpp-dev/message/9961
Mute This Topic: https://lists.fd.io/mt/23811660/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Manual patch verify request: gerrit 13769

[Damjan Marion via Lists.Fd.Io]

Is incremental checksum really needed here,
or we can just move to new vectorized checksum calculation (already used in 
ip-input)?

-- 
Damjan

> On 27 Jul 2018, at 22:17, Dave Barach via Lists.Fd.Io 
>  wrote:
> 
> Thanks very much... Dave
>  
> From: Tina Tsou mailto:tina.t...@arm.com>> 
> Sent: Friday, July 27, 2018 1:51 PM
> To: Dave Barach (dbarach) mailto:dbar...@cisco.com>>
> Cc: Brian Brooks mailto:brian.bro...@arm.com>>; 
> vpp-dev@lists.fd.io 
> Subject: Re: Manual patch verify request: gerrit 13769
>  
> Dear Dave, 
>  
> Looking into it...
> 
>  
> Thank you, 
> Tina
> 
> On Jul 27, 2018, at 7:23 AM, Dave Barach (dbarach)  > wrote:
> 
> Folks,
>  
> Would it be possible for someone to download and manually verify that 
> https://gerrit.fd.io/r/#/c/13769  is 
> functionally correct, and that the proposed change isn’t a performance 
> disaster on aarch64?
>  
> Thanks... Dave
>  
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#9956): https://lists.fd.io/g/vpp-dev/message/9956 
> 
> Mute This Topic: https://lists.fd.io/mt/23832194/675642 
> 
> Group Owner: vpp-dev+ow...@lists.fd.io 
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
>   [dmar...@me.com 
> ]
> -=-=-=-=-=-=-=-=-=-=-=-

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#9962): https://lists.fd.io/g/vpp-dev/message/9962
Mute This Topic: https://lists.fd.io/mt/23832194/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] L3VPN in VPP

[Gulakh]

Hi,
I have setup a *VPLS *scenario successfully and now I want to setup a *L3VPN
*scenario in VPP (L3VPN topology is in attachment).

My configuration for VPLS is some how like this link

.

As far as I searched Internet, L3VPN has a *VPN Label* that I think is
somehow like *PW Label* in VPLS with difference that *VPN Label is used to
select VRF* and *PW Label is used to select mpls tunnel *(hence bridge).

===
*Part1:*
I guess I should configure the *source PE* as follow:

 *In VPLS: mpls tunnel add l2-only via  out-labels
*
*   ip route add  via  out-labels
*


*In L3VPN: CMD1 ??? (insert in customer VRF)*
* ip route add  via  out-labels
 (insert in GLOBAL VRF)*

I don't know what command I should use for CMD1 ... This command must add
VPN-LABEL which is selected base on the customer's VRF to the packet and
then lookup the GLOBAL VRF to push the MPLS Label. just like VPLS that the
mpls tunnel first adds a PW Label and then in the destination IP
resolution, MPLS Label is added to packet.

*Question1:* Am I right about the configurations in the source PE?


*Part2:*
I guess I should configure the *target PE* as follow:

 *In VPLS: mpls local-label add eos  via l2-input-on
*

* In L3VPN: mpls local-label add eos  via
ip4-lookup-in-table   (insert in GLOBAL VRF) *

*Question2:* Am I right about the configurations in the target PE?

=
*Part3:*
In order to fill customer's VRF, I should use control plane's RouteTarget
(RT) to select the VRF ID and then use below command to fill the VRF:

  *ip route add  via   table
*

*Question3:* Am I right?

thanks in advance
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#9963): https://lists.fd.io/g/vpp-dev/message/9963
Mute This Topic: https://lists.fd.io/mt/23840657/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] target symbol

[xulang]

Hi all,
How can I reserve symbols in the target file vpp, what should I do to the 
Makefile under build-root.




Regards,
xiaoC-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#9964): https://lists.fd.io/g/vpp-dev/message/9964
Mute This Topic: https://lists.fd.io/mt/23848314/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-