| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Following messages are now handled by PROX
- router_solicitation
- neighbour_solicitation
- router_advertisement
- neighbour_advertisement
The following parameters are supported (through the PROX config file)
- sub mode=ndp
This will enable handling of router and neighbour solicitation
and advertisement.
- local ipv6=xxxx:xxxx:xxxxx:xxxx:xxxx:xxxx:xxxx:xxxx
This will configure the local IPv6 address of the port.
This parameter is optional. If not specified, the local IPv6
will be calculated from the EUI.
- global ipv6=xxxx:xxxx:xxxxx:xxxx:xxxx:xxxx:xxxx:xxxx
This will configure the global IPv6 address of the port.
This parameter is optional. If not specified, the global IPv6
will be calculated from the EUI and the router prefix received
from the router.
- ipv6 router=yes
This will cause the core to behave as an IPv6 router
i.e. it will generate Router Advertisement messages
This is only useful in back to back cases, when no real
IPv6 router is present in the setup.
- router prefix=xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx
The router prefix usedin the router advertisement
The prefix will be used by the node to build an IPv6 global
address in cases none were configured.
"Unsollicited NA" parameter has been added within the core/task section.
If set to yes (Unsollicited NA=yes), then an unsollicited neighbour
Advertisement is sent at startup
A same core/task cannot support both l3 and ndp mode.
Those messages will be generated or handled when submode
is set to "ndp":
- neighbour sollicitation
- neighbour advertisement
- router sollicitation
- router advertisement
An example configuration is provided: config/ipv6.cfg in which
port 0 / core 1 plays the role of the generator and port 1 /
core 2 plays the role of the swap.
Change-Id: Id0ab32d384448b4cf767fb4a1c486fc023f4f395
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
In Prox configuration IMIX can be specified using the following syntax:
imix=pkt_size,pkt_size... Up to 127 different pkt sizes can be specified.
Through command line, the following syntax can be used
imix core_id task_id pkt_size,pkt_size... Up to 127 packet sizes can be specified.
When IMIX is enabled, PROX will loop through the list of packet sizes.
PROX supports two different submodes to handle pcap files.
In the 1st submode (default, no submode specified), timestamps from
the pcap file are ignored. In this submode IMIX is supported as well and each
packets in the pcap file will be generated with all IMIX sizes.
In the second submode, called pcap in gen mode, packets are generated at
the timestamp specified in the pcap file. This submode does not support IMIX.
Change-Id: I53cbf1378a5364254285b81e6848350d98561184
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
lat all stats <core_id> <task_id> combines "lat stats" and "lat packets" within one command.
This command returns:
- One line in case the core_task parser fails. In that case the line will start with: "error: invalid syntax"
- One set of lines for each core task:
- if core/task is invalid, or not running lat mode, the line will contain (start with) "error...". this will be the only line for that core/task.
- Otherwise the set of lines will be:
- One line as returned by "lat stats". This line will be
- One line starting with "error" in case of error, or
- One line containing lat_min_usec, lat_max_usec, lat_avg_usec, tot_lat_min_usec, tot_lat_max_usec, last_tsc, rte_get_tsc_hz(), lcore_id, task_id
- The return from lat packets i.e.
- One line starting with "error" in case of error, or
- 128 lines - one for each bucket - as returned by "lat packets" command
This command is more useful then lat packets, as it contains the tsc - needed to see whether the sample is new or not.
Change-Id: I04231aa7c5bd2d352ed6f94d40e88d3b411ce744
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
- Latency Distribution (i.e. histograms) has been added when latency is enabled.
- Histograms are now compiled by default.
- A bug has also been fixed, which was causing strange behavior in the histograms
(due to bucket size being overwritten).
- The default bucket size has been changed to "11" which means that the size of each bucket
is now (1 cycle << 11) = 2048 cycles = 1 microsecond at 2GHz. It was (1 << (10 - 1)).
As there are 128 latency buckets, it is not possible to show all of them on the display.
Hence the latency buckets are displayed based on on the assumption that the minimum latency is usually relatively
stable and that the maximum latency change more often.
- The first empty buckets are not shown (i.e. buckets empty for all tasks)
- If more than 15 buckets are non empty, then the buckets are combined, so that a maximum of
15 (bigger) buckets are shown
- If less than 15 buckets are non empty, the following (empty) buckets are shown
(this avoid seeing every x seconds some columns being added and removed).
Change-Id: I27fe6ac0e513a5558e42ff2e74255c55ba79516d
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
This commit prepares PROX for supporting changes from DPDK 19.08
Mainly, the "sed" listed below were run.
In addition,
- some forward definition have been removed,
- prox_compat.h has been updated
- prox_compat.h has been included where necessary.
Hence such a commit is rather easy to review and to reapply
on other branches if necessary.
sed -i 's/struct ether_hdr/prox_rte_ether_hdr/g' *.h
sed -i 's/struct ether_hdr/prox_rte_ether_hdr/g' *.c
sed -i 's/struct ether_addr/prox_rte_ether_addr/g' *.c
sed -i 's/struct ether_addr/prox_rte_ether_addr/g' *.h
sed -i 's/prox_rte_ether_addr_port/struct ether_addr_port/g' *.c
sed -i 's/prox_rte_ether_addr_port/struct ether_addr_port/g' *.h
sed -i 's/struct vlan_hdr/prox_rte_vlan_hdr/g' *.c
sed -i 's/struct vlan_hdr/prox_rte_vlan_hdr/g' *.h
sed -i 's/struct ipv4_hdr/prox_rte_ipv4_hdr/g' *.h
sed -i 's/struct ipv4_hdr/prox_rte_ipv4_hdr/g' *.c
sed -i 's/struct ipv6_hdr/prox_rte_ipv6_hdr/g' *.c
sed -i 's/struct ipv6_hdr/prox_rte_ipv6_hdr/g' *.h
sed -i 's/struct udp_hdr/prox_rte_udp_hdr/g' *.c
sed -i 's/struct udp_hdr/prox_rte_udp_hdr/g' *.h
sed -i 's/struct tcp_hdr/prox_rte_tcp_hdr/g' *.c
sed -i 's/struct tcp_hdr/prox_rte_tcp_hdr/g' *.h
sed -i 's/struct prox_rte_ether_addr_copy/ether_addr_copy/g' *.c
sed -i 's/struct prox_rte_ether_addr_copy/ether_addr_copy/g' *.h
sed -i 's/struct prox_rte_ether_addr_copy/prox_rte_ether_addr_copy/g' *.c
sed -i 's/struct prox_rte_ether_addr_copy/ether_addr_copy/g' *.h
sed -i 's/prox_rte_ether_addr_copy/ether_addr_copy/g' *.h
sed -i 's/prox_rte_ether_addr_copy/ether_addr_copy/g' *.c
sed -i 's/ether_addr_copy/prox_rte_ether_addr_copy/g' *.c
sed -i 's/ether_addr_copy/prox_rte_ether_addr_copy/g' *.h
sed -i 's/prox_rte_ether_hdr_arp/struct ether_hdr_arp/g' *.h
sed -i 's/prox_rte_ether_hdr_arp/struct ether_hdr_arp/g' *.c
sed -i 's/struct vxlan_gpe_hdr/prox_rte_vxlan_gpe_hdr/g' *.h
sed -i 's/struct vxlan_gpe_hdr/prox_rte_vxlan_gpe_hdr/g' *.c
sed -i 's/eth_random_addr/prox_rte_eth_random_addr/g' *.c
sed -i 's/eth_random_addr/prox_rte_eth_random_addr/g' *.h
sed -i 's/ETHER_CRC_LEN/PROX_RTE_ETHER_CRC_LEN/g' *.c
sed -i 's/ETHER_CRC_LEN/PROX_RTE_ETHER_CRC_LEN/g' *.h
sed -i 's/ETHER_HDR_LEN/PROX_RTE_ETHER_HDR_LEN/g' *.c
sed -i 's/ETHER_HDR_LEN/PROX_RTE_ETHER_HDR_LEN/g' *.h
sed -i 's/ETHER_MAX_LEN/PROX_RTE_ETHER_MAX_LEN/g' *.c
sed -i 's/ETHER_MAX_LEN/PROX_RTE_ETHER_MAX_LEN/g' *.h
sed -i 's/ETHER_MIN_LEN/PROX_RTE_ETHER_MIN_LEN/g' *.c
sed -i 's/ETHER_MIN_LEN/PROX_RTE_ETHER_MIN_LEN/g' *.h
sed -i 's/TCP_SYN_FLAG/PROX_RTE_TCP_SYN_FLAG/g' *.c
sed -i 's/TCP_RST_FLAG/PROX_RTE_TCP_RST_FLAG/g' *.c
sed -i 's/TCP_FIN_FLAG/PROX_RTE_TCP_FIN_FLAG/g' *.c
sed -i 's/TCP_ACK_FLAG/PROX_RTE_TCP_ACK_FLAG/g' *.c
Change-Id: I4dfe8be68e618c94dcaae28754579fbeb571bb00
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
- When using "pcap file" argument in PROX config file in the gen mode
(and no submode), packets were truncated to 8 bytes (and a warning printed)
This has been fixed.
- "Set value" command was checking whether offset was within first 1518 bytes
unrespective to the mtu (e.g. jumbo packets). This has been fixed.
- There was a limit of 64K packets loaded from a pcap file (which could be
overwritten through PROX config). This limit has been removed - by default
all packets from pcap are loaded
- When pcap was loaded, memory was allocated to store the packet. However
just enough memory was allocated, so that there was no way to change (increase)
packet size through command line after that. Now memory is allocated to store
up to mtu size
- While "set value" command was acting on all packets, "pkt size" command
was only changing the first packet. This has now been changed and both commands
change all the packets.
- A few other minor cleanups.
Change-Id: I7264cee8d57e3e6a405dfd7e7a52a95b99399d99
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
Change-Id: I833d753bd5c426d50c0c9fdee5668f3b9fff13b9
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
Multicast can be enabled through configuration or through command line
- Through configuration
Add multicast=mcast_address (e.g. multicast=01:00:5e:01:02:03) in the port
section
- Through command line
run enable multicast port_id mcast_address (e.g. enable multicast 1 01:00:5e:01:02:03)
IGMP join message is sent unsollicited through command line:
join igmp core_id task_id ip (e.g. join igmp 1 0 224.1.1.3)
To enable swap answering IGMP Query (w/ IGMP Join)
- Through configuration
Add igmp ipv4=ip_address within the core/task section
- Through command line
join igmp core_id task_id ip (e.g. join igmp 1 0 224.1.1.3)
(this will 1st initiate an unsollicated join, then answer any subsequent query)
UDP/TCP packets received on a multicast address (224.0.0.0 => 239.255.255.255) are discarded
To stop sending responses to IGMP query:
leave igmp core_id task_id
Change-Id: I3808ccabf3b38b5a1e10e1b044db63aa05bcd7b5
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
This is required for instance on gcc (GCC) 8.2.1 20180905
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
Change-Id: Id86de5d39d77c5cbf168cc51434f436f84376a4c
|
|
Change-Id: Ifb55091feedb28ffc5947ffe61e6f6a5ce034459
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
Change-Id: Iaae603a7558666b5794ec4c76f447eb3260a1df9
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
Signed-off-by: Patrice Buriez <patrice.buriez@intel.com>
|
|
Similar support and comments as for "dp core stats" command
Change-Id: I215fc57c292fbc1f12a3fe95d40a0a80c29b714a
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
Signed-off-by: Patrice Buriez <patrice.buriez@intel.com>
|
|
The "dp core stats" command supported, as other commands, multiple cores
but not multiple tasks. It now supports both (e.g. dp core stats 1-2 0-1).
This is necessary so that users can collect all statistics from PROX in one
command line.
It will return similar information on the screen or through the socket:
- if the syntax is wrong (e.g. missing task, too many cores or tasks, ...)
=> an error message is printed on the screen, and the single error line
"error: invalid syntax" is returned through the socket
- if the syntax is correct
=> one line is printed or returned for each core/task pair
=> if the core/task pair is invalid, the line reports an error
=> otherwise, the line provides dataplane statistics for the core/task pair,
with the core_id and task_id added, either at the end of the line returned
through the socket, or at the beginning of the line printed on the screen.
This means a change in behaviour when using the socket: before, when an error
happened (e.g. bad task), then nothing was returned which made it difficult for
the script to catch the syntax error.
Similar behaviour could/should be implemented for other commands.
However, care must be taken as some scripts like NSB might count the number
of lines within the output, or the number of items within the line.
This should not be an issue for dp core stats as NSB does not use it, and other
PROX scripts do not count the number of items and will be adjusted to count the
number of lines.
Change-Id: I582a671ae3d2f6493f791e80fc28e70f8e3a38d1
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
Signed-off-by: Patrice Buriez <patrice.buriez@intel.com>
|
|
and rename parse_core_task() to parse_cores_task()
Change-Id: I256dfb8d02520a70d65d6623feddcc9037938501
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
Signed-off-by: Patrice Buriez <patrice.buriez@intel.com>
|
|
Warning:
This change breaks backward-compatibility of PROX socket scripting API,
because the "total TX fail" count is reported before the "last TSC"
field.
As a result, PROX scripts that make use of the "dp core stats" command,
such as the core_stats() method in helper-scripts/openstackrapid/prox_ctrl.py,
MUST be reworked to correctly parse the returned set of fields.
Change-Id: I3fe7f37dccee19f5f0b2719f262c6cfa7bad850f
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
Signed-off-by: Patrice Buriez <patrice.buriez@intel.com>
|
|
by means of calling core_task_is_valid()
Change-Id: Ice64aabc84066633288ff43d4dc9af3f5b378e33
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
Signed-off-by: Patrice Buriez <patrice.buriez@intel.com>
|
|
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>
|
|
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>
|
|
|
|
When doing latency measurements PROX takes into account the
generation or reception of a bulk of packets. For instance, if
PROX receives at time T 4 packets, it knows that the first
packet was received by te NIC before T (the time to receive the other
3 packets, as they were received at maximum link speed).
So the latency data is decreased by the minimum time to receive those
3 packets.
For this PROX was using a default link speed of 10Gbps. This is wrong
for 1Gbps and 40Gbps networks, and was causing for instance issues
on 40 Gbps networks as extrapolating too much, resulting in either
too low latencies or negative numbers (visible as very high latencies).
Change-Id: I4e0f02e8383dd8d168ac50ecae37a05510ad08bc
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
irq mode can be used to show how a core is interrupted by other tasks.
This mode does not handle packets. It only loops reading tsc.
When the difference between two consecutive calls to rdtsc() is high
then it means the core was interrupted.
This task implementes the display, so that we can see a histogram of
interrupts as well as the maximum, per core.
Command line is also supported, through "show irq buckets" (too show
the intervals of each buckets, in micrcoseconds), and the stats
command line (showing the number of items in each buckets and the max)..
Change-Id: I153cc3deaa7b86ae2776ea44e46ef9ecfd116992
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
Command parser could have been crashing if a wrong core/task was
used in pkt_size command. For some other commands both an error
and a warning were printed in case of errors.
Change-Id: I6648bfca1b5bcde3c6393d49687ed84900326d49
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
The l3 submode was not supported in nop mode, as the nop mode uses some
specific nop thread (and not generic). When L3 is specified, the nop mode
must use the generic thread. In addition the l3 submode is implemented
differently than other submodes. It is not supported through task_init
structures (i.e. each task does not have to explicitely tell that it
supports l3 submode). But this prevented to run both a nop with no submode
and a nop with a l3 submode. Note that nop with l3 is usually not very useful
- it handles arp (requests and response) but as nop, it does not swap IP
addresses. So with a real switch, the packets transmitted will be received
back... and l3 mode is usually mainly usefull when using a switch.
However, there is at least one nop mode where l3 submode makes sense:
when the nop does not transmit. In such cases, for instace used in
conjunction with a gen l3, the nop receives all packets and forward
the arp requests and responses to the master for handling.
Change-Id: I992121db285ba25a11cbb494092a6afc6fe55a58
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
Change-Id: I9c46b57f98b566efc8ca3ea5966befe2a150315b
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
Change-Id: Ie6d4e7ce22c27967117a446626f5923643397812
Signed-off-by: Patrice Buriez <patrice.buriez@intel.com>
|
|
JIRA: SAMPLEVNF-55
PROX is a DPDK-based application implementing Telco use-cases such as
a simplified BRAS/BNG, light-weight AFTR... It also allows configuring
finer grained network functions like QoS, Routing, load-balancing...
(We are moving PROX version v039 to sampleVNF
https://01.org/intel-data-plane-performance-demonstrators/prox-overview)
Change-Id: Ia3cb02cf0e49ac5596e922c197ff7e010293d033
Signed-off-by: Deepak S <deepak.s@linux.intel.com>
|
Xavier Simonart
Patrice Buriez
Deepak S