Re: [vpp-dev] [tsc] Hc2vpp 1.17.04 released

2017-04-28 Thread 倪红军 

Congratulations to all guys !



At 2017-04-28 23:40:38, "Marek Gradzki -X (mgradzki - PANTHEON TECHNOLOGIES at 
Cisco)"  wrote:


The hc2vpp 1.17.04 release is up.

 

All hc2vpp artifacts (JARs, u14 DEBs, centos7 RPM)

are uploaded to nexus server.

 

More details can be found in release notes:

https://docs.fd.io/hc2vpp/1.17.04/hc2vpp-parent/release-notes-aggregator/release_notes.html

 

Many thanks to all contributors, testers and LF infra engineers,

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

Re: [vpp-dev] A Curious DHCP Hostname Terminator Choice

2017-04-28 Thread Burt Silverman 
Way back when I must have been dealing with u8* versus char* rather than
u8[] versus char[], but that slight bit of confusion on my part does not
change my suggestion:-)

Burt

On Thu, Apr 27, 2017 at 4:09 PM, Burt Silverman  wrote:

> If I were coding, in addition to Jon's change, I probably would change
> "u8" to "char" for the type of hostname elements in the dhcp_client_config
> and dhcp_compl_event in dhcp.api, because way back when I liked to think of
> u8 as a hint that the array is a vector style string, i.e., not terminated
> with a null. I don't know how carefully we maintained the convention years
> ago, and I haven't looked at much code recently. I didn't write "unsigned
> char" above because strings are usually "char".
>
> Burt
>
> On Thu, Apr 27, 2017 at 2:19 PM, Luke, Chris 
> wrote:
>
>> > Jon Loeliger said:
>> >> On Thu, Apr 27, 2017 at 12:19 PM, Luke, Chris > chris_l...@comcast.com> wrote:
>> >> [...] What I am not sure of is NUL in DHCP hostname strings – I
>> remember reading somewhere
>> >> it’s optional, so I suspect that means the TLV length is used to
>> determine the string length;
>> >> meaning it might be possible to have a hostname that is 64 printable
>> characters long. Maybe.
>> >
>> > According to my RFC digging, 1 to 63 characters.
>> >
>> > NUL is not a valid hostname character.
>>
>> What it actually says is:
>>
>>sname64  Optional server host name, null terminated string.
>>
>> So yes, you're semantically correct. I forgot in the original DHCP this
>> was a static field and not a TLV. In DHCPv6 however it doesn't exist.
>>
>> 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

Re: [vpp-dev] setting up PCI interface on Centos 7 system

2017-04-28 Thread Damjan Marion 


Looks like packets are dropped due to source lookup miss, so your device setup 
is fine. Check your ipv4 addressing...

Sent from my iPhone

> On 28 Apr 2017, at 17:52, Guy Doucet -X (gudoucet - FLEXTRONICS CANADA DESIGN 
> SERVICES INC at Cisco)  wrote:
> 
> Hi,
>  
> I am trying to connect a PCI interface by following the instructions on the 
> wiki on a Centos 7 system.
>  
> I built and installed VPP and was able to setup the interface 
> GigabitEthernet1/0/1 and add the ip address.
>  
> Unfortunately all messages are being dropped. The following is a capture of 
> my ping:
>  
> 00:43:16:995516: dpdk-input
>   GigabitEthernet1/0/1 rx queue 0
>   buffer 0xccda79: current data 14, length 84, free-list 0, clone-count 0, 
> totlen-nifb 0, trace 0x3
>   PKT MBUF: port 0, nb_segs 1, pkt_len 98
> buf_len 2176, data_len 98, ol_flags 0x180, data_off 128, phys_addr 
> 0x8d65d40
> packet_type 0x11
> Packet Offload Flags
>   PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
>   PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
> Packet Types
>   RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
>   RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension headers
>   IP4: b8:38:61:64:91:bf -> 2c:5a:0f:ff:c1:5b
>   ICMP: 10.30.3.2 -> 10.30.5.2
> tos 0x00, ttl 63, length 84, checksum 0x7106
> fragment id 0xae63, flags DONT_FRAGMENT
>   ICMP echo_request checksum 0x9b75
> 00:43:16:995524: ip4-input-no-checksum
>   ICMP: 10.30.3.2 -> 10.30.5.2
> tos 0x00, ttl 63, length 84, checksum 0x7106
> fragment id 0xae63, flags DONT_FRAGMENT
>   ICMP echo_request checksum 0x9b75
> 00:43:16:995530: ip4-lookup
>   fib 0 dpo-idx 6 flow hash: 0x
>   ICMP: 10.30.3.2 -> 10.30.5.2
> tos 0x00, ttl 63, length 84, checksum 0x7106
> fragment id 0xae63, flags DONT_FRAGMENT
>   ICMP echo_request checksum 0x9b75
> 00:43:16:995542: ip4-local
> ICMP: 10.30.3.2 -> 10.30.5.2
>   tos 0x00, ttl 63, length 84, checksum 0x7106
>   fragment id 0xae63, flags DONT_FRAGMENT
> ICMP echo_request checksum 0x9b75
> 00:43:16:995546: error-drop
>   ip4-input: ip4 source lookup miss
>  
> I suspect that this is because I was unable to run the modprobe igb_uio as 
> indicated in the wiki.
>  
> Any ideas on how to set this up to work correctly on a Centos machine?
>  
> Thanks,
>  
> Guy
> ___
> 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] Hc2vpp 1.17.04 released

2017-04-28 Thread Marek Gradzki -X (mgradzki - PANTHEON TECHNOLOGIES at Cisco) 
The hc2vpp 1.17.04 release is up.

All hc2vpp artifacts (JARs, u14 DEBs, centos7 RPM)
are uploaded to nexus server.

More details can be found in release notes:
https://docs.fd.io/hc2vpp/1.17.04/hc2vpp-parent/release-notes-aggregator/release_notes.html

Many thanks to all contributors, testers and LF infra engineers,
Marek
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] acl packet trace interpretation help

2017-04-28 Thread Juraj Linkes -X (jlinkes - PANTHEON TECHNOLOGIES at Cisco) 
Hi vpp devs,

I'm using vpp-17.04-release.x86_64 on CentOS 7.3 and I'm trying to figure out 
what does this packet trace mean:
Packet 9

00:15:18:177142: tapcli-rx
  tap-2
00:15:18:177155: ethernet-input
  IP4: fa:16:3e:eb:c6:6d -> fa:16:3e:9b:93:4a
00:15:18:177159: l2-input
  l2-input: sw_if_index 4 dst fa:16:3e:9b:93:4a src fa:16:3e:eb:c6:6d
00:15:18:177161: l2-input-classify
  l2-classify: sw_if_index 4, table 1, offset 0, next 21
00:15:18:177163: acl-plugin-in-ip4-l2
  acl-plugin: sw_if_index 4, next index 0, action: 0, match: acl -1 rule -1 
trace_bits 
  pkt info  7073c30a  0700640a 
00010008 0400
00:15:18:177167: error-drop
  acl-plugin-in-ip4-l2: ACL deny packets

What do acl -1 and rule -1 mean? I expected to find acl and rule indices in the 
trace, but I don't know what -1 means. I've looked at which acls are on that 
inteface in vat:
vat# acl_interface_list_dump
vl_api_acl_interface_list_details_t_handler:152: sw_if_index: 0, count: 0, 
n_input: 0
   input
vat# vl_api_acl_interface_list_details_t_handler:152: sw_if_index: 1, count: 0, 
n_input: 0
   input
vl_api_acl_interface_list_details_t_handler:152: sw_if_index: 2, count: 2, 
n_input: 1
   input 83886080
  output 67108864
vl_api_acl_interface_list_details_t_handler:152: sw_if_index: 3, count: 2, 
n_input: 1
   input 0
  output 16777216

vl_api_acl_interface_list_details_t_handler:152: sw_if_index: 4, count: 0, 
n_input: 0
   input
vl_api_acl_interface_list_details_t_handler:152: sw_if_index: 6, count: 0, 
n_input: 0
   input
vl_api_acl_interface_list_details_t_handler:152: sw_if_index: 7, count: 0, 
n_input: 0
   input
vl_api_acl_interface_list_details_t_handler:152: sw_if_index: 8, count: 0, 
n_input: 0
   input

It says there are no acls associated with the interface. No sure how what acls 
are being applied then. And what about the acls indices (83886080, 67108864 and 
16777216)? I only have six acls configured (indices 0-5) and the indices are 
way off. Is it some sort of overflow? Note that we're using honeycomb to 
configure these.

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

Re: [vpp-dev] [discuss] CSIT rls1704 report published

2017-04-28 Thread Jerome Tollet (jtollet) 
Congratulation! Performance are increasing version over versions !

Le 27/04/2017 21:50, « discuss-boun...@lists.fd.io au nom de Maciek 
Konstantynowicz (mkonstan) »  a écrit :

The CSIT rls1704 report is published on FD.io docs site: 
https://docs.fd.io/csit/rls1704/report/

Many Thanks to All Contributors and Committers that worked on csit
rls1704 and made it happen !

And of course Many Thanks to VPP contributors and committers that gave
us a solid piece of VPP rls1704 to test and report on :)

Linked report includes results of i) VPP performance and functional
tests, ii) Testpmd performance tests, iii) Honeycomb functional tests,
and iv) reference to VPP unit tests.

Points of note in the report:

- Added tests including Centos7, crypto-HW, cgnat


https://docs.fd.io/csit/rls1704/report/vpp_performance_tests/csit_release_notes.html#changes-in-csit-release

https://docs.fd.io/csit/rls1704/report/vpp_functional_tests/csit_release_notes.html#changes-in-csit-release

https://docs.fd.io/csit/rls1704/report/testpmd_performance_tests/csit_release_notes.html#changes-in-csit-release

- Measured VPP performance improvements


https://docs.fd.io/csit/rls1704/report/vpp_performance_tests/csit_release_notes.html#performance-improvements

- Performance graphs - throughput and latency for VPP and DPDK-Testpmd


https://docs.fd.io/csit/rls1704/report/vpp_performance_tests/packet_throughput_graphs/index.html

https://docs.fd.io/csit/rls1704/report/vpp_performance_tests/packet_latency_graphs/index.html

https://docs.fd.io/csit/rls1704/report/testpmd_performance_tests/packet_throughput_graphs/index.html

https://docs.fd.io/csit/rls1704/report/testpmd_performance_tests/packet_latency_graphs/index.html

- VPP configs used per test case


https://docs.fd.io/csit/rls1704/report/test_configuration/vpp_performance_configuration/index.html

https://docs.fd.io/csit/rls1704/report/test_configuration/vpp_functional_configuration/index.html

- VPP operational data - "show runtime” outputs at NDR rate with CPU 
core
  clock cycles spent per worker node per packet


https://docs.fd.io/csit/rls1704/report/test_operational_data/vpp_performance_operational_data/index.html

And for those addicted to numbers and stats - here total numbers of VPP 
tests per type in CSIT rls1704:

- 360 of performance non-drop-rate discovery tests.
- 319 of performance partial-drop-rate discovery tests.
- 258 of system functional VIRL tests for VPP.
- executed on-demand, per patch, nightly and semi-weekly depending on 
category and requirements.

Please send your feedback and comments by email to csit-...@lists.fd.io.

-Maciek (CSIT PTL)
On behalf of FD.io CSIT project.

P.S. All test data in the report incl. graphs and tables are auto-
generated by CSIT scripts. CSIT project team did their best to ensure
the scripts are bug free and content is pleasant to human reading eye,
but as content generated by test executors is dynamic some errors are
very likely. If you see any formatting issues or data inconsistencies,
please report them by email to csit-...@lists.fd.io, so that errors can
be corrected.
___
discuss mailing list
disc...@lists.fd.io
https://lists.fd.io/mailman/listinfo/discuss

___
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-04-28 Thread Ni, Hongjun 
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 
the openflow NSH flows in the compute node?
[Hongjun] Yes, can get NSP and NSI from packet's NSH header, when receiving a 
NSH packet.

What about the address '90e2.ba48.7a80'? Is this hardware address of 
TenGigabitEthernet5/0/0?
[Hongjun] Yes. It is MAC address of interface.

Regards,
Srikanth.

From: Ni, Hongjun [mailto:hongjun...@intel.com]
Sent: Friday, April 28, 2017 11:19 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 use VPP and NSH_SFC project for running SFF, not running vxlan_tool.py.

Below is the commands used to configure your setup for running SFF, just for 
reference.
vppctl set int state TenGigabitEthernet5/0/0 up
vppctl set int ip table TenGigabitEthernet5/0/0 7
vppctl set int ip address TenGigabitEthernet5/0/0 10.10.10.3/24
vppctl ip route add 192.168.2.25/32 via 10.10.10.3 TenGigabitEthernet5/0/0
vppctl set ip arp fib-id 7 TenGigabitEthernet5/0/0 192.168.2.25 90e2.ba48.7a80

vppctl create vxlan-gpe tunnel local 10.10.10.3 remote 192.168.2.25 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 185 nsi 255 mapped-nsp 185 mapped-nsi 254 nsh_action 
swap encap-vxlan-gpe-intf 3

vppctl create nsh entry nsp 185 nsi 255 md-type 1 c1 1 c2 2 c3 3 c4 4 
next-ethernet
vppctl create nsh entry nsp 185 nsi 254 md-type 1 c1 11 c2 12 c3 13 c4 14 
next-ethernet


Yes, local 10.10.10.3 remote 192.168.2.25 is the local and peer tunnel endpoint 
IP.

Fib table is a VRF(Virtual Routing Forwarding) table. Default Fib table is 0.


From: Srikanth Lingala [mailto:srikanth.ling...@nxp.com]
Sent: Friday, April 28, 2017 1:56 AM
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

+ vpp-dev

Hi Hongjun,
Thanks for the info.
My requirement is that, I am spawning a SFC vNF which is VPP based. So, that 
vNF should be IP-less NSH aware.
My typical setup is as shown in the attached image. I have single Compute Node, 
with 2 vNFs in a Chain. One vNF is NSH aware (running vxlan_tool.py), and 
another vNF is VPP based VM, which is IP-less, as its interface is hooked to 
DPDK. As I am new to FD.io/ VPP, can you please relate the commands you sent to 
my setup? I may not need the entire commands...Isn't it?

Anyways, In the commands you sent, I have some doubts.

What are the IP's 192.168.50.71 and 192.168.50.76, those are tunnel endpoint 
IP's right?
What is fib-id 7?

Can you please filter out the particular commands to configure my setup?

Regards,
Srikanth.

From: Ni, Hongjun [mailto:hongjun...@intel.com]
Sent: Tuesday, April 25, 2017 9:44 AM
To: Srikanth Lingala 
>; Yang, Yi Y 
>
Cc: nsh_sfc-...@lists.fd.io
Subject: RE: Regarding vxlan_tool.py in SFC vNF

Hi Srikanth,

If you install nsh_plugin, you may use NSH_SFC 17.01 release, which did not 
support NSH-aware SNAT.

For NSH_SFC 17.01 release, you can configure as blow to act as a SFF, which can 
forward NSH packets.

Below configuration script is for reference:

-NSH 
SFF
vppctl set int state TenGigabitEthernet5/0/0 up
vppctl set int ip table TenGigabitEthernet5/0/0 7
vppctl set int ip address TenGigabitEthernet5/0/0 192.168.50.76/24
vppctl ip route add 192.168.50.71/32 via 192.168.50.76 TenGigabitEthernet5/0/0
vppctl ip route add 192.168.50.72/32 via 192.168.50.76 TenGigabitEthernet5/0/0
vppctl set ip arp fib-id 7 TenGigabitEthernet5/0/0 192.168.50.71 90e2.ba48.7a80
vppctl set ip arp fib-id 7 TenGigabitEthernet5/0/0 192.168.50.72 0800.2761.0705

vppctl create vxlan-gpe tunnel local 192.168.50.76 remote 192.168.50.71 vni 9 
next-nsh encap-vrf-id 7 decap-vrf-id 7
vppctl set int l2 bridge vxlan_gpe_tunnel0 1 1
vppctl create vxlan-gpe tunnel local 192.168.50.76 remote 192.168.50.72 vni 9 
next-nsh encap-vrf-id 7 decap-vrf-id 7
vppctl set int l2 bridge vxlan_gpe_tunnel1 1 1

vppctl create nsh map nsp 185 nsi 255 mapped-nsp