| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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>
|
|
Add support for pkt_inline of jumbo frames.
Dump the whole packet, and not a truncated packet. This might
have a small impact on performance as the memory footprint
is increased (by ~640K * number of tasks), resulting in potential
higher DTLB misses.
Change-Id: I4ed02be7ca899db4f8f97355c180a92d69d39d8f
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>
|
|
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>
|
|
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: 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