| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Improve PROX generator performance by pre-calculating bytes_to_tsc.
This improvement is only implemented for non-pcap
generator, where only few different packet sizes are usually generated.
This change might have a negative performance impact in some cases, if
many different packet sizes are generated, resulting in higher memory usage.
This is the case for instance if random is applied to packet size.
In addition, simplified the rx path, receiving now only MAX_PKT_BURST packets
per handle loop.
Before we were trying to empty the NIC looping on RX packets, ending up
with many rx packets per handle loop. This was used to determine an lower bound
for the time the packet was received.
We now set the lower bound when less than MAX_PKT_BURST has been received.
Change-Id: I1ce813d7e4ac1577ea412c590add5d6f94b36ec7
Signed-off-by: Xavier Simonart <xavier.simonart@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>
|
|
In some (rare) modes, more than 64 packets can be received through
one rx function. This is for instance the case of the lat mode.
Change-Id: Ie733c927a8e116c679c464f2551768185ef85366
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
There were two issues identified in dump receive packets
- when the receive packets was going to be dropped (and not transmitted),
it was also printed as TX[255].
- a potential crash when using the dump function with modes like
lat which can receive more than MAX_RING_BURST.
Those issues have been fixed.
Change-Id: Ia2297539d64961a211389d68e3c9c6280472243c
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
PROX can stack different RX functions, so that they are executed
after each other.
This feature is for instance used to dump packets or to print
distribution of receive packets, without influencing the performance
of the rx functions when no dump or print is needed.
The previous implementation was wrong and causing some of the stacked
functions not to be executed. This was causing for instance issues
in latency measurement after enabling dumping packets.
Change-Id: I766b8ee8e8852fa17cdaf60ee6e1fec0dc98c719
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