Re: [vpp-dev] Problem with new c api patch commit 8f2a4ea merged on September 19

[Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)]

At the time of creating this patch, epel was part of Makefile and
python34 was installed as dependency from that repo.
(see https://gerrit.fd.io/r/#/c/6983/53/Makefile)
At later time, the epel stuff disappeared and with it also
the possibility to add python34 as a centos dependency - commit
bd8e242024fcc2daffa77bdd6e2da1296ace5c69. I remember pointing this out
in discussion with Neale, but I didn't get a chance to test whether
centos works or not before it was merged.

As for the solution, I can think of 3 options:

1.) require python3 (which has been around for some ~9 years now)
2.) disable generation of the C (and C++) API if python3 is not detected
3.) convert the script to python2.7 (which is in the opposite direction of
where we would want to go wrt python version)

Thanks,
Klement

Quoting Thomas F Herbert (2017-09-23 15:55:10)
>All:
> 
>Commit 8f2a4ea, Gerrit,  [1]https://gerrit.fd.io/r/#/c/6983/ "Add new C
>API"
> 
>introduces a dependency on Python 3 and breaks downstream builds for
>Centos.
> 
>Unfortunately, neither RHEL nor Centos currently support Python 3.
> 
>Most VPPers are probably building with EPEL repo so this problem didn't
>show up until now but actually there is no dependency on EPEL in the
>Makefile or spec file.
> 
>If anybody can suggest a solution short of pushing Python 3 into the
>downstream repos, I am open to suggestions.
> 
>--Tom
> 
>--
>Thomas F Herbert
>NFV and Fast Data Planes
>Office of Technology
>Red Hat
> 
> References
> 
>Visible links
>1. https://gerrit.fd.io/r/#/c/6983/
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Problem with new c api patch commit 8f2a4ea merged on September 19

[Marco Varlese]

Hi Klement,

>>> "Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)" 
>>>  09/25/17 9:33 AM >>>
> At the time of creating this patch, epel was part of Makefile and
> python34 was installed as dependency from that repo.
> (see https://gerrit.fd.io/r/#/c/6983/53/Makefile)
> At later time, the epel stuff disappeared and with it also
> the possibility to add python34 as a centos dependency - commit
> bd8e242024fcc2daffa77bdd6e2da1296ace5c69. I remember pointing this out
> in discussion with Neale, but I didn't get a chance to test whether
> centos works or not before it was merged.

I think it would be nice though to update other scripts too so to have one 
single python version used across the board. 
Currently, to build VPP on our distribution I need to require both python and 
python3 packages since some python scripts use one rather than the other.
Aligning python versions would make downstream consumption better I believe.
Is this something which will/could be done?

> As for the solution, I can think of 3 options:
> 
> 1.) require python3 (which has been around for some ~9 years now)
> 2.) disable generation of the C (and C++) API if python3 is not detected

I think this would be a fair compromise for distros not supporting (yet) 
python3. However, I am not sure how this would result in the VPP CI... wouldn't 
this break all tests running over those API?
> 3.) convert the script to python2.7 (which is in the opposite direction of
> where we would want to go wrt python version)
> 
> Thanks,
> Klement

Cheers,
Marco

Quoting Thomas F Herbert (2017-09-23 15:55:10)
>All:
> 
>Commit 8f2a4ea, Gerrit,  [1]https://gerrit.fd.io/r/#/c/6983/ "Add new C
>API"
> 
>introduces a dependency on Python 3 and breaks downstream builds for
>Centos.
> 
>Unfortunately, neither RHEL nor Centos currently support Python 3.
> 
>Most VPPers are probably building with EPEL repo so this problem didn't
>show up until now but actually there is no dependency on EPEL in the
>Makefile or spec file.
> 
>If anybody can suggest a solution short of pushing Python 3 into the
>downstream repos, I am open to suggestions.
> 
>--Tom
> 
>--
>Thomas F Herbert
>NFV and Fast Data Planes
>Office of Technology
>Red Hat
> 
> References
> 
>Visible links
>1. https://gerrit.fd.io/r/#/c/6983/
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev


___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Problem with new c api patch commit 8f2a4ea merged on September 19

[Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)]

Quoting Marco Varlese (2017-09-25 10:26:50)
> Hi Klement,
> 
> >>> "Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)" 
> >>>  09/25/17 9:33 AM >>>
> > At the time of creating this patch, epel was part of Makefile and
> > python34 was installed as dependency from that repo.
> > (see https://gerrit.fd.io/r/#/c/6983/53/Makefile)
> > At later time, the epel stuff disappeared and with it also
> > the possibility to add python34 as a centos dependency - commit
> > bd8e242024fcc2daffa77bdd6e2da1296ace5c69. I remember pointing this out
> > in discussion with Neale, but I didn't get a chance to test whether
> > centos works or not before it was merged.
> 
> I think it would be nice though to update other scripts too so to have one 
> single python version used across the board. 
> Currently, to build VPP on our distribution I need to require both python and 
> python3 packages since some python scripts use one rather than the other.
> Aligning python versions would make downstream consumption better I believe.
> Is this something which will/could be done?

See below.

> 
> > As for the solution, I can think of 3 options:
> > 
> > 1.) require python3 (which has been around for some ~9 years now)
> > 2.) disable generation of the C (and C++) API if python3 is not detected
> 
> I think this would be a fair compromise for distros not supporting (yet) 
> python3. However, I am not sure how this would result in the VPP CI... 
> wouldn't this break all tests running over those API?

Tests are python2.7 because scapy wasn't python3 capable when we
designed the test framework.

These are language bindings, not different API calls. Only test_vapi,
which tests that the language bindings of different types (simple
request, dump, event, etc.) work would have to be disabled.

> > 3.) convert the script to python2.7 (which is in the opposite direction of
> > where we would want to go wrt python version)
> > 
> > Thanks,
> > Klement
> 
> Cheers,
> Marco
> 
> Quoting Thomas F Herbert (2017-09-23 15:55:10)
> >All:
> > 
> >Commit 8f2a4ea, Gerrit,  [1]https://gerrit.fd.io/r/#/c/6983/ "Add new C
> >API"
> > 
> >introduces a dependency on Python 3 and breaks downstream builds for
> >Centos.
> > 
> >Unfortunately, neither RHEL nor Centos currently support Python 3.
> > 
> >Most VPPers are probably building with EPEL repo so this problem didn't
> >show up until now but actually there is no dependency on EPEL in the
> >Makefile or spec file.
> > 
> >If anybody can suggest a solution short of pushing Python 3 into the
> >downstream repos, I am open to suggestions.
> > 
> >--Tom
> > 
> >--
> >Thomas F Herbert
> >NFV and Fast Data Planes
> >Office of Technology
> >Red Hat
> > 
> > References
> > 
> >Visible links
> >1. https://gerrit.fd.io/r/#/c/6983/
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
> 
> 
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Problem with new c api patch commit 8f2a4ea merged on September 19

[Marco Varlese]

Thanks for the thorough explanation Klement!Based on that, I think (2) is still 
the better option for the current situation... 

Tom, how would that sound to you?

>>> "Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)" 
>>>  09/25/17 10:40 AM >>>
Quoting Marco Varlese (2017-09-25 10:26:50)
> Hi Klement,
> 
> >>> "Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)" 
> >>>  09/25/17 9:33 AM >>>
> > At the time of creating this patch, epel was part of Makefile and
> > python34 was installed as dependency from that repo.
> > (see https://gerrit.fd.io/r/#/c/6983/53/Makefile)
> > At later time, the epel stuff disappeared and with it also
> > the possibility to add python34 as a centos dependency - commit
> > bd8e242024fcc2daffa77bdd6e2da1296ace5c69. I remember pointing this out
> > in discussion with Neale, but I didn't get a chance to test whether
> > centos works or not before it was merged.
> 
> I think it would be nice though to update other scripts too so to have one 
> single python version used across the board. 
> Currently, to build VPP on our distribution I need to require both python and 
> python3 packages since some python scripts use one rather than the other.
> Aligning python versions would make downstream consumption better I believe.
> Is this something which will/could be done?

See below.

> 
> > As for the solution, I can think of 3 options:
> > 
> > 1.) require python3 (which has been around for some ~9 years now)
> > 2.) disable generation of the C (and C++) API if python3 is not detected
> 
> I think this would be a fair compromise for distros not supporting (yet) 
> python3. However, I am not sure how this would result in the VPP CI... 
> wouldn't this break all tests running over those API?

Tests are python2.7 because scapy wasn't python3 capable when we
designed the test framework.

These are language bindings, not different API calls. Only test_vapi,
which tests that the language bindings of different types (simple
request, dump, event, etc.) work would have to be disabled.

> > 3.) convert the script to python2.7 (which is in the opposite direction of
> > where we would want to go wrt python version)
> > 
> > Thanks,
> > Klement
> 
> Cheers,
> Marco
> 
> Quoting Thomas F Herbert (2017-09-23 15:55:10)
> >All:
> > 
> >Commit 8f2a4ea, Gerrit,  [1]https://gerrit.fd.io/r/#/c/6983/ "Add new C
> >API"
> > 
> >introduces a dependency on Python 3 and breaks downstream builds for
> >Centos.
> > 
> >Unfortunately, neither RHEL nor Centos currently support Python 3.
> > 
> >Most VPPers are probably building with EPEL repo so this problem didn't
> >show up until now but actually there is no dependency on EPEL in the
> >Makefile or spec file.
> > 
> >If anybody can suggest a solution short of pushing Python 3 into the
> >downstream repos, I am open to suggestions.
> > 
> >--Tom
> > 
> >--
> >Thomas F Herbert
> >NFV and Fast Data Planes
> >Office of Technology
> >Red Hat
> > 
> > References
> > 
> >Visible links
> >1. https://gerrit.fd.io/r/#/c/6983/
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
> 
> 

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Problem with new c api patch commit 8f2a4ea merged on September 19

[Thomas F Herbert]

On 09/25/2017 05:02 AM, Marco Varlese wrote:

Thanks for the thorough explanation Klement!Based on that, I think (2) is still 
the better option for the current situation...

Tom, how would that sound to you?


"Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)"  
09/25/17 10:40 AM >>>

Quoting Marco Varlese (2017-09-25 10:26:50)

Hi Klement,


"Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)"  
09/25/17 9:33 AM >>>

At the time of creating this patch, epel was part of Makefile and
python34 was installed as dependency from that repo.
(see https://gerrit.fd.io/r/#/c/6983/53/Makefile)
At later time, the epel stuff disappeared and with it also
the possibility to add python34 as a centos dependency - commit
bd8e242024fcc2daffa77bdd6e2da1296ace5c69. I remember pointing this out
in discussion with Neale, but I didn't get a chance to test whether
centos works or not before it was merged.
That's OK. You would have had to test with a system without EPEL Repo 
enabled to discover this problem.


I should have paid closer attention when this patch was first discussed 
in May. Please add me as a reviewer for patches that have implications 
for RPM packaging and requirements.

I think it would be nice though to update other scripts too so to have one 
single python version used across the board.
Currently, to build VPP on our distribution I need to require both python and 
python3 packages since some python scripts use one rather than the other.
Aligning python versions would make downstream consumption better I believe.
Is this something which will/could be done?

See below.


As for the solution, I can think of 3 options:

1.) require python3 (which has been around for some ~9 years now)
2.) disable generation of the C (and C++) API if python3 is not detected

I think this would be a fair compromise for distros not supporting (yet) 
python3. However, I am not sure how this would result in the VPP CI... wouldn't 
this break all tests running over those API?

Tests are python2.7 because scapy wasn't python3 capable when we
designed the test framework.

These are language bindings, not different API calls. Only test_vapi,
which tests that the language bindings of different types (simple
request, dump, event, etc.) work would have to be disabled.
I think this is a good interim work-around until the distros have 
Python3. I can submit another patch to allow this the inclusion would be 
enabled as a default but could be disabled only in downstream builds in 
RHEL and Centos 7.


When will we have tests in CSIT that use the C/C++ APIs in 17.10?

Neale, are we planning to cherry-pick this patch into 17.10?

Do we have yet tests in CSIT that use the C/C++ APIs in 17.10?





3.) convert the script to python2.7 (which is in the opposite direction of
where we would want to go wrt python version)

Thanks,
Klement

Cheers,
Marco

Quoting Thomas F Herbert (2017-09-23 15:55:10)

All:

Commit 8f2a4ea, Gerrit,  [1]https://gerrit.fd.io/r/#/c/6983/ "Add new C
API"

introduces a dependency on Python 3 and breaks downstream builds for
Centos.

Unfortunately, neither RHEL nor Centos currently support Python 3.

Most VPPers are probably building with EPEL repo so this problem didn't
show up until now but actually there is no dependency on EPEL in the
Makefile or spec file.

If anybody can suggest a solution short of pushing Python 3 into the
downstream repos, I am open to suggestions.

--Tom

--
Thomas F Herbert
NFV and Fast Data Planes
Office of Technology
Red Hat

References

Visible links
1. https://gerrit.fd.io/r/#/c/6983/

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev




--
*Thomas F Herbert*
NFV and Fast Data Planes
Office of Technology
*Red Hat*
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Problem with new c api patch commit 8f2a4ea merged on September 19

[Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)]

Quoting Thomas F Herbert (2017-09-25 13:31:55)
>On 09/25/2017 05:02 AM, Marco Varlese wrote:
> 
>  Thanks for the thorough explanation Klement!Based on that, I think (2) is 
> still the better option for the current situation...
> 
>  Tom, how would that sound to you?
> 
> 
>  "Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)" 
> [1] 09/25/17 10:40 AM >>>
> 
>  Quoting Marco Varlese (2017-09-25 10:26:50)
> 
>  Hi Klement,
> 
> 
>  "Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)" 
> [2] 09/25/17 9:33 AM >>>
> 
>  At the time of creating this patch, epel was part of Makefile and
>  python34 was installed as dependency from that repo.
>  (see [3]https://gerrit.fd.io/r/#/c/6983/53/Makefile)
>  At later time, the epel stuff disappeared and with it also
>  the possibility to add python34 as a centos dependency - commit
>  bd8e242024fcc2daffa77bdd6e2da1296ace5c69. I remember pointing this out
>  in discussion with Neale, but I didn't get a chance to test whether
>  centos works or not before it was merged.
> 
>That's OK. You would have had to test with a system without EPEL Repo
>enabled to discover this problem.
> 
>I should have paid closer attention when this patch was first discussed in
>May. Please add me as a reviewer for patches that have implications for
>RPM packaging and requirements.
> 
> 
>  I think it would be nice though to update other scripts too so to have one 
> single python version used across the board.
>  Currently, to build VPP on our distribution I need to require both python 
> and python3 packages since some python scripts use one rather than the other.
>  Aligning python versions would make downstream consumption better I believe.
>  Is this something which will/could be done?
> 
>  See below.
> 
> 
> 
>  As for the solution, I can think of 3 options:
> 
>  1.) require python3 (which has been around for some ~9 years now)
>  2.) disable generation of the C (and C++) API if python3 is not detected
> 
>  I think this would be a fair compromise for distros not supporting (yet) 
> python3. However, I am not sure how this would result in the VPP CI... 
> wouldn't this break all tests running over those API?
> 
>  Tests are python2.7 because scapy wasn't python3 capable when we
>  designed the test framework.
> 
>  These are language bindings, not different API calls. Only test_vapi,
>  which tests that the language bindings of different types (simple
>  request, dump, event, etc.) work would have to be disabled.
> 
>I think this is a good interim work-around until the distros have Python3.
>I can submit another patch to allow this the inclusion would be enabled as
>a default but could be disabled only in downstream builds in RHEL and
>Centos 7.
> 
>When will we have tests in CSIT that use the C/C++ APIs in 17.10?
> 
>Neale, are we planning to cherry-pick this patch into 17.10?
> 
>Do we have yet tests in CSIT that use the C/C++ APIs in 17.10?

Let me rephrase my words to clarify possible confusion which I see. New
C/C++ API bindings are just a way of calling old VPP APIs in a more
user-friendly way. They still call e.g. sw_interface_dump - there is no
change to APIs themselves.

So it's important to distinguish between API (e.g. sw_interface_dump)
and API binding (which is a language-specific way of constructing
sw_interface_dump message and sending it over shared memory to VPP).

I don't know about CSIT, but "make test" tests use python API bindings,
which internally uses old C API bindings (vapiclient). Unless we want
to remove old C API, there is little motivation to rework python API
binding as it contains more or less the same logic as the new C/C++ API
bindings.

There is one test though which doesn't - test_vapi.py, which builds its
own test client binary for both new C and new C++ API to make sure that
it builds, links and executes as intended. It doesn't call python API
bindings at all, it only sets up the infra for running a test and then
spawns a binary, which does the actual testing (vs running native python
code as is the case for most of the other tests).

Now to answer your questions:

1.) there is no CSIT test which uses new C/C++ API
2.) there is only one "make test" test which uses new C/C++ API
(test_vapi), which is part of this change.

To disable this partially on centos, we need to exclude

a.) vpp-api/vapi/Makefile.am (don't build)
b.) test/ext/Makefile (don't build)
c.) test/test_vapi.py (don't run) - we can add code to skip this easily
if we can detect centos e.g. via some kind of environment variable from
within python..

> 
> 
> 
>  3.) convert the script to python2.7 (which is in the opposite direction of
>  where we would want to go wrt python version)
> 
>  Thanks,
>  Klement
> 
>  Cheers,
>  Marco
> 
>  Quoting Thomas F Herbert (2017-09-23 15:55:10)
> 
> All:
> 
> Commit 8f2a4ea, Gerrit,  [1][4]https://gerrit.fd.io/r/#/c/6983/ "Add new C
> API"
> 
> introduces a depend

Re: [vpp-dev] ipv6 lookup rate

[Pragash Vijayaragavan]

Any inputs on this is appreciated

Thanks,

Pragash Vijayaragavan
Grad Student at Rochester Institute of Technology
email : pxv3...@rit.edu
ph : 585 764 4662


On Thu, Sep 21, 2017 at 4:50 PM, Pragash Vijayaragavan 
wrote:

> Hi Guys,
>
> We are working on ipv6 lookup rate in VPP.
>
> We are sending traffic from TRex and receiving on the same machine, with
> VPP as the SUT.
>
> The problem is that lookup rate of ip6 is very low, we are only getting a
> lookup rate of 200 Kpps, there are lot of drops. (ip4 has a rate of 5 Mpps).
>
> Is there any special configuration / requirement for doing the ip6 lookup
> in the VPP faster. We tried increasing the heapsize, using multiple cores..
>
> Our topology :
>
>--- | TRex  port 1 |  | VPP
> port 1 |
>|   port 2 | | VPP
> port 2 |
>
> Note : we have default routes in VPP, (so that there are no drops).
>
> Thanks,
>
> Pragash Vijayaragavan
> Grad Student at Rochester Institute of Technology
> email : pxv3...@rit.edu
> ph : 585 764 4662 <(585)%20764-4662>
>
>
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Problem with new c api patch commit 8f2a4ea merged on September 19

[Thomas Herbert]

Posted from iPhone. Forgive top posting, and terse writing style..

--Thomas F Herbert
SDN Group
Office of Technology
Red Hat


> On Sep 25, 2017, at 1:03 PM, Klement Sekera -X (ksekera - PANTHEON 
> TECHNOLOGIES at Cisco)  wrote:
> 
> Quoting Thomas F Herbert (2017-09-25 13:31:55)
>>   On 09/25/2017 05:02 AM, Marco Varlese wrote:
>> 
>> Thanks for the thorough explanation Klement!Based on that, I think (2) is 
>> still the better option for the current situation...
>> 
>> Tom, how would that sound to you?
>> 
>> 
>> "Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)" 
>> [1] 09/25/17 10:40 AM >>>
>> 
>> Quoting Marco Varlese (2017-09-25 10:26:50)
>> 
>> Hi Klement,
>> 
>> 
>> "Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)" 
>> [2] 09/25/17 9:33 AM >>>
>> 
>> At the time of creating this patch, epel was part of Makefile and
>> python34 was installed as dependency from that repo.
>> (see [3]https://gerrit.fd.io/r/#/c/6983/53/Makefile)
>> At later time, the epel stuff disappeared and with it also
>> the possibility to add python34 as a centos dependency - commit
>> bd8e242024fcc2daffa77bdd6e2da1296ace5c69. I remember pointing this out
>> in discussion with Neale, but I didn't get a chance to test whether
>> centos works or not before it was merged.
>> 
>>   That's OK. You would have had to test with a system without EPEL Repo
>>   enabled to discover this problem.
>> 
>>   I should have paid closer attention when this patch was first discussed in
>>   May. Please add me as a reviewer for patches that have implications for
>>   RPM packaging and requirements.
>> 
>> 
>> I think it would be nice though to update other scripts too so to have one 
>> single python version used across the board.
>> Currently, to build VPP on our distribution I need to require both python 
>> and python3 packages since some python scripts use one rather than the other.
>> Aligning python versions would make downstream consumption better I believe.
>> Is this something which will/could be done?
>> 
>> See below.
>> 
>> 
>> 
>> As for the solution, I can think of 3 options:
>> 
>> 1.) require python3 (which has been around for some ~9 years now)
>> 2.) disable generation of the C (and C++) API if python3 is not detected
>> 
>> I think this would be a fair compromise for distros not supporting (yet) 
>> python3. However, I am not sure how this would result in the VPP CI... 
>> wouldn't this break all tests running over those API?
>> 
>> Tests are python2.7 because scapy wasn't python3 capable when we
>> designed the test framework.
>> 
>> These are language bindings, not different API calls. Only test_vapi,
>> which tests that the language bindings of different types (simple
>> request, dump, event, etc.) work would have to be disabled.
>> 
>>   I think this is a good interim work-around until the distros have Python3.
>>   I can submit another patch to allow this the inclusion would be enabled as
>>   a default but could be disabled only in downstream builds in RHEL and
>>   Centos 7.
>> 
>>   When will we have tests in CSIT that use the C/C++ APIs in 17.10?
>> 
>>   Neale, are we planning to cherry-pick this patch into 17.10?
>> 
>>   Do we have yet tests in CSIT that use the C/C++ APIs in 17.10?
> 
> Let me rephrase my words to clarify possible confusion which I see. New
> C/C++ API bindings are just a way of calling old VPP APIs in a more
> user-friendly way. They still call e.g. sw_interface_dump - there is no
> change to APIs themselves.
> 
> So it's important to distinguish between API (e.g. sw_interface_dump)
> and API binding (which is a language-specific way of constructing
> sw_interface_dump message and sending it over shared memory to VPP).
> 
> I don't know about CSIT, but "make test" tests use python API bindings,
> which internally uses old C API bindings (vapiclient). Unless we want
> to remove old C API, there is little motivation to rework python API
> binding as it contains more or less the same logic as the new C/C++ API
> bindings.
> 
> There is one test though which doesn't - test_vapi.py, which builds its
> own test client binary for both new C and new C++ API to make sure that
> it builds, links and executes as intended. It doesn't call python API
> bindings at all, it only sets up the infra for running a test and then
> spawns a binary, which does the actual testing (vs running native python
> code as is the case for most of the other tests).
> 
> Now to answer your questions:
> 
> 1.) there is no CSIT test which uses new C/C++ API
> 2.) there is only one "make test" test which uses new C/C++ API
> (test_vapi), which is part of this change.
> 
> To disable this partially on centos, we need to exclude
> 
> a.) vpp-api/vapi/Makefile.am (don't build)
> b.) test/ext/Makefile (don't build)
> c.) test/test_vapi.py (don't run) - we can add code to skip this easily
> if we can detect centos e.g. via some kind of environment variable from
> within python..
OK, I volunteer to work on a disa

[vpp-dev] Poor L3/L4 Performance

[Alessio Silvestro]

Dear all,

I am performing some experiments on VPP in order to get some performance
metrics for specific applications.

I am working on vpp v17.04.2-2.

In order to have a baseline of my system, I run L2 XConnect (XC) as in [
https://perso.telecom-paristech.fr/~drossi/paper/vpp-bench-techrep.pdf].

In this case, I can achieve, similarly to the paper, ~13Mpps -- which
somehow confirm that the
current setup is correct.

I implemented 2 further experiments:

*1) L3-Xconnect *

I implemented a new node that listens for traffic with specific ether_type
with the following api:

ethernet_register_input_type(vm, ETHERNET_TYPE_X, my_node.index)

Once the traffic is received, the node sends the traffic directly to
l2_output without any further processing.

The achieved packet rate is less than 5 Mpps.

*2) L4-Xconnect*

I implemented another node that listens for UDP traffic on  a specific port
with the following api:


udp_register_dst_port (vm, UDP_DST_PORT_vxlan, vxlan_input_node.index, 1 /*
is_ip4 */);

Once the traffic is received, the node sends the traffic directly to
l2_output without any further processing.

The achieved packet rate is less than 4 Mpps.


The testbed is composed of 2 servers. The first server is running VPP
whereas the second server runs the traffic generator (packetgen). The
servers are equipped with Intel NICs capable of dual-port 10 Gbps
full-duplex link. Generated packets have the size of 64kb.

VPP is configured to run with one main thread and one worker thread.
Therefore, the previous values are meant for a single CPU-core.

In my opinion those values are a bit too low compared to other
state-of-the-art approaches.

Do you have any idea on why this is happening and, if this is my fault, how
I can fix it.

Thanks,
Alessio
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Problem with new c api patch commit 8f2a4ea merged on September 19

[Burt Silverman]

I thought of a solution, but it a purely technological one that ignores any
business relationship details, as they are above my pay grade: if VPP were
part of the EPEL distribution rather than directly part of RHEL/CentOS,
then there would be no problems!

Burt

On Mon, Sep 25, 2017 at 7:31 AM, Thomas F Herbert 
wrote:

>
>
> On 09/25/2017 05:02 AM, Marco Varlese wrote:
>
> Thanks for the thorough explanation Klement!Based on that, I think (2) is 
> still the better option for the current situation...
>
> Tom, how would that sound to you?
>
>
> "Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)" 
>   09/25/17 10:40 AM >>>
>
> Quoting Marco Varlese (2017-09-25 10:26:50)
>
> Hi Klement,
>
>
> "Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)" 
>   09/25/17 9:33 AM >>>
>
> At the time of creating this patch, epel was part of Makefile and
> python34 was installed as dependency from that repo.
> (see https://gerrit.fd.io/r/#/c/6983/53/Makefile)
> At later time, the epel stuff disappeared and with it also
> the possibility to add python34 as a centos dependency - commit
> bd8e242024fcc2daffa77bdd6e2da1296ace5c69. I remember pointing this out
> in discussion with Neale, but I didn't get a chance to test whether
> centos works or not before it was merged.
>
> That's OK. You would have had to test with a system without EPEL Repo
> enabled to discover this problem.
>
> I should have paid closer attention when this patch was first discussed in
> May. Please add me as a reviewer for patches that have implications for RPM
> packaging and requirements.
>
> I think it would be nice though to update other scripts too so to have one 
> single python version used across the board.
> Currently, to build VPP on our distribution I need to require both python and 
> python3 packages since some python scripts use one rather than the other.
> Aligning python versions would make downstream consumption better I believe.
> Is this something which will/could be done?
>
> See below.
>
>
> As for the solution, I can think of 3 options:
>
> 1.) require python3 (which has been around for some ~9 years now)
> 2.) disable generation of the C (and C++) API if python3 is not detected
>
> I think this would be a fair compromise for distros not supporting (yet) 
> python3. However, I am not sure how this would result in the VPP CI... 
> wouldn't this break all tests running over those API?
>
> Tests are python2.7 because scapy wasn't python3 capable when we
> designed the test framework.
>
> These are language bindings, not different API calls. Only test_vapi,
> which tests that the language bindings of different types (simple
> request, dump, event, etc.) work would have to be disabled.
>
> I think this is a good interim work-around until the distros have Python3.
> I can submit another patch to allow this the inclusion would be enabled as
> a default but could be disabled only in downstream builds in RHEL and
> Centos 7.
>
> When will we have tests in CSIT that use the C/C++ APIs in 17.10?
>
> Neale, are we planning to cherry-pick this patch into 17.10?
>
> Do we have yet tests in CSIT that use the C/C++ APIs in 17.10?
>
>
>
>  3.) convert the script to python2.7 (which is in the opposite direction of
> where we would want to go wrt python version)
>
> Thanks,
> Klement
>
> Cheers,
> Marco
>
> Quoting Thomas F Herbert (2017-09-23 15:55:10)
>
>All:
>
>Commit 8f2a4ea, Gerrit,  [1]https://gerrit.fd.io/r/#/c/6983/ "Add new C
>API"
>
>introduces a dependency on Python 3 and breaks downstream builds for
>Centos.
>
>Unfortunately, neither RHEL nor Centos currently support Python 3.
>
>Most VPPers are probably building with EPEL repo so this problem didn't
>show up until now but actually there is no dependency on EPEL in the
>Makefile or spec file.
>
>If anybody can suggest a solution short of pushing Python 3 into the
>downstream repos, I am open to suggestions.
>
>--Tom
>
>--
>Thomas F Herbert
>NFV and Fast Data Planes
>Office of Technology
>Red Hat
>
> References
>
>Visible links
>1. https://gerrit.fd.io/r/#/c/6983/
>
> ___
> vpp-dev mailing 
> listvpp-...@lists.fd.iohttps://lists.fd.io/mailman/listinfo/vpp-dev
>
>
> --
> *Thomas F Herbert*
> NFV and Fast Data Planes
> Office of Technology
> *Red Hat*
>
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
>
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] [FD.io Helpdesk #45750] Spurious patch verification failure (gerrit 8400)

[Vanessa Valderrama via RT]

Switching to the new flavors appears to have resolved this issue.

Thank you,
Vanessa

On Wed Sep 13 15:09:49 2017, valderrv wrote:
> We do see intermittent slow response times from Nexus.  We are
> investigating the cause.
> 
> On Wed Sep 13 09:56:20 2017, dbarach wrote:
> > See gerrit https://gerrit.fd.io/r/#/c/8400,
> > https://jenkins.fd.io/job/vpp-verify-master-centos7/7070/console
> >
> >
> > 12:29:12 make[1]: Leaving directory `/w/workspace/vpp-verify-master-
> > centos7/test'
> > 12:29:12 [vpp-verify-master-centos7] $ /bin/bash
> > /tmp/hudson3100921859131279854.sh
> > 12:29:12 Loaded plugins: fastestmirror, langpacks
> > 12:29:12 Repodata is over 2 weeks old. Install yum-cron? Or run: yum
> > makecache fast
> > 12:29:17 Determining fastest mirrors
> > 12:29:18  * base: centos.mirror.ca.planethoster.net
> > 12:29:18  * epel: ftp.cse.buffalo.edu
> > 12:29:18  * extras: centos.mirror.iweb.ca
> > 12:29:18  * updates: centos.mirror.netelligent.ca
> > 12:29:21 Package redhat-lsb-4.1-27.el7.centos.1.x86_64 already
> > installed and latest version
> > 12:29:21 Nothing to do
> > 12:29:21 DISTRIB_ID: CentOS
> > 12:29:21 DISTRIB_RELEASE: 7.3.1611
> > 12:29:21 DISTRIB_CODENAME: Core
> > 12:29:21 DISTRIB_DESCRIPTION: "CentOS Linux release 7.3.1611 (Core) "
> > 12:29:21 INSTALLING VPP-DPKG-DEV from apt/yum repo
> > 12:29:21 REPO_URL:
> > https://nexus.fd.io/content/repositories/fd.io.master.centos7
> > 12:29:21 Loaded plugins: fastestmirror, langpacks
> > 12:29:52
> > https://nexus.fd.io/content/repositories/fd.io.master.centos7/repodata/repomd.xml:
> > [Errno 12] Timeout on
> > https://nexus.fd.io/content/repositories/fd.io.master.centos7/repodata/repomd.xml:
> > (28, 'Operation too slow. Less than 1000 bytes/sec transferred the
> > last 30 seconds')
> > 12:29:52 Trying other mirror.
> > 12:30:22
> > https://nexus.fd.io/content/repositories/fd.io.master.centos7/repodata/repomd.xml:
> > [Errno 12] Timeout on
> > https://nexus.fd.io/content/repositories/fd.io.master.centos7/repodata/repomd.xml:
> > (28, 'Operation too slow. Less than 1000 bytes/sec transferred the
> > last 30 seconds')
> > 12:30:22 Trying other mirror.
> > 12:30:52
> > https://nexus.fd.io/content/repositories/fd.io.master.centos7/repodata/repomd.xml:
> > [Errno 12] Timeout on
> > https://nexus.fd.io/content/repositories/fd.io.master.centos7/repodata/repomd.xml:
> > (28, 'Operation too slow. Less than 1000 bytes/sec transferred the
> > last 30 seconds')
> > 12:30:52 Trying other mirror.
> > 12:31:22
> > https://nexus.fd.io/content/repositories/fd.io.master.centos7/repodata/repomd.xml:
> > [Errno 12] Timeout on
> > https://nexus.fd.io/content/repositories/fd.io.master.centos7/repodata/repomd.xml:
> > (28, 'Operation too slow. Less than 1000 bytes/sec transferred the
> > last 30 seconds')
> > 12:31:22 Trying other mirror.
> > 12:31:52
> > https://nexus.fd.io/content/repositories/fd.io.master.centos7/repodata/repomd.xml:
> > [Errno 12] Timeout on
> > https://nexus.fd.io/content/repositories/fd.io.master.centos7/repodata/repomd.xml:
> > (28, 'Operation too slow. Less than 1000 bytes/sec transferred the
> > last 30 seconds')
> > 12:31:52 Trying other mirror.
> > 12:32:22
> > https://nexus.fd.io/content/repositories/fd.io.master.centos7/repodata/repomd.xml:
> > [Errno 12] Timeout on
> > https://nexus.fd.io/content/repositories/fd.io.master.centos7/repodata/repomd.xml:
> > (28, 'Operation too slow. Less than 1000 bytes/sec transferred the
> > last 30 seconds')
> > 12:32:22 Trying other mirror.
> > 12:32:52
> > https://nexus.fd.io/content/repositories/fd.io.master.centos7/repodata/repomd.xml:
> > [Errno 12] Timeout on
> > https://nexus.fd.io/content/repositories/fd.io.master.centos7/repodata/repomd.xml:
> > (28, 'Operation too slow. Less than 1000 bytes/sec transferred the
> > last 30 seconds')
> > 12:32:52 Trying other mirror.
> > 12:33:22
> > https://nexus.fd.io/content/repositories/fd.io.master.centos7/repodata/repomd.xml:
> > [Errno 12] Timeout on
> > https://nexus.fd.io/content/repositories/fd.io.master.centos7/repodata/repomd.xml:
> > (28, 'Operation too slow. Less than 1000 bytes/sec transferred the
> > last 30 seconds')
> > 12:33:22 Trying other mirror.
> > 12:33:52
> > https://nexus.fd.io/content/repositories/fd.io.master.centos7/repodata/repomd.xml:
> > [Errno 12] Timeout on
> > https://nexus.fd.io/content/repositories/fd.io.master.centos7/repodata/repomd.xml:
> > (28, 'Operation too slow. Less than 1000 bytes/sec transferred the
> > last 30 seconds')
> > 12:33:52 Trying other mirror.
> > 12:34:22
> > https://nexus.fd.io/content/repositories/fd.io.master.centos7/repodata/repomd.xml:
> > [Errno 12] Timeout on
> > https://nexus.fd.io/content/repositories/fd.io.master.centos7/repodata/repomd.xml:
> > (28, 'Operation too slow. Less than 1000 bytes/sec transferred the
> > last 30 seconds')
> > 12:34:22 Trying other mirror.
> > 12:34:22
> > 12:34:22
> > 12:34:22  One of the configured repositories failed (fd.io master
> > branch latest merge),
> > 12

[vpp-dev] [FD.io Helpdesk #45822] Jenkins ubuntu 1604 failures

[Vanessa Valderrama via RT]

VPP jobs are building on 8c/32gb instances.  This appears to have resolved 
build timeout issues and decreased build times. Please let me know if you 
experience any other issues.

Thank you,
Vanessa

On Fri Sep 15 11:36:43 2017, valderrv wrote:
> VPP Jenkins minions have been switched to 4 core / 16GB instances.
> I'll
> be monitoring builds throughout the day.  Please contact me via IRC
> fdio-infra (valderrv) if you experience any issues.
> 
> Thank you,
> Vanessa
> 
> On 09/14/2017 05:59 PM, Vanessa Valderrama wrote:
> >
> > Florin,
> >
> > It doesn't appear the  failures are related to the new instances.  We
> > will be switching to a new performance (4c/8GB) instance when it's
> > available. I've submitted a request to the vendor and will follow up
> > tomorrow morning.  Adding the additional CPU resources may
> > improve/resolve the failure in build 7108.  Please let me know if
> > there are additional failures you are concerned about that I haven't
> > addressed.  Also please feel free to ping me via IRC fdio-infra
> > (valderrv) if you'd like to work together to debug these issues
> > quickly.
> >
> > *https://jenkins.fd.io/view/vpp/job/vpp-verify-master-
> > ubuntu1604/7108/console
> > 17:34:21* ACL IPv4 routed -> bridged, L2 ACL
> > permit+reflect17:44:47,177 Timeout while waiting for child test
> > runner
> > process (last test running was `MACIP 2 ACLs each with 100+ entries'
> > in `/tmp/vpp-unittest-TestMACIP-py7viS')!
> >
> > *
> > *This failure is not a timeout and appears to be related to code*
> >
> > https://jenkins.fd.io/view/vpp/job/vpp-verify-master-
> > ubuntu1604/7109/console*
> >
> > *16:48:11* * Test framework PEP8 compliance check FAILED
> > *16:48:11*
> > ***
> > *16:48:11* Makefile:172: recipe for target 'checkstyle' failed
> > *16:48:11* make[1]: *** [checkstyle]
> > Error 1 *16:48:11* make[1]: Leaving directory
> > '/w/workspace/vpp-verify-master-ubuntu1604/test' *16:48:11*
> > Makefile:376: recipe for target 'test-checkstyle' failed *16:48:11*
> > make: *** [test-checkstyle] Error 2 *16:48:11* Build step
> > 'Execute shell' marked build as failure
> >
> >
> > The cause of these two failures appear to be related to package(s)
> > not
> > installing?
> >*
> > https://jenkins.fd.io/view/vpp/job/vpp-verify-master-
> > ubuntu1604/7111/console
> >
> > https://jenkins.fd.io/view/vpp/job/vpp-verify-master-
> > ubuntu1604/7112/console
> > **19:05:38* cc1: all warnings being treated as errors
> > *19:05:38* Makefile:6164: recipe for target 'vppinfra/linux/mem.lo'
> > failed *19:05:38* make[3]: *** [vppinfra/linux/mem.lo] Error 1
> >*19:05:38* make[3]: *** Waiting for unfinished jobs *
> > 19:05:40* make[3]: Leaving directory
> > '/w/workspace/vpp-verify-master-ubuntu1604/build-root/build-vpp-
> > native/vpp'*19:05:40*
> > Makefile:698: recipe for target 'vpp-build' failed *19:05:40*
> > make[2]:
> > *** [vpp-build] Error 2 *19:05:40* make[2]:
> > Leaving directory
> > '/w/workspace/vpp-verify-master-ubuntu1604/build-root' *19:05:40*
> > Makefile:934: recipe for target 'install-packages' failed *19:05:40*
> > make[1]: *** [install-packages] Error 1 *19:05:40* make[1]: Leaving
> > directory '/w/workspace
> > /vpp-verify-master-ubuntu1604/build-root' *19:05:40* Makefile:487:
> > recipe for target 'verify' failed *19:05:40* make: *** [verify] Error
> > 2 *19:05:40* Build step 'Execute shell' marked build as failure
> >
> > Thank you,
> > Vanessa
> >
> > On 09/14/2017 02:27 PM, Florin Coras wrote:
> >> Hi Vanessa,
> >>
> >> We’re seeing lots of vpp-verify-master-ubuntu1604 failures that seem
> >> to be timeouts related. Could they be related to the recent switch
> >> to the new instances?
> >>
> >> Thanks,
> >> Florin
> >>
> >




___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Poor L3/L4 Performance

[Damjan Marion (damarion)]

Dear Alessio,

It is hard to guess where is the problem out of your description,
but I would not be surprised that your implementation of those graph nodes is 
not properly performance tuned.
One missing prefetch can hurt performance really badly.

If you are able to share your code I can take a quick look...

Thanks,

Damjan


On 25 Sep 2017, at 07:12, Alessio Silvestro 
mailto:ale.silver...@gmail.com>> wrote:

Dear all,

I am performing some experiments on VPP in order to get some performance 
metrics for specific applications.

I am working on vpp v17.04.2-2.

In order to have a baseline of my system, I run L2 XConnect (XC) as in 
[https://perso.telecom-paristech.fr/~drossi/paper/vpp-bench-techrep.pdf].

In this case, I can achieve, similarly to the paper, ~13Mpps -- which somehow 
confirm that the
current setup is correct.

I implemented 2 further experiments:

1) L3-Xconnect

I implemented a new node that listens for traffic with specific ether_type with 
the following api:

ethernet_register_input_type(vm, ETHERNET_TYPE_X, my_node.index)

Once the traffic is received, the node sends the traffic directly to l2_output 
without any further processing.

The achieved packet rate is less than 5 Mpps.

2) L4-Xconnect

I implemented another node that listens for UDP traffic on  a specific port 
with the following api:


udp_register_dst_port (vm, UDP_DST_PORT_vxlan, vxlan_input_node.index, 1 /* 
is_ip4 */);

Once the traffic is received, the node sends the traffic directly to l2_output 
without any further processing.

The achieved packet rate is less than 4 Mpps.


The testbed is composed of 2 servers. The first server is running VPP whereas 
the second server runs the traffic generator (packetgen). The servers are 
equipped with Intel NICs capable of dual-port 10 Gbps full-duplex link. 
Generated packets have the size of 64kb.

VPP is configured to run with one main thread and one worker thread. Therefore, 
the previous values are meant for a single CPU-core.

In my opinion those values are a bit too low compared to other state-of-the-art 
approaches.

Do you have any idea on why this is happening and, if this is my fault, how I 
can fix it.

Thanks,
Alessio

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Problem in ARP reply

[Neale Ranns (nranns)]

Hi Andrew,

Can you describe your use case/requirements in more detail please. Addresses on 
the subnet the ARP request arrives on, the ARP proxy range configured and a 
packet trace indicating what you consider to be incorrect behaviour.

Thanks,
neale

From:  on behalf of Andrew Taylor 

Date: Sunday, 24 September 2017 at 00:13
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] Problem in ARP reply

Hi,

In following code in /vnet/ethernet/arp.c

1058 if (!(FIB_ENTRY_FLAG_CONNECTED & dst_flags))
1059 {
1060   error0 = ETHERNET_ARP_ERROR_l3_dst_address_not_local;
1061   goto drop1;
1062 }

I think the flag should be FIB_ENTRY_FLAG_LOCAL. is it correct?

Because when I set ARP proxy, the reply is sent with local address!


Best Regards
Andrew Taylor




___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Problem with new c api patch commit 8f2a4ea merged on September 19

[Ole Troan]

> I don't know about CSIT, but "make test" tests use python API bindings,
> which internally uses old C API bindings (vapiclient). Unless we want
> to remove old C API, there is little motivation to rework python API
> binding as it contains more or less the same logic as the new C/C++ API
> bindings.

To avoid any misunderstanding. The python binding constructs the binary 
messages itself, but yes, it uses a C api to read and write from the shared 
memory queues.

Best regards,
Ole



signature.asc
Description: Message signed with OpenPGP
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Static Route Data API Data Structures

[Neale Ranns (nranns)]

Hi Jon,

Some answers inline.

Thanks,
neale

-Original Message-
From: Jon Loeliger 
Date: Thursday, 21 September 2017 at 16:42
To: "Neale Ranns (nranns)" 
Cc: vpp-dev 
Subject: Re: [vpp-dev] Static Route Data API Data Structures

On Tue, Aug 29, 2017 at 9:37 AM, Neale Ranns (nranns)  
wrote:
>
> Hi Jon,
>
> The new API does not function correctly in master at this time. If you 
want to ride on the bleeding edge with the new API, the code I intend to commit 
is (complete AFAICT) here:
>   https://gerrit.fd.io/r/#/c/7819/
>
> it’s not committed yet because I need to do an n-step dance with CSIT 
changes to make the verify jobs pass. This will take a few weeks (because 
vacations).
>
> Regards,
> neale


Hi Neale,

Hope your vacation went well!

Glad to see you are back at The Salt Mines, though!  Any chance for
a brief update on the progress of this whole Route Table re-work effort?

It’s committed and ready to go. 
I’m still working through some updates to CSIT to behave w.r.t. adding tables 
first before adding routes or binding interfaces. After that I will add the 
checks in VPP to enforce it.


Specifically, I have code poised to use the "add_del_table" API call, and
I *think* that I can do that now.  But can I remove the soon-to-be-obsolete
create_table_if_needed flag yet?

You can remove that flag. I mistakenly left the flag in the API, but it has no 
effect in VPP. Too late to remove it now we are in the API Freeze, I’ll do it 
in the next iteration.

Also, I read a comment about the need to ensure that an interface does
not have addresses on it when the IF is bound to a route table.  I get
the "why" behind that, but I'd like a small clarification:  Is that per-AF?
Or is that "across the board"?

Per-AF. One could bind an interface to a new IPv4 tale whilst it had IPv6 
address.

The reason I ask is the potentially somewhat disconnected special case
API call intf_add_del_address which contains a flag "del_all".  And it
does as advertised -- it removes all IPv4 and IPv6 addresses in one shot.

But if the route table addition is per-AF, it might make sense to have
the two calls coordinated a bit better.  That is:

- Modify intf_add_del_address to del_all per AF, or all AFs
- Modify intf_sw_interface_set_table to accept and bind one or both AFs

It is all in an effort to avoid repeatedly removing and re-adding the
addresses that might be present in either or both AFs on an interface.

See where I am headed there?  Am I way off base?

I agree that is inconsistent. I would propose the del_all case becomes AF 
specific. But I would also suggest this in an API change, albeit semantic not 
syntactic, and so we should wait for the next release.

Regards,
neale

Thanks,
jdl


___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Poor L3/L4 Performance

[Dave Barach (dbarach)]

As discussed off-list: please stick to best-practice coding patterns. 
Single-packet frames simply cannot perform, etc.

Thanks… Dave

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Alessio Silvestro
Sent: Monday, September 25, 2017 10:13 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Poor L3/L4 Performance

Dear all,

I am performing some experiments on VPP in order to get some performance 
metrics for specific applications.

I am working on vpp v17.04.2-2.

In order to have a baseline of my system, I run L2 XConnect (XC) as in 
[https://perso.telecom-paristech.fr/~drossi/paper/vpp-bench-techrep.pdf].

In this case, I can achieve, similarly to the paper, ~13Mpps -- which somehow 
confirm that the
current setup is correct.

I implemented 2 further experiments:

1) L3-Xconnect

I implemented a new node that listens for traffic with specific ether_type with 
the following api:

ethernet_register_input_type(vm, ETHERNET_TYPE_X, my_node.index)

Once the traffic is received, the node sends the traffic directly to l2_output 
without any further processing.

The achieved packet rate is less than 5 Mpps.

2) L4-Xconnect

I implemented another node that listens for UDP traffic on  a specific port 
with the following api:


udp_register_dst_port (vm, UDP_DST_PORT_vxlan, vxlan_input_node.index, 1 /* 
is_ip4 */);

Once the traffic is received, the node sends the traffic directly to l2_output 
without any further processing.

The achieved packet rate is less than 4 Mpps.


The testbed is composed of 2 servers. The first server is running VPP whereas 
the second server runs the traffic generator (packetgen). The servers are 
equipped with Intel NICs capable of dual-port 10 Gbps full-duplex link. 
Generated packets have the size of 64kb.

VPP is configured to run with one main thread and one worker thread. Therefore, 
the previous values are meant for a single CPU-core.

In my opinion those values are a bit too low compared to other state-of-the-art 
approaches.

Do you have any idea on why this is happening and, if this is my fault, how I 
can fix it.

Thanks,
Alessio

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Trunk ports with VPP

[Prabhjot Singh Sethi]

Hi,
    i am trying to achieve trunck ports with VPP using following
documentation
https://wiki.fd.io/view/VPP/Interconnecting_vRouters_with_VPP#Create_TRUNK_ports
only difference is that i am trying this with host interfaces
connected to netns instance.

However packet egressing on this trunk port remains untagged
irrespective of which sub-interface it came from.

i am i missing something over here ?

Regards,
Prabhjot

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Trunk ports with VPP

[John Lo (loj)]

The access port config from the example doc is aa follows:
create vhost socket /tmp/sock2.sock server
set interface state VirtualEthernet0/0/2 up
set interface l2 bridge VirtualEthernet0/0/2 200
set interface l2 tag-rewrite VirtualEthernet0/0/2 push dot1q 200

Note the tag-rewrite config on access port to push the VLAN tag on the packet. 
Did you do this on the access ports?

Regards,
John

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Prabhjot Singh Sethi
Sent: Monday, September 25, 2017 2:11 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Trunk ports with VPP

Hi,
i am trying to achieve trunck ports with VPP using following documentation
https://wiki.fd.io/view/VPP/Interconnecting_vRouters_with_VPP#Create_TRUNK_ports
only difference is that i am trying this with host interfaces connected to 
netns instance.

However packet egressing on this trunk port remains untagged irrespective of 
which sub-interface it came from.

i am i missing something over here ?

Regards,
Prabhjot
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev