summaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2019-02-07Added use case "Forwaring Rate At Maximum Offered Load"Xavier Simonart2-0/+148
With this use case, the generator is generating at maximum speed We measure the forwarding rate. Throughput, latency, number of packets sent and received are printed every seconds. Change-Id: I05eb874d6ecefd58fb0c876bccf6a32872306076 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2019-02-07Merge "Fix memory leak in L3 submode"Deepak S2-1/+3
2019-02-07Merge changes from topic 'fix_non_dataplane_pkt_count'Deepak S6-14/+53
* changes: Prevent dropping ARP packets Do not add count of non dataplane packets to dropped count
2019-02-07Merge "Add support for configurable arp timers in L3 mode"Deepak S4-7/+26
2019-01-30Fix memory leak in L3 submodeXavier Simonart2-1/+3
In L3 submodes, there were two memory leaks - when a L3 core was restarted, causing around 2MB leak and a potential issue after 256 start/stop - a potential mbuf leak when handling arp replies Those have been fixed Change-Id: I348478fa5967936297850432e93667e12b0adac4 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2019-01-28Add support for configurable arp timers in L3 modeXavier Simonart4-7/+26
L3 mode supports two timers: - arp_update_time, defaulted to 1 second, which makes PROX to send arp request every second for active flows - arp_timeout, previously defaulted to 30 seconds, which makes PROX consider a MAC address as invalid if no arp_reply was received within those 30 seconds. Those timers values were hardcoded. They can now be configured through the configuration file (within the core section), using resp. "arp update time" and "arp timeout" keywords. Unit is milli seconds. The default becomes respectively 1 second and 2 weeks. Change-Id: I35e46e97df32ca44c2cdfae85a20ee015de5d6e1 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2019-01-23Configure RSS hashing to IP/UDP and check for with PMD supportXavier Simonart1-2/+9
RSS was enabled when rss=yes is set in the configuration or when multiqueue is being used. But when RSS was enabled the types of packets on which RSS hashing was applied might not be supported by the PMD, as almost every PMD supported a different set of packets. Change-Id: I1d9516da61df7ef18c1d6953879ee15e33fca077 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2019-01-23Clean up port initializationXavier Simonart1-77/+68
Change-Id: Ia9df816d522e5db460d9129109525d5d345d997f Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2019-01-07Improved image build & packet loss measurementsLuc Provoost22-84/+139
Reworked deploycentos1.sh and deploycentos2.sh which is installing a PROX version that deals with non data plane packet counting for improved packet loss measurements. Fixed some issues with the packer scripts. Change-Id: I64aab09d364ab5abbbc5fc75c73afcbe11fed681 Signed-off-by: Luc Provoost <luc.provoost@intel.com>
2019-01-03Prevent dropping ARP packetsXavier Simonart5-13/+47
JIRA: SAMPLEVNF-152 When system is overloaded, ARP packets were sometimes dropped, as any other packets. This was causing two issues: - The count of TX non dataplane packets was wrong - If many consecutive ARP packets were dropped, the underlying switch might see its ARP timer expiring, causing performance degradation (packets being broadcasted). ARP packets are now always sent as no-drop. Change-Id: I9a86cbf8c4b56a178f86bc789153f1fa49ddf73f Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2018-12-20Do not add count of non dataplane packets to dropped countXavier Simonart1-1/+6
RX packets count = TX count + dropped (handled + discarded) count + non dataplane packets count. Hence non dataplane packets such as unexpected packets (e.g. dhcp request) should not b considerded as handled. Change-Id: I45cef19fed09bb4f86644d56d689a0959a9038db Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2018-12-18Merge "Fix handing configuration error (missing tx port or ring in gen mode)"Deepak S1-1/+2
2018-12-18Merge changes from topic 'fix_multiple_arp_issues'Deepak S6-47/+152
* changes: Fix arp handling when master core is on socket 1 Add support for zero packet loss in PROX L3 mode. Fix issue in l3 mode when no arp reply was received Clean up debugging messages
2018-12-14Fix handing configuration error (missing tx port or ring in gen mode)Xavier Simonart1-1/+2
Gen mode requires a tx ring or a tx port. A configuration without those should gracefully report an error. This was causing a crash. Change-Id: Ia30d4d4c87a694da1dfed86587f90b9199c493ab Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2018-12-14Gambia 7.1 release notes updateDeepak S1-6/+6
Change-Id: I145c87b0c18565da479ecaa08e5ffce91232a7ce Signed-off-by: Deepak S <deepak.s@linux.intel.com>
2018-12-13Fix arp handling when master core is on socket 1Xavier Simonart1-1/+1
When master core was on socket 1, the rings setup to exchange messages related to arp between dataplane cores and master core was not properly setup, resulting in arp not working. Change-Id: Icc08df81f2e39e53de7c212248cdc7b78d7e2618 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2018-12-13Add support for zero packet loss in PROX L3 mode.Xavier Simonart3-24/+109
In L3 mode, prox is extracting IP destination address in the packets. It uses this destination address to find the MAC address. If the MAC address is not found, it sends a ARP request. It also sends ARP request when it realizes that some timeout expired. However, PROX was using the mbuf of the existing packets (to be forwarded) to send the ARP. This resulted in packet loss. Now PROX is generating ARP requests using mbuf from an ARP mempool. Some clean up was also done. Change-Id: Icb6083a8cdf88789553ad23c32ca12d6b7ba7f08 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2018-12-13Fix issue in l3 mode when no arp reply was receivedXavier Simonart1-7/+26
When no arp reply was received in l3 mode, the requesting core continuously sends ARP requests every seconds (which is correct). But master core was keeping a list of all requests, while all those requests are the same, resulting in potential table overflow. Change-Id: I13aa1ec4ea88404a690a25678fb6ec72df19a9b9 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2018-12-13Clean up debugging messagesXavier Simonart6-15/+16
Print IP address in a.b.c.d format instead of one 32-bit number. Better align debugging information in log file Change-Id: Icfab30836ba83d53f700fcfbdfbd7cf238ed7bf8 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2018-12-06Merge "Fix potential crash when getting device info"Deepak S1-10/+12
2018-12-06Merge "Add support for VLAN insert and stripping"Deepak S2-0/+19
2018-12-05Add support for VLAN insert and strippingXavier Simonart2-0/+19
JIRA: SAMPLEVNF-149 VLAN can be enabled on a port by adding "vlan=yes" in the port section. When VLAN is enabled on a port, then DEV_RX_OFFLOAD_VLAN_STRIP and DEV_TX_OFFLOAD_VLAN_INSERT are enabled (if device supports it). This will cause VLAN to be stripped from any packets received with the proper tag, and VLAN to be added for any packets being transmitted. The VLAN ID themselves are configured through the physical function using something like (where ens801f1 isthe PF): ip link set ens801f1 vf 0 vlan 1111 Change-Id: I945c87b0c18565da479ecaa08e5ffce91232a7ce Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2018-11-10Add index.rstAric Gardner1-0/+19
We need an index file so that https://opnfv-samplevnf.readthedocs.io/en/latest/ can build Change-Id: I81a98f5264f8ffef0e157610c75f7a172278bcc7 Signed-off-by: Aric Gardner <agardner@linuxfoundation.org>
2018-11-04Fix potential crash when getting device infoXavier Simonart1-10/+12
In some cases, like when using virtual functions, getting device info return a NULL device, which was potentially causing a crash. Change-Id: Icc65f35bb54cd7d9bd8d837b3d6ec7ebb48b7c5e Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2018-11-02Updating release notes for Gambia...Deepak S1-33/+313
Change-Id: Ide712ee94254b506a0ad88c95a7e01b789f00e48 Signed-off-by: Deepak S <deepak.s@linux.intel.com>
2018-11-01Add Gambia release notesDeepak S2-70/+21
Change-Id: Ide712ee94254b506a0ad88c95a7e01b789f99d49 Signed-off-by: Deepak S <deepak.s@linux.intel.com>
2018-10-31Merge "Add support for counting non dataplane related packets"Deepak S8-5/+114
2018-10-31Merge "Fix potential crash when shuffling mbufs"Deepak S1-2/+3
2018-10-31Support for DPDK 18.05 and DPDK 18.08Xavier Simonart22-109/+456
Improve DPDK 18.05 support introduced by 3e532aca. Support for DPDK 18.08. Change-Id: Ide712ee94254b506a0ad88c95a7e01b789f99d48 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2018-10-30Fix potential crash when shuffling mbufsXavier Simonart1-2/+3
Change-Id: I70de6345afc6a696906f006c1b0f44540ae4ecec Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2018-10-28Add support for counting non dataplane related packetsXavier Simonart8-5/+114
When performing some zero packet loss performance testing on dataplane, it is important (not) to count non dataplane packets. For instance, one might receive uexpected packets from a switch, or ARP packets. Or one might need to transmit ARP packets. Such packets should not be counted as dataplane packets as for thse packets there is no 1:1 mapping between transmitted packets and received packets. To support this, the counters reporting numbers of transmitted and received packets remain unchanged but two new counters have been added to PROX, counting respectively number of received and number of transmitted non-dataplane packets. On RX side, packets are counsidered as non-dataplane if being ARP or if they do not countain the proper signature On TX side, ARP packets are not considered as dataplane packets. This feature requires configuration of signature. "dp core stats" command has been added Change-Id: I98e113cd02f36d540383d343a433592867ad86a9 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2018-10-11test improvements and fixes for image creationLuc Provoost13-69/+150
Updated and corrected the creation of an image containing the PROX tool with packer. Test will now only be declared successful when average and maximum latency are below a certain threshold. The start speed is now also a parameter of the *.test files. Change-Id: I1112555c87e7a857e1c699921ae08f61281642e1 Signed-off-by: Luc Provoost <luc.provoost@intel.com>
2018-09-18Local Documentation BuildsAric Gardner5-0/+25
This adds configuration for performing local documentation builds with the following simple command: tox -e docs Change-Id: I84d69542d8c603e72d4af460834134d9711ac537 Signed-off-by: Aric Gardner <agardner@linuxfoundation.org>
2018-09-14Improve l3fwd performanceXavier Simonart1-9/+3
JIRA: SAMPLEVNF-128 Improve performance of l3fwd use-case. L3fwd did not disable TX offload flags, which resulted in non-vector mode to be used in pmd in some cases like bare-metal. Note that in some cases such as virtio, vector mode was already used as OVS reports that it does not support TX-offload, hence TX-offload was already disabled on virtio. Using vector mode usually brings higher performance. Change-Id: I102b846d604a9cf28c6b7dae8bedbe918ccfcf6c Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2018-09-04Workaround DPDK net/virtio queue setup issuePatrice Buriez1-14/+14
JIRA: SAMPLEVNF-127 PROX was crashing in the VM with vector mode enabled and multiple OVS queues. This was not really a PROX bug, but a DPDK issue, which has been fixed by DPDK commit https://git.dpdk.org/dpdk/commit/?id=efc83a1e7fc3 This "net/virtio: fix queue setup consistency" is included in DPDK 17.11 and subsequent versions, and has been backported into: - DPDK 16.11.4: https://git.dpdk.org/dpdk-stable/commit/?h=16.11&id=516447a5056c - DPDK 17.08.1: https://git.dpdk.org/dpdk-stable/commit/?h=17.08&id=907fe4fc263e This means the fix is not included into any DPDK 17.02.x used by NSB. Fortunately, a simple workaround consists of calling rte_eth_tx_queue_setup() before rte_eth_rx_queue_setup(). This change implements this simple workaround, in order to make PROX work, even with unfixed DPDK versions. Change-Id: I818e9bb812babe023c6b7225c8b9769a359d9bec Signed-off-by: Patrice Buriez <patrice.buriez@intel.com>
2018-08-09update from src port in the pvt/pub handlerDeepak S1-12/+9
Change-Id: Iccd72f6ab3db68bc093c42d60d225fe86f8fbda7 Signed-off-by: Deepak S <deepak.s@linux.intel.com>
2018-08-07Enable the local cache mac addressDeepak S1-1/+9
Change-Id: If7d72f6ab3db68bc093c42d60d125fe86f8fbda7 Signed-off-by: Deepak S <deepak.s@linux.intel.com>
2018-07-27Merge "Initial support for DPDK 18.05"Deepak S5-8/+42
2018-07-26Initial support for DPDK 18.05Xavier Simonart5-8/+42
This patch makes PROX compile with DPDK 18.05. However some features are disabled or will not work as expected such as: "mem info" command "police" mode Those will need to be fixed later (see DPDK1805 within code). Change-Id: Ie7d72f6ab3db68bc093c42d60d125fe86f8fbda7 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com> Signed-off-by: Patrice Buriez <patrice.buriez@intel.com>
2018-07-07Fix potential crash with latency accuracyPatrice Buriez1-45/+73
Detect, remember and skip bad/unexpected packets: - too short to hold the latency-related values - with bad signature - with invalid generator_id using a uint64_t-based bitmap. Also moved variable declarations closer to usage, added some likely/unlikely hints, reworked some return statements, and fixed 32-bit overflow (every ~4s) of rx_time_err computation. Change-Id: Ib2aadc1af6b7a68601cc080ba66b10d41ff9a64e Signed-off-by: Patrice Buriez <patrice.buriez@intel.com>
2018-06-29Updating release notes for OPNFV Fraser 6.2Deepak S1-5/+5
Change-Id: I9a9da79cb4ccb245ddb38b50b561da51a40a359d Signed-off-by: Deepak S <deepak.s@linux.intel.com>
2018-06-29Merge "TempFix: vCGNAPT/vACL ipv4 perf issue"Deepak S2-17/+38
2018-06-29Merge "Temp Fix for vFW perf issue"Deepak S4-38/+56
2018-06-17Adding centos.json to be used with packer to generate a VM with PROXLuc Provoost16-84/+328
Based on a CentOS cloud image downloadable from the web, you can now use packer to create an image that has DPDK and PROX installed in the proper directories. The VM is also tuned for guest VNFs. A service is also created to deal with the proper isolated_cpu settings for tuned. The service will also make sure uio and igb_uio are loaded. The prox_user_data.sh is not needed any more and hence deleted. ctrl-c of runrapid.py will now also stop prox in all the VMs so a new test can be started. Change-Id: I16cc59878e2d4912757f42e05f98d51dff5feb89 Signed-off-by: Luc Provoost <luc.provoost@intel.com>
2018-06-12Adding support for Ubuntu 17.10...Deepak S8-9/+8
Change-Id: I9a9da79cb4ccb245ccb38b50b561da51a40a359d Signed-off-by: Deepak S <deepak.s@linux.intel.com>
2018-06-07Get multiple port stats simultaneouslyPatrice Buriez1-0/+44
JIRA: YARDSTICK-1220 Implemented new "multi port stats <port list>" command, which returns a semi-colon-separated list of comma-separated values: - port id - total (at last_tsc) for rx_pkts, tx_pkts, no_mbufs, ierrors + imissed - last_tsc Change-Id: I8a8da79cb4ccb245ccb38b50b561da51a40a359d Signed-off-by: Patrice Buriez <patrice.buriez@intel.com>
2018-06-05TempFix: vCGNAPT/vACL ipv4 perf issueDeepak S2-17/+38
Change-Id: I924fcac7a65c0d221d5d422f419deb9c0f864172 Signed-off-by: Deepak S <deepak.s@linux.intel.com>
2018-06-03Temp Fix for vFW perf issueDeepak S4-38/+56
Change-Id: I324fcac7a65c0d221d5d422f419deb9c0f864172 Signed-off-by: Deepak S <deepak.s@linux.intel.com>
2018-05-25Updating release notes for OPNFV Farser 6.1Deepak S1-7/+13
Change-Id: I333fcac7a65c0d221d5d422f419deb9c0f864172 Signed-off-by: Deepak S <deepak.s@linux.intel.com>
2018-05-25Increase default mbuf size and code simplification/cleanupXavier Simonart18-98/+126
mbuf size was setup to achieve the best performance i.e. using the smallest mbuf and not segmenting packets. However this resulted in complex code, much dependent of the way the pmd are working e.g. a change(fix) in recent dpdk i40e implementation caused a 1782 (=1518+8+256) bytes mbuf to be too small to hold a 1518 bytes packets. Hence this change simplifies the mbuf size selection at the price of a potential decreases in performance - as more memory is now used. Except if jumbo frames are used, the mbuf size will now be the same for all modes. The packets will not be segmented except if jumbo frames are enabled. If jumbo frames are enabled, packets are by default segmented, except if the mbuf size is configured big enough in the config file. Change-Id: I222fcac7a65c0d221d5d422f419deb9c0f864172 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com> Signed-off-by: Deepak S <deepak.s@linux.intel.com>