| 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>
|
|
Jumbo frames are now supported through the addition of a "mtu"
parameter of the port in the config file.
Setting the mtu to a value higher than 1500 bytes will enable
the reception of jumbo frames.
In addition, the rte_eth_dev_set_mtu is now set for all pmds.
Finally, setting mbuf_size does not set MEMPOOL_F_NO_SPREAD
anymore. This option was only used for pure debugging.
Big packets can be received using two ways
- Using multiple "small" mbufs, i.e. around 2K. This is the default.
- Using one big mbuf holding the whole packet. This can be enabled
by setting a parameter mbuf_size in the receiving core configuration
Change-Id: Idd60ad31f41c89f9522dff4d894af2696b7a2ea1
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>
|
|
|
|
L2fwd and swap has many options to set src mac. swap was supposed
to support the ability to use port mac, but config file parsing was
wrong. L2fwd was using port mac if a port was available and if
src mac=packet or if there was no src mac in the config.
Now l2fwd supports the following options
- "src mac=xx:xx:xx:xx:xx:xx" => this mac address is used as src mac.
- "src mac=packet" => the src mac is taken from the dst mac of the
received packet.
- "src mac=hw" => the src mac is taken from the mac address of the port,
if there is a physical port. Error otherwise.
- "src mac=no" => src mac kept untouched
- No "src mac" => same as "src mac=hw" if there is a physical port
and same as "src mac=packet" otherwise.
Default is (no "src mac") hence the mac is taken from the tx port if there
is one tx port and from the packet otherwise.
swap support is similar, except that it does not support "src mac=no".
Change-Id: I70fe49a61c2e85772288b769ede14a7a6205d122
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
Change-Id: I5611ead4b61b23d6c1c983852e8c75619e08ecf9
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>
|
|
Change-Id: I389389e5317d1a9d0d79cc1762d6f15d8287e36a
Signed-off-by: Alexander Komarov <alexander.komarov@intel.com>
Signed-off-by: Alexander Komarov <izard.ak@gmail.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
Deepak S
Patrice Buriez
Alexander Komarov