date:20170911

Re: [vpp-dev] VPP contribute

2017-09-11 Thread Shachar Beiser

Hi Dave,

   Is there a simple solution to the “hooks/commit-msg” I have ?
 -Shachar Beiser.

[shacharbe@pegasus08 vpp]$ git review
Using global/system git-review config files (/etc/git-review/git-review.conf) 
is deprecated
/usr/lib/python2.7/site-packages/urllib3/connectionpool.py:858: 
InsecureRequestWarning: Unverified HTTPS request is being made. Adding 
certificate verification is strongly advised. See: 
https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
  InsecureRequestWarning)
Problems encountered installing commit-msg hook
The following command failed with exit code 104
"GET https://shacha...@gerrit.fd.io/tools/hooks/commit-msg;
---



Error 404 


HTTP ERROR: 404
Problem accessing /tools/hooks/commit-msg. Reason:
Not Found
Powered by Jetty://



From: Dave Barach (dbarach) [mailto:dbar...@cisco.com]
Sent: Monday, September 11, 2017 2:57 PM
To: Shachar Beiser ; vpp-dev@lists.fd.io
Cc: Damjan Marion (damarion) 
Subject: RE: VPP contribute

That’s right, no need to send patches to a mailing list. In fact, please don’t 
send patches to this list. ()...

Thanks… Dave

From: vpp-dev-boun...@lists.fd.io 
[mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Shachar Beiser
Sent: Monday, September 11, 2017 7:48 AM
To: vpp-dev@lists.fd.io
Cc: Damjan Marion (damarion) >
Subject: [vpp-dev] VPP contribute

Hi ,

   I contribute to the VPP for the first time.
   I am following the instructions in your web-site : 
https://wiki.fd.io/view/VPP/Pulling,_Building,_Running,_Hacking_and_Pushing_VPP_Code#Setting_up_Gerrit
   Is that it ? don’t I need to send my patches to the mailing-list ?

   -Shachar Beiser.

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

Re: [vpp-dev] Icmp support in Stateful ACL

2017-09-11 Thread Andrew Yourtchenko

Thanks for the contribution!

Yep, I posted some comments.

In short: I think it needs some more work.

One additional comment that I forgot to mention in the review: I would really 
love to see unittests...

--a

> On 11 Sep 2017, at 17:53, Ed Warnicke  wrote:
> 
> Andrew,
>  Could you have a look?
> 
> Ed
> 
>> On Mon, Sep 11, 2017 at 2:37 AM, chore  wrote:
>> Dear Team
>> 
>> I had a commit in acl plugin to support Icmp proto in Stateful ACL. please 
>> kindly review the changes. 
>> 
>> Best Regards,
>> Chore
>> 
>> ___
>> 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 mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] u32 vs uint32_t

2017-09-11 Thread Luke, Chris

Thanks.

To be honest I would prefer using the standard type, but I also have a much 
stronger preference for consistency.

Chris.

From: Neale Ranns (nranns) [mailto:nra...@cisco.com]
Sent: Monday, September 11, 2017 1:18 PM
To: Dave Barach (dbarach) ; Dave Wallace 
; Florin Coras ; Luke, Chris 

Cc: vpp-dev 
Subject: Re: [vpp-dev] u32 vs uint32_t

+1. I’ll patch the uses of uin32_t.

/neale

From: > on 
behalf of "Dave Barach (dbarach)" >
Date: Monday, 11 September 2017 at 18:59
To: Dave Wallace >, Florin 
Coras >, "Luke, Chris" 
>
Cc: vpp-dev >
Subject: Re: [vpp-dev] u32 vs uint32_t

+1, let’s stick with u32... Thanks… Dave

From: vpp-dev-boun...@lists.fd.io 
[mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Dave Wallace
Sent: Monday, September 11, 2017 12:36 PM
To: Florin Coras >; Luke, 
Chris >
Cc: vpp-dev >
Subject: Re: [vpp-dev] u32 vs uint32_t

+1
On 09/11/2017 11:27 AM, Florin Coras wrote:
Hi Chris,

Personally, I’d like to enforce the use of u32. Is it an option to just replace 
all occurrences of uint32_t in ip.h/mpls.h?

Thanks,
Florin

On Sep 11, 2017, at 7:55 AM, Luke, Chris 
> wrote:

For discussion: VPP has traditionally used its own fixed-width types, such as 
u32 and u64 and only uses standard types when referring to the external world 
(eg, to talk to libc, etc). Recently I’ve noticed the C99 variant, uint32_t 
creeping in more and into VPP internal matters. As a matter of style and 
consistency, which should we as a project be using?

Reason I ask: The recent MPLS patch (https://gerrit.fd.io/r/#/c/8371) uses both 
styles in .h files but doesn’t have stdint.h included in any path leading to 
those .h’s; Coverity appears to be fussy about this – it checks that all types 
used in a .h are defined in the scope of that .h. Upshot is that Coverity is 
balking at this and only 54% of the project now compiles under Coverity

To resolve the issue with Coverity, I am torn with adding “#include ” 
to ip.h/mpls.h to fix it where it happens, or just accept that humans are 
inconsistent and add it to vppinfra/types.h. Thoughts?

Chris.

___
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 mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] JVPP API for adding MPLS local label

2017-09-11 Thread Neale Ranns (nranns)

Hi Jozef,

It’s mpls_route_add_del

Regards,
neale

From:  on behalf of Jozef Glončák 

Date: Monday, 11 September 2017 at 13:48
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] JVPP API for adding MPLS local label


Hello developers,



I would like substitude this VPP CLI command

mpls local-label add eos 101 ip4-lookup-in-table 1
with JVPP API call, but I am not able to find equivalent.



Is it possible?



Jozef Glončák

Pantheon Technologies, s. r. o.
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] u32 vs uint32_t

2017-09-11 Thread Neale Ranns (nranns)

+1. I’ll patch the uses of uin32_t.

/neale

From:  on behalf of "Dave Barach (dbarach)" 

Date: Monday, 11 September 2017 at 18:59
To: Dave Wallace , Florin Coras , 
"Luke, Chris" 
Cc: vpp-dev 
Subject: Re: [vpp-dev] u32 vs uint32_t

+1, let’s stick with u32... Thanks… Dave

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Dave Wallace
Sent: Monday, September 11, 2017 12:36 PM
To: Florin Coras ; Luke, Chris 
Cc: vpp-dev 
Subject: Re: [vpp-dev] u32 vs uint32_t

+1
On 09/11/2017 11:27 AM, Florin Coras wrote:
Hi Chris,

Personally, I’d like to enforce the use of u32. Is it an option to just replace 
all occurrences of uint32_t in ip.h/mpls.h?

Thanks,
Florin

On Sep 11, 2017, at 7:55 AM, Luke, Chris 
> wrote:

For discussion: VPP has traditionally used its own fixed-width types, such as 
u32 and u64 and only uses standard types when referring to the external world 
(eg, to talk to libc, etc). Recently I’ve noticed the C99 variant, uint32_t 
creeping in more and into VPP internal matters. As a matter of style and 
consistency, which should we as a project be using?

Reason I ask: The recent MPLS patch (https://gerrit.fd.io/r/#/c/8371) uses both 
styles in .h files but doesn’t have stdint.h included in any path leading to 
those .h’s; Coverity appears to be fussy about this – it checks that all types 
used in a .h are defined in the scope of that .h. Upshot is that Coverity is 
balking at this and only 54% of the project now compiles under Coverity

To resolve the issue with Coverity, I am torn with adding “#include ” 
to ip.h/mpls.h to fix it where it happens, or just accept that humans are 
inconsistent and add it to vppinfra/types.h. Thoughts?

Chris.

___
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 mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] u32 vs uint32_t

2017-09-11 Thread Dave Barach (dbarach)

+1, let’s stick with u32... Thanks… Dave

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Dave Wallace
Sent: Monday, September 11, 2017 12:36 PM
To: Florin Coras ; Luke, Chris 
Cc: vpp-dev 
Subject: Re: [vpp-dev] u32 vs uint32_t

+1
On 09/11/2017 11:27 AM, Florin Coras wrote:
Hi Chris,

Personally, I’d like to enforce the use of u32. Is it an option to just replace 
all occurrences of uint32_t in ip.h/mpls.h?

Thanks,
Florin

On Sep 11, 2017, at 7:55 AM, Luke, Chris 
> wrote:

For discussion: VPP has traditionally used its own fixed-width types, such as 
u32 and u64 and only uses standard types when referring to the external world 
(eg, to talk to libc, etc). Recently I’ve noticed the C99 variant, uint32_t 
creeping in more and into VPP internal matters. As a matter of style and 
consistency, which should we as a project be using?

Reason I ask: The recent MPLS patch (https://gerrit.fd.io/r/#/c/8371) uses both 
styles in .h files but doesn’t have stdint.h included in any path leading to 
those .h’s; Coverity appears to be fussy about this – it checks that all types 
used in a .h are defined in the scope of that .h. Upshot is that Coverity is 
balking at this and only 54% of the project now compiles under Coverity

To resolve the issue with Coverity, I am torn with adding “#include ” 
to ip.h/mpls.h to fix it where it happens, or just accept that humans are 
inconsistent and add it to vppinfra/types.h. Thoughts?

Chris.

___
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 mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Icmp support in Stateful ACL

2017-09-11 Thread Ed Warnicke

Andrew,
 Could you have a look?

Ed

On Mon, Sep 11, 2017 at 2:37 AM, chore  wrote:

> Dear Team
>
> I had a commit in acl plugin to support Icmp proto in Stateful ACL. please
> kindly review the changes .
>
> Best Regards,
> Chore
>
> ___
> 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] [tsc] FD.io Jenkins Maintenance: 2017-09-07 @ 0415 UTC (9:15am PDT)

2017-09-11 Thread Vanessa Valderrama

The change is made, I'll be monitoring trends throughout the day. 
Please contact me via IRC valderrv if you experience any issues related
to timeouts or increate in build times.

Thank you,
Vanessa

On 09/11/2017 10:29 AM, Florin Coras wrote:
> Thanks, Vanessa!
>
> Florin
>
>> On Sep 11, 2017, at 7:53 AM, Vanessa Valderrama
>> > > wrote:
>>
>> Switching VPP jobs to new instances.  This change should stabilize
>> build times.
>>
>> Thank you,
>> Vanessa
>>
>> On 09/08/2017 01:51 PM, Vanessa Valderrama wrote:
>>> While the build timeouts issue appears to be resolved, there does
>>> seem to be an increase in build times for various VPP jobs.  We are
>>> aware of and looking into this issue.
>>>
>>> Thank you,
>>> Vanessa
>>>
>>>
>>> On 09/07/2017 11:27 AM, Vanessa Valderrama wrote:

 Change is complete.  The new nodes appear to be spinning up
 successfully.  We'll be monitoring jobs throughout the day.  Please
 report issues via IRC fdio-infra.

 Thank you,
 Vanessa

 On 09/07/2017 11:18 AM, Vanessa Valderrama wrote:
>
> Starting change now.
>
>
> On 09/07/2017 10:51 AM, Vanessa Valderrama wrote:
>>
>>
>>
>> What:
>>
>> LF is switching VPP jobs to use new Jenkins nodes with dedicated
>> core instances
>>
>> When:
>>
>> 2017-09-07 @ 0415 UTC (9:15am PDT)
>>
>>
>> Impact:
>>
>> No restart is required for this change.  Once the change is made
>> new instances will spin up on the new nodes.
>>
>> Why:
>>
>> Various FD.io  projects have been intermittently
>> experiencing build time out issues.  Dedicated core instances
>> should alleviate these issues by reducing CPU over subscription.
>>
>>
>

>>>
>>
>> ___
>> tsc mailing list
>> t...@lists.fd.io 
>> https://lists.fd.io/mailman/listinfo/tsc
>



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

Re: [vpp-dev] [tsc] FD.io Jenkins Maintenance: 2017-09-07 @ 0415 UTC (9:15am PDT)

2017-09-11 Thread Florin Coras

Thanks, Vanessa!

Florin

> On Sep 11, 2017, at 7:53 AM, Vanessa Valderrama 
>  wrote:
> 
> Switching VPP jobs to new instances.  This change should stabilize build 
> times.
> 
> Thank you,
> Vanessa
> 
> On 09/08/2017 01:51 PM, Vanessa Valderrama wrote:
>> While the build timeouts issue appears to be resolved, there does seem to be 
>> an increase in build times for various VPP jobs.  We are aware of and 
>> looking into this issue.
>> 
>> Thank you,
>> Vanessa
>> 
>> 
>> On 09/07/2017 11:27 AM, Vanessa Valderrama wrote:
>>> Change is complete.  The new nodes appear to be spinning up successfully.  
>>> We'll be monitoring jobs throughout the day.  Please report issues via IRC 
>>> fdio-infra.
>>> 
>>> Thank you,
>>> Vanessa
>>> 
>>> On 09/07/2017 11:18 AM, Vanessa Valderrama wrote:
 Starting change now.
 
 On 09/07/2017 10:51 AM, Vanessa Valderrama wrote:
> 
> 
> 
> What:
> 
> LF is switching VPP jobs to use new Jenkins nodes with dedicated core 
> instances
> When:
> 
> 2017-09-07 @ 0415 UTC (9:15am PDT)
> 
> 
> Impact:
> 
> No restart is required for this change.  Once the change is made new 
> instances will spin up on the new nodes.
> 
> Why:
> Various FD.io projects have been intermittently experiencing build time 
> out issues.  Dedicated core instances should alleviate these issues by 
> reducing CPU over subscription.
> 
> 
 
>>> 
>> 
> 
> ___
> tsc mailing list
> t...@lists.fd.io
> https://lists.fd.io/mailman/listinfo/tsc

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

[vpp-dev] u32 vs uint32_t

2017-09-11 Thread Luke, Chris

For discussion: VPP has traditionally used its own fixed-width types, such as 
u32 and u64 and only uses standard types when referring to the external world 
(eg, to talk to libc, etc). Recently I've noticed the C99 variant, uint32_t 
creeping in more and into VPP internal matters. As a matter of style and 
consistency, which should we as a project be using?

Reason I ask: The recent MPLS patch (https://gerrit.fd.io/r/#/c/8371) uses both 
styles in .h files but doesn't have stdint.h included in any path leading to 
those .h's; Coverity appears to be fussy about this - it checks that all types 
used in a .h are defined in the scope of that .h. Upshot is that Coverity is 
balking at this and only 54% of the project now compiles under Coverity

To resolve the issue with Coverity, I am torn with adding "#include " 
to ip.h/mpls.h to fix it where it happens, or just accept that humans are 
inconsistent and add it to vppinfra/types.h. Thoughts?

Chris.

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

Re: [vpp-dev] FD.io Jenkins Maintenance: 2017-09-07 @ 0415 UTC (9:15am PDT)

2017-09-11 Thread Vanessa Valderrama

Switching VPP jobs to new instances.  This change should stabilize build
times.

Thank you,
Vanessa

On 09/08/2017 01:51 PM, Vanessa Valderrama wrote:
> While the build timeouts issue appears to be resolved, there does seem
> to be an increase in build times for various VPP jobs.  We are aware
> of and looking into this issue.
>
> Thank you,
> Vanessa
>
>
> On 09/07/2017 11:27 AM, Vanessa Valderrama wrote:
>>
>> Change is complete.  The new nodes appear to be spinning up
>> successfully.  We'll be monitoring jobs throughout the day.  Please
>> report issues via IRC fdio-infra.
>>
>> Thank you,
>> Vanessa
>>
>> On 09/07/2017 11:18 AM, Vanessa Valderrama wrote:
>>>
>>> Starting change now.
>>>
>>>
>>> On 09/07/2017 10:51 AM, Vanessa Valderrama wrote:

 What:

 LF is switching VPP jobs to use new Jenkins nodes with dedicated
 core instances

 When:

 2017-09-07 @ 0415 UTC (9:15am PDT)

 Impact:

 No restart is required for this change.  Once the change is made
 new instances will spin up on the new nodes.


 Why:

 Various FD.io projects have been intermittently experiencing build
 time out issues.  Dedicated core instances should alleviate these
 issues by reducing CPU over subscription.


>>>
>>
>

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

Re: [vpp-dev] vhost-user stable implementation?: VPP native or DPDK

2017-09-11 Thread Steven Luong (sluong)

If you create the VIrtualEthernet interface via the CLI or binary API, it 
always uses VPP native. If you create the virtual interface via vdev in the 
dpdk clause in the startup file, it uses dpdk’s vhost-user.

The problem is in DPDK virtio-user that they don’t comply with virtio1.0 spec. 
I submitted a patch for them. I don’t think they took it yet.

Steven

From:  on behalf of "Guo, Ruijing" 

Date: Sunday, September 10, 2017 at 5:36 PM
To: "Saxena, Nitin" , "vpp-dev@lists.fd.io" 

Subject: Re: [vpp-dev] vhost-user stable implementation?: VPP native or DPDK


Just for your reference:
I am using vpp 17.07. The default one is vpp native. But it cannot work with 
virtio-user. So I change to vhost-user in dpdk.


From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Saxena, Nitin
Sent: Monday, September 11, 2017 1:22 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] vhost-user stable implementation?: VPP native or DPDK

Hi All

I went through following video regarding vhost-user.

https://www.youtube.com/watch?v=z-ZRof2hDP0

The question is in this video it has been told by default VPP implementation of 
vhost-user being used and not the dpdk one. Since this video is 1 yr old and I 
am using vpp version 1704. Can anyone please comment which vhost-user code is 
by default enabled in vpp1704 - is it dpdk one or VPP native? I can see in 
vpp-master/RELEASE.md that DPDK vhost was deprecated in vpp1609? Is it fixed 
now?

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

Re: [vpp-dev] Regarding vxlan_tool.py in SFC vNF

2017-09-11 Thread Srikanth Lingala

Hi Hongjun,
If I use vxlan_tool.py by stopping VPP in the SFC VM, packets are getting fine. 
Following are the vxlan_tool.py logs:

Packet #1
Eth Dst MAC: fa:16:3e:8b:b7:1e, Src MAC: 28:b6:80:5b:79:b0, Ethertype: 0x0800
IP Version: 4 IP Header Length: 5, TTL: 64, Protocol: 17, Src IP: 
123.123.123.100, Dst IP: 123.123.123.3
UDP Src Port: 46935, Dst Port: 6633, Length: 114, Checksum: 0
VxLAN/VxLAN-gpe VNI: 67, flags: 0c, Next: 4
NSH base nsp: 67, nsi: 255
NSH context c1: 0xc0a8021a, c2: 0x03ed, c3: 0x, c4: 0x


Packet #2
Eth Dst MAC: fa:16:3e:8b:b7:1e, Src MAC: 28:b6:80:5b:79:b0, Ethertype: 0x0800
IP Version: 4 IP Header Length: 5, TTL: 64, Protocol: 17, Src IP: 
123.123.123.100, Dst IP: 123.123.123.3
UDP Src Port: 57814, Dst Port: 6633, Length: 114, Checksum: 0
VxLAN/VxLAN-gpe VNI: 67, flags: 0c, Next: 4
NSH base nsp: 67, nsi: 255
NSH context c1: 0xc0a8021a, c2: 0x03ed, c3: 0x, c4: 0x


Packet #3
Eth Dst MAC: fa:16:3e:8b:b7:1e, Src MAC: 28:b6:80:5b:79:b0, Ethertype: 0x0800
IP Version: 4 IP Header Length: 5, TTL: 64, Protocol: 17, Src IP: 
123.123.123.100, Dst IP: 123.123.123.3
UDP Src Port: 46935, Dst Port: 6633, Length: 106, Checksum: 0
VxLAN/VxLAN-gpe VNI: 67, flags: 0c, Next: 4
NSH base nsp: 67, nsi: 255
NSH context c1: 0xc0a8021a, c2: 0x03ed, c3: 0x, c4: 0x

>From the above logs, I constructed the following VPP commands and executed in 
>SFC VM:

vppctl set int state GigabitEthernet0/2/0 up
vppctl set int ip table GigabitEthernet0/2/0 7
vppctl set int ip address GigabitEthernet0/2/0 123.123.123.3/24
vppctl ip route add 123.123.123.100/24 via 123.123.123.3 GigabitEthernet0/2/0
vppctl set interface mac address GigabitEthernet0/2/0 fa:16:3e:8b:b7:1e
vppctl set ip arp fib-id 7 GigabitEthernet0/2/0 123.123.123.100 
28:b6:80:5b:79:b0
vppctl create vxlan-gpe tunnel local 123.123.123.3 remote 123.123.123.100 vni 
67 next-nsh encap-vrf-id 7 decap-vrf-id 7
vppctl set int l2 bridge vxlan_gpe_tunnel0 1 1
vppctl create nsh map nsp 67 nsi 255 mapped-nsp 67 mapped-nsi 255 nsh_action 
swap encap-vxlan-gpe-intf 3
vppctl create nsh entry nsp 67 nsi 255 md-type 1 c1 XX c2 XX c3 0 c4 0 
next-ethernet

Here, I have a doubt. What should be the values for c1 and c2 from the above 
VPP commands? From the vxlan_tool.py logs, they are 0xc0a8021a and 0x03ed 
respectively.
But, when I run the same usecase while running the above VPP commands in SFC 
VM, I am getting packet drops. Following are some logs:

root@sfc_vm:/run/media/vda# vppctl show int
  Name   Idx   State  Counter  Count
GigabitEthernet0/2/0  1 up   rx packets 
 1473
 rx bytes  
168226
 tx packets 
  287
 tx bytes   
18754
 drops  
 1187
 ip4
  152
local00down
nsh_tunnel0   3 up
vxlan_gpe_tunnel0 2 up

root@sfc_vm:/run/media/vda# vppctl show error
   CountNode  Reason
50 ip4-udp-lookup no listener for dst port
   102ip4-input   ip4 adjacency drop
50 ip4-icmp-error destination unreachable 
response sent
  1085   lldp-input   lldp packets received on 
disabled interfaces
   236arp-input   ARP replies sent
 1arp-input   IP4 destination address not 
local to subnet

Can you please let me know, how can I trace the packets in VPP? Based on that, 
I can get some idea about the issue.

Thanks & Regards,
Srikanth.

From: Ni, Hongjun [mailto:hongjun...@intel.com]
Sent: Monday, September 11, 2017 5:38 PM
To: Srikanth Lingala 
Cc: Yang, Yi Y ; vpp-dev@lists.fd.io; 
nsh_sfc-...@lists.fd.io
Subject: RE: Regarding vxlan_tool.py in SFC vNF

Hi Srikanth,

Sorry for delayed response, because I am on a business travel.

>From your email and "show int", it seems that your packets are dropped on RX.

Please "show error" and uses packet trace to get the cause of packets dropped.

-Hongjun

From: Srikanth Lingala [mailto:srikanth.ling...@nxp.com]
Sent: Thursday, September 7, 2017 5:10 PM
To: Ni, Hongjun >
Cc: Yang, Yi Y >; 
vpp-dev@lists.fd.io; 
nsh_sfc-...@lists.fd.io
Subject: RE: Regarding vxlan_tool.py in SFC vNF

Hi Hongjun,
Sometime back, we are discussing about VPP in the

Re: [vpp-dev] Regarding vxlan_tool.py in SFC vNF

2017-09-11 Thread Ni, Hongjun

Hi Srikanth,

Sorry for delayed response, because I am on a business travel.

>From your email and "show int", it seems that your packets are dropped on RX.

Please "show error" and uses packet trace to get the cause of packets dropped.

-Hongjun

From: Srikanth Lingala [mailto:srikanth.ling...@nxp.com]
Sent: Thursday, September 7, 2017 5:10 PM
To: Ni, Hongjun 
Cc: Yang, Yi Y ; vpp-dev@lists.fd.io; 
nsh_sfc-...@lists.fd.io
Subject: RE: Regarding vxlan_tool.py in SFC vNF

Hi Hongjun,
Sometime back, we are discussing about VPP in the place of vxlan_tool.py.
Now, I am able to load nsh-plugin in VPP 17.04.
To simplify things, I put only one VM in SFC.
I am trying to execute the following commands in the SFC VM, which were 
suggested by you sometime back:

vppctl show dpdk int placement
vppctl set int state GigabitEthernet0/2/0 up
vppctl set int ip table GigabitEthernet0/2/0 7
vppctl set int ip address GigabitEthernet0/2/0 123.123.123.3/24
vppctl ip route add 192.168.2.26/24 via 123.123.123.3 GigabitEthernet0/2/0
vppctl set interface mac address GigabitEthernet0/2/0 fa16.3e64.8b49
vppctl set ip arp fib-id 7 GigabitEthernet0/2/0 192.168.2.26 fa16.3e64.8b49
vppctl create vxlan-gpe tunnel local 123.123.123.3 remote 192.168.2.26 vni 9 
next-nsh encap-vrf-id 7 decap-vrf-id 7
vppctl set int l2 bridge vxlan_gpe_tunnel0 1 1
vppctl create nsh map nsp 35 nsi 255 mapped-nsp 35 mapped-nsi 254 nsh_action 
swap encap-vxlan-gpe-intf 3
vppctl create nsh entry nsp 35 nsi 254 md-type 1 c1 3232236058 c2 0 c3 0 c4 0 
next-ethernet
vppctl create nsh entry nsp 35 nsi 254 md-type 1 c1 0 c2 0 c3 0 c4 0 
next-ethernet

Following are my NSH flows captured from Compute Node:
https://pastebin.com/P7dCCPDU


But, NSH packets are not forwarding in the VPP based SFC VM.
Can you please help me in fixing the above commands?

Regards,
Srikanth.

From: Ni, Hongjun [mailto:hongjun...@intel.com]
Sent: Tuesday, May 02, 2017 10:55 AM
To: Srikanth Lingala 
>; Yang, Yi Y 
>; 
vpp-dev@lists.fd.io; 
nsh_sfc-...@lists.fd.io
Subject: RE: Regarding vxlan_tool.py in SFC vNF

Hi Srikanth,

Please make sure nsh-plugin is loaded, and the nsh-plugin version is stable 
17.01 or more.

Yes,  you need to modify c1, c2, c3 and c4.

From: Srikanth Lingala [mailto:srikanth.ling...@nxp.com]
Sent: Friday, April 28, 2017 5:32 PM
To: Ni, Hongjun >; Yang, Yi Y 
>; 
vpp-dev@lists.fd.io; 
nsh_sfc-...@lists.fd.io
Subject: RE: Regarding vxlan_tool.py in SFC vNF

Hi Hongjun,
I am trying to execute the commands, you sent. I am able to execute the 
following commands in the VPP VM:

vppctl set int state GigabitEthernet0/2/0 up
vppctl set int ip table GigabitEthernet0/2/0 7
vppctl set int ip address GigabitEthernet0/2/0 123.123.123.3/24
vppctl ip route add 123.123.123.100/24 via 123.123.123.3 GigabitEthernet0/2/0
vppctl set interface mac address GigabitEthernet0/2/0 fa16.3e64.8b49
vppctl set ip arp fib-id 7 GigabitEthernet0/2/0 123.123.123.100 fa16.3e64.8b49
vppctl create vxlan-gpe tunnel local 123.123.123.3 remote 123.123.123.100 vni 9 
next-nsh encap-vrf-id 7 decap-vrf-id 7
vppctl set int l2 bridge vxlan_gpe_tunnel0 1 1

But, when I try to execute the below command, I got error:
root@VPP_vNF:~# vppctl create nsh map nsp 108 nsi 255 mapped-nsp 108 mapped-nsi 
254 nsh_action swap encap-vxlan-gpe-intf 3
create nsh map: parse error: 'nsh_action swap encap-vxlan-gp...'

And also, in the below command, I need to modify c1, c2, c3 and c4 attribute 
values. Right?
#> vppctl create nsh entry nsp 108 nsi 255 md-type 1 c1 1 c2 2 c3 3 c4 4 
next-ethernet

FYI, in the following link my NSH flows captured from Compute Node:
https://pastebin.com/y2uYD5cV


Thanks & Regards,
Srikanth.

From: Ni, Hongjun [mailto:hongjun...@intel.com]
Sent: Friday, April 28, 2017 11:31 AM
To: Srikanth Lingala 
>; Yang, Yi Y 
>; 
vpp-dev@lists.fd.io; 
nsh_sfc-...@lists.fd.io
Subject: RE: Regarding vxlan_tool.py in SFC vNF

Please see inline comments.

From: Srikanth Lingala [mailto:srikanth.ling...@nxp.com]
Sent: Friday, April 28, 2017 1:58 PM
To: Ni, Hongjun >; Yang, Yi Y 
>; 
vpp-dev@lists.fd.io; 
nsh_sfc-...@lists.fd.io
Subject: RE: Regarding vxlan_tool.py in SFC vNF

Hi Hongjun,
Thanks for your time to recreate those commands.
I have some doubts :).
What about the nsp and nsi id's? They can be anything or need to get them from

Re: [vpp-dev] VPP contribute

2017-09-11 Thread Dave Barach (dbarach)

That’s right, no need to send patches to a mailing list. In fact, please don’t 
send patches to this list. ()...

Thanks… Dave

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Shachar Beiser
Sent: Monday, September 11, 2017 7:48 AM
To: vpp-dev@lists.fd.io
Cc: Damjan Marion (damarion) 
Subject: [vpp-dev] VPP contribute

Hi ,

   I contribute to the VPP for the first time.
   I am following the instructions in your web-site : 
https://wiki.fd.io/view/VPP/Pulling,_Building,_Running,_Hacking_and_Pushing_VPP_Code#Setting_up_Gerrit
   Is that it ? don’t I need to send my patches to the mailing-list ?

   -Shachar Beiser.

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

Re: [vpp-dev] Running CLI against named vpp instance

2017-09-11 Thread Marek Gradzki -X (mgradzki - PANTHEON TECHNOLOGIES at Cisco)

Ed,

sudo vpp api-segment { prefix vpp1 } unix { cli-listen /run/vpp/cli.vpp1.sock }
+
vppctl -s /run/vpp/cli.vpp1.sock

works indeed, but then

sudo vpp api-segment { prefix vpp2 } unix { cli-listen /run/vpp/cli.vpp2.sock }

does not start.

But anyway I was able to run vpp in docker and don’t need this feature anymore.

Thanks,
Marek

From: Ed Warnicke [mailto:hagb...@gmail.com]
Sent: 7 września 2017 15:39
To: Marek Gradzki -X (mgradzki - PANTHEON TECHNOLOGIES at Cisco) 

Cc: Dave Wallace ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Running CLI against named vpp instance

Marek,

I don't think you have a local issue.  I think what is happening is that the 
instructions for running multiple vpps has changed.

With the advent of the new C vppctl, which is using a different method:

sudo vpp api-segment { prefix vpp1 } unix { cli-listen /run/vpp/cli.vpp1.sock }

(In the example above I arbitrarily chose the cli-listen socket name... you can 
pick whatever you want as long as its unique among the set of vpps you are 
running).

Then to address it with vppctl you'd use:

vppctl -s /run/vpp/cli.vpp1.sock

essentially -s is replacing -p.

Please note, the above is based on Wallace's excellent description in this 
thread, I have not yet tried it, and would be grateful if you would do so and 
tell me if it works :)

Ed

On Thu, Sep 7, 2017 at 1:00 AM, Marek Gradzki -X (mgradzki - PANTHEON 
TECHNOLOGIES at Cisco) > wrote:
Dave, Ed

with 17.07 I was able to run two vpp instances and connect CLI to them as 
described here:
https://wiki.fd.io/view/VPP/Progressive_VPP_Tutorial#Action:_Run_vpp

So one needed just to specify prefix when starting vpp and vppctl.
There was no need to do any other configuration changes.

With current master (both build locally or using most recent ub16 packages)
it does not work for me.

I also tired explicitly specifying cfg files with different sockets,
Api segments + corresponding vppctl parameters (-p, -s)
+ some combinations.

It is possible I have some local issue,
so I would be grateful if you could share config that works for you.

Thanks,
Marek

From: Dave Wallace [mailto:dwallac...@gmail.com]
Sent: 6 września 2017 18:07
To: Ed Warnicke >
Cc: Marek Gradzki -X (mgradzki - PANTHEON TECHNOLOGIES at Cisco) 
>; 
vpp-dev@lists.fd.io

Subject: Re: [vpp-dev] Running CLI against named vpp instance

Ed,

vppctl already has a command line arg (-s) which allows the user to specify a 
specific socket pathname which must be the same as the "cli-listen " 
configuration in a given vpp instance.  Adding a naming convention to both vpp 
and vppctl is going to over-complicate the matter.

Thanks,
-daw-

On 09/06/2017 11:01 AM, Ed Warnicke wrote:
Dave,

I think we would need to be sure that different vpp instances have different 
cli-listen socket files, and that vppctl has a mechanism to address them easily.

I'd suggest a pattern like

"unix { cli-listen /run/vpp.cli-${prefix}.sock"

and

vppctl -p ${prefix}

to be in line with current usage.

Ed

On Wed, Sep 6, 2017 at 7:50 AM, Dave Wallace 
> wrote:
Marek,

Please check the vpp startup configuration (/etc/vpp/startup.conf) to ensure 
that "unix { cli-listen /run/vpp/cli.sock }" is present.  This is the default 
socket used by the 'c' implementation of vppctl.

I'm going to fix the error message to output the socket file name to make this 
easier to debug.

Thanks,
-daw-

On 09/06/2017 05:55 AM, Marek Gradzki -X (mgradzki - PANTHEON TECHNOLOGIES at 
Cisco) wrote:
Dave,

please find replies inline.

From: Dave Wallace [mailto:dwallac...@gmail.com]
Sent: 5 września 2017 16:41
To: Marek Gradzki -X (mgradzki - PANTHEON TECHNOLOGIES at Cisco) 
; 
vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Running CLI against named vpp instance

Marek,

What is the uid/gid of /dev/shm/vpe-api ?
root/vpp

Is the user a member of the vpp group?
yes

Does your VPP workspace include the patch c900ccc34 "Enabled gid vpp in 
startup.conf to allow non-root vppctl access" ?
yes (I’ve built master with HEAD @ 809bc74, also tested corresponding package 
from nexus)

Thanks,
-daw-
On 09/05/2017 06:08 AM, Marek Gradzki -X (mgradzki - PANTHEON TECHNOLOGIES at 
Cisco) wrote:
Hi,

I am having problems with running CLI against named vpp instance (g809bc74):

sudo vpp api-segment { prefix vpp0 }

sudo vppctl -p vpp0 show int
clib_socket_init: connect: Connection refused

But ps shows vpp process is running.

It worked with 17.07.
Is it no longer supported or I need some additional configuration?

Regards,
Marek

___

vpp-dev mailing list

vpp-dev@lists.fd.io

[vpp-dev] Icmp support in Stateful ACL

2017-09-11 Thread chore

Dear Team

I had a commit in acl plugin to support Icmp proto in Stateful ACL. please
kindly review the changes .

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

Re: [vpp-dev] [csit-dev] make test python segfault in ubuntu 16.04

2017-09-11 Thread Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)

Dave,

the tests are not run in parallel. For each testcase  *class* a new vpp is
started and all the tests which are members of that class are run
against that vpp. Then the vpp is killed and another class is picked. We
use a helper thread to "pump" stdout & stderr from vpp to the logger,
motivation being - have it time-synchronized as much as possible with
the other logger messages. Afaik there is nothing which blocks the python
interpreter from reaping the thread.

Regarding timeouts - the first thing the framework does is setup a few
communication pipes and fork. Child sends periodic keepalives
by writing a tuple describing test class running, it's temporary
directory etc. to the pipe. If sufficient time passes without
activity on the pipe, the child is considered stuck, killed and the
messages which you describe appear. This usually happens if vpp
coredumps mid-api call, in which case the wait for shared memory
condition will never finish (as there is no vpp to signal that condition).

Regards,
Klement

Quoting Dave Wallace (2017-08-25 19:56:13)
>vpp-dev, Florin,
> 
>Below is an analysis of the all of the failures that this patch
>encountered before finally passing. None of the failures were related in
>any way to the code changes in the patch.
> 
>In summary, there appear to be a number of different factors involved with
>these failures.
> 
>  • Two failures appear to be caused by the run-time environment.
>  • An intermittent bug appears to exist in `L2BD Multi-instance test 5 -
>delete 5 BDs'
>  • The segfault shows lots of threads being run.  Are tests being
>executed in parallel?  If so, it would be interesting to serialize the
>tests to see if that fixes any of these issues.
> 
>I'm also seeing a variation in the order that the "make tests" are run (or
>at least in the order of the status reports).  My understanding of the
>'make test' python infrastructure is insufficient to make an intelligent
>guess as to whether this has any bearing on any of these failures.
> 
>I get more predictable result output when running make test locally on my
>own server, but the order of test output is different than in the CI test
>runs.  Locally, the order of tests appears to be the same between
>different runs of 'make test'.  I have also not seen any of these errors
>on my server which is running Ubuntu 17.04, although I have not done an
>endurance test either.
> 
>My recommendation based on this analysis is as follows:
>  1. The L2BD unit test issue be investigated by the appropriate 'make
>test' experts
>  2. vpp-verify-master-centos7, vpp-verify-master-ubuntu1604, and
>vpp-test-debug-master-ubuntu1604 jobs should be run operationally in the
>Container PoC environment with the rest of the jjb jobs run in the cloud
>infra.
> 
>Thanks,
>-daw-
> 
> %< 
>[ From [1]https://gerrit.fd.io/r/#/c/8133 ]
> 
>=> Container PoC Aug 24 8:36 PM  Patch Set 9:  Build Successful
>[2]http://jenkins.ejkern.net:8080/job/vpp-docs-verify-master/1515/ :
>SUCCESS
>
> [3]http://jenkins.ejkern.net:8080/job/vpp-make-test-docs-verify-master/1512/
>: SUCCESS
>[4]http://jenkins.ejkern.net:8080/job/vpp-verify-master-centos7/1983/ :
>SUCCESS
>
> [5]http://jenkins.ejkern.net:8080/job/vpp-test-debug-master-ubuntu1604/1301/
>: SUCCESS
>[6]http://jenkins.ejkern.net:8080/job/vpp-verify-master-ubuntu1604/2022/ :
>SUCCESS
>[7]http://jenkins.ejkern.net:8080/job/vpp-fake-csit-verify-master/1695/ :
>SUCCESS
> 
>=> fd.io JJB  Aug 24 9:19 PM  Patch Set 9:  Verified-1  Build Failed
>[8]https://jenkins.fd.io/job/vpp-verify-master-ubuntu1604/6775/ : FAILURE
>Logs:
>
> [9]https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-master-ubuntu1604/6775
> 
>  Failure Signature:
>    01:08:59  verify templates on IP6 datapath  Fatal Python error:
>  Segmentation fault
> 
>  Comment:
>    Python bug or resource starvation?  Lots of threads running...
>    Possibly due to bad environment/sick minion.
> 
>[10]https://jenkins.fd.io/job/vpp-make-test-docs-verify-master/3098/ :
>SUCCESS
>[11]https://jenkins.fd.io/job/vpp-verify-master-centos7/6770/ : SUCCESS
>[12]https://jenkins.fd.io/job/vpp-csit-verify-virl-master/6781/ : SUCCESS
>[13]https://jenkins.fd.io/job/vpp-docs-verify-master/5370/ : SUCCESS
> 
>=> Container PoC  Aug 24 10:54 PM  Patch Set 9:  Build Successful
>[14]http://jenkins.ejkern.net:8080/job/vpp-docs-verify-master/1519/ :
>SUCCESS
>
> [15]http://jenkins.ejkern.net:8080/job/vpp-make-test-docs-verify-master/1516/
>: SUCCESS
>[16]http://jenkins.ejkern.net:8080/job/vpp-verify-master-centos7/1987/ :
>SUCCESS
>
> [17]http://jenkins.ejkern.net:8080/job/vpp-test-debug-master-ubuntu1604/1305/
>: SUCCESS
>

Re: [vpp-dev] Query for IPSec support on VPP

2017-09-11 Thread Sergio Gonzalez Monroy


Hi Mukesh,

I am by no means an expert on the matter but after talking to some folks 
my understanding is that it is a common feature (uRPF).


This issue has nothing to do with IPsec though, I am pretty sure you 
could reproduce the issue with other tunnels too.
Note that uRPF would apply to packets with local destination, in this 
case the inner address is also the interface address.


I think it makes sense that the packet was drop given that we did not 
have any default route.


Thanks,
Sergio


On 09/09/2017 10:44, Mukesh Yadav (mukyadav) wrote:

HI Sergio,

Thanks with changes as below, IPSec worked in tunnel mode as well.

Is this restriction right?
i.e dropping packet in Rx processing if there is no route for Source IP.
In normal linux machine we simply process the packet and in TX we 1st Make a 
packet and then route matter when we do forward.

Specially in IPSec use-case, why should route of Inner Source IP matter at all.
It’s anyway going to be encrypted and sent across.
Route of Outer IP is what shall matter, not the Inner Peer IP in tunnel mode.

Thanks
Mukesh

On 07/09/17, 5:55 PM, "Sergio Gonzalez Monroy" 
 wrote:

 Hi Mukesh,
 
 I think the problem is that we do not have fib entry for 1.1.1.1 network.
 
 I guess there are different ways to fix the issue, I did the following

 (already updated interface name to match your config):
 
 set ip arp GigabitEthernet0/8/0 2.2.2.254 be:ef:00:00:00:02

 ip route add 1.1.1.0/24 via 2.2.2.254 GigabitEthernet0/8/0
 
 Let me know if it does the trick.
 
 Thanks,

 Sergio
 
 
 



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

[vpp-dev] VPP API Freeze September 13

2017-09-11 Thread Florin Coras

All, 

On September 13th end of day PST we enter VPP API freeze for the upcoming 17.10 
release. Subsequently, we will not be accepting binary API patches nor 
high-risk changes on the main branch. 

API freeze will last until September 27th when 17.10 stable branch will be 
created and master will return to normal operation. For more details, please 
refer to the release plan [1]. 

Regards, 
Florin

[1] https://wiki.fd.io/view/Projects/vpp/Release_Plans/Release_Plan_17.10 
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Build vpp on openwrt

2017-09-11 Thread Pierre Pfister (ppfister)

Hello.

I didn't try it.
But the hardest is probably not to build VPP in an OpenWrt system.
I'd dare say it would be easy if OpenWrt is compiled for x86 target.

The real question is what platform do you want to compile OpenWrt for ?

- Pierre


Le 9 sept. 2017 à 03:18, yug...@telincn.com a écrit :

Hi all,
Is there anyone try to build vpp on openwrt?

Regards,
Ewan


yug...@telincn.com
___
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] questions about bihash

2017-09-11 Thread chupenghong

hi,all
when a writer adds or deletes some elements in a bucket of a hash table, the 
bihash algorithm tries to making a working copy of the bucket and the reader 
may use the working copy to search.  However, it is possible for the reader to 
use the bucket to search before the writer makes the working copy and the 
writer may then modify the bucket even if the reader is still using it. Another 
possibility is that when a reader is using the working copy and a writer may 
change the working copy for another bucket modification. In any case, the 
reader may can't find a element already in the hash table or get a wrong value 
of a element.
I don't verify the analysis above at a running environment and all the analysis 
is based on the code. Please help me to check out whether the analysis is 
right.  
Regards,
chu.penghong

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

Re: [vpp-dev] VPP contribute

Re: [vpp-dev] Icmp support in Stateful ACL

Re: [vpp-dev] u32 vs uint32_t

Re: [vpp-dev] JVPP API for adding MPLS local label

Re: [vpp-dev] u32 vs uint32_t

Re: [vpp-dev] u32 vs uint32_t

Re: [vpp-dev] Icmp support in Stateful ACL

Re: [vpp-dev] [tsc] FD.io Jenkins Maintenance: 2017-09-07 @ 0415 UTC (9:15am PDT)

Re: [vpp-dev] [tsc] FD.io Jenkins Maintenance: 2017-09-07 @ 0415 UTC (9:15am PDT)

[vpp-dev] u32 vs uint32_t

Re: [vpp-dev] FD.io Jenkins Maintenance: 2017-09-07 @ 0415 UTC (9:15am PDT)

Re: [vpp-dev] vhost-user stable implementation?: VPP native or DPDK

Re: [vpp-dev] Regarding vxlan_tool.py in SFC vNF

Re: [vpp-dev] Regarding vxlan_tool.py in SFC vNF

Re: [vpp-dev] VPP contribute

Re: [vpp-dev] Running CLI against named vpp instance

[vpp-dev] Icmp support in Stateful ACL

Re: [vpp-dev] [csit-dev] make test python segfault in ubuntu 16.04

Re: [vpp-dev] Query for IPSec support on VPP

[vpp-dev] VPP API Freeze September 13

Re: [vpp-dev] Build vpp on openwrt

[vpp-dev] questions about bihash

22 matches

Site Navigation

Mail list logo

Footer information