Ferruh Yigit 1bb4a528c4 ethdev: fix max Rx packet length
There is a confusion on setting max Rx packet length, this patch aims to
clarify it.

'rte_eth_dev_configure()' API accepts max Rx packet size via
'uint32_t max_rx_pkt_len' field of the config struct 'struct
rte_eth_conf'.

Also 'rte_eth_dev_set_mtu()' API can be used to set the MTU, and result
stored into '(struct rte_eth_dev)->data->mtu'.

These two APIs are related but they work in a disconnected way, they
store the set values in different variables which makes hard to figure
out which one to use, also having two different method for a related
functionality is confusing for the users.

Other issues causing confusion is:
* maximum transmission unit (MTU) is payload of the Ethernet frame. And
  'max_rx_pkt_len' is the size of the Ethernet frame. Difference is
  Ethernet frame overhead, and this overhead may be different from
  device to device based on what device supports, like VLAN and QinQ.
* 'max_rx_pkt_len' is only valid when application requested jumbo frame,
  which adds additional confusion and some APIs and PMDs already
  discards this documented behavior.
* For the jumbo frame enabled case, 'max_rx_pkt_len' is an mandatory
  field, this adds configuration complexity for application.

As solution, both APIs gets MTU as parameter, and both saves the result
in same variable '(struct rte_eth_dev)->data->mtu'. For this
'max_rx_pkt_len' updated as 'mtu', and it is always valid independent
from jumbo frame.

For 'rte_eth_dev_configure()', 'dev->data->dev_conf.rxmode.mtu' is user
request and it should be used only within configure function and result
should be stored to '(struct rte_eth_dev)->data->mtu'. After that point
both application and PMD uses MTU from this variable.

When application doesn't provide an MTU during 'rte_eth_dev_configure()'
default 'RTE_ETHER_MTU' value is used.

Additional clarification done on scattered Rx configuration, in
relation to MTU and Rx buffer size.
MTU is used to configure the device for physical Rx/Tx size limitation,
Rx buffer is where to store Rx packets, many PMDs use mbuf data buffer
size as Rx buffer size.
PMDs compare MTU against Rx buffer size to decide enabling scattered Rx
or not. If scattered Rx is not supported by device, MTU bigger than Rx
buffer size should fail.

Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
Acked-by: Somnath Kotur <somnath.kotur@broadcom.com>
Acked-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
Acked-by: Rosen Xu <rosen.xu@intel.com>
Acked-by: Hyong Youb Kim <hyonkim@cisco.com>
2021-10-18 19:20:20 +02:00

170 lines
5.2 KiB
ReStructuredText

.. SPDX-License-Identifier: BSD-3-Clause
Copyright(c) 2015 Intel Corporation.
Basic Forwarding Sample Application
===================================
The Basic Forwarding sample application is a simple *skeleton* example of a
forwarding application.
It is intended as a demonstration of the basic components of a DPDK forwarding
application. For more detailed implementations see the L2 and L3 forwarding
sample applications.
Compiling the Application
-------------------------
To compile the sample application see :doc:`compiling`.
The application is located in the ``skeleton`` sub-directory.
Running the Application
-----------------------
To run the example in a ``linux`` environment:
.. code-block:: console
./<build_dir>/examples/dpdk-skeleton -l 1 -n 4
Refer to *DPDK Getting Started Guide* for general information on running
applications and the Environment Abstraction Layer (EAL) options.
Explanation
-----------
The following sections provide an explanation of the main components of the
code.
All DPDK library functions used in the sample code are prefixed with ``rte_``
and are explained in detail in the *DPDK API Documentation*.
The Main Function
~~~~~~~~~~~~~~~~~
The ``main()`` function performs the initialization and calls the execution
threads for each lcore.
The first task is to initialize the Environment Abstraction Layer (EAL). The
``argc`` and ``argv`` arguments are provided to the ``rte_eal_init()``
function. The value returned is the number of parsed arguments:
.. literalinclude:: ../../../examples/skeleton/basicfwd.c
:language: c
:start-after: Initializion the Environment Abstraction Layer (EAL). 8<
:end-before: >8 End of initializion the Environment Abstraction Layer (EAL).
:dedent: 1
The ``main()`` also allocates a mempool to hold the mbufs (Message Buffers)
used by the application:
.. literalinclude:: ../../../examples/skeleton/basicfwd.c
:language: c
:start-after: Allocates mempool to hold the mbufs. 8<
:end-before: >8 End of allocating mempool to hold mbuf.
:dedent: 1
Mbufs are the packet buffer structure used by DPDK. They are explained in
detail in the "Mbuf Library" section of the *DPDK Programmer's Guide*.
The ``main()`` function also initializes all the ports using the user defined
``port_init()`` function which is explained in the next section:
.. literalinclude:: ../../../examples/skeleton/basicfwd.c
:language: c
:start-after: Initializing all ports. 8<
:end-before: >8 End of initializing all ports.
:dedent: 1
Once the initialization is complete, the application is ready to launch a
function on an lcore. In this example ``lcore_main()`` is called on a single
lcore.
.. literalinclude:: ../../../examples/skeleton/basicfwd.c
:language: c
:start-after: Called on single lcore. 8<
:end-before: >8 End of called on single lcore.
:dedent: 1
The ``lcore_main()`` function is explained below.
The Port Initialization Function
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The main functional part of the port initialization used in the Basic
Forwarding application is shown below:
.. literalinclude:: ../../../examples/skeleton/basicfwd.c
:language: c
:start-after: Main functional part of port initialization. 8<
:end-before: >8 End of main functional part of port initialization.
The Ethernet ports are configured with default settings using the
``rte_eth_dev_configure()`` function.
For this example the ports are set up with 1 RX and 1 TX queue using the
``rte_eth_rx_queue_setup()`` and ``rte_eth_tx_queue_setup()`` functions.
The Ethernet port is then started:
.. literalinclude:: ../../../examples/skeleton/basicfwd.c
:language: c
:start-after: Starting Ethernet port. 8<
:end-before: >8 End of starting of ethernet port.
:dedent: 1
Finally the RX port is set in promiscuous mode:
.. literalinclude:: ../../../examples/skeleton/basicfwd.c
:language: c
:start-after: Enable RX in promiscuous mode for the Ethernet device.
:end-before: End of setting RX port in promiscuous mode.
:dedent: 1
The Lcores Main
~~~~~~~~~~~~~~~
As we saw above the ``main()`` function calls an application function on the
available lcores. For the Basic Forwarding application the lcore function
looks like the following:
.. literalinclude:: ../../../examples/skeleton/basicfwd.c
:language: c
:start-after: Basic forwarding application lcore. 8<
:end-before: >8 End Basic forwarding application lcore.
The main work of the application is done within the loop:
.. literalinclude:: ../../../examples/skeleton/basicfwd.c
:language: c
:start-after: Main work of application loop. 8<
:end-before: >8 End of loop.
:dedent: 1
Packets are received in bursts on the RX ports and transmitted in bursts on
the TX ports. The ports are grouped in pairs with a simple mapping scheme
using the an XOR on the port number::
0 -> 1
1 -> 0
2 -> 3
3 -> 2
etc.
The ``rte_eth_tx_burst()`` function frees the memory buffers of packets that
are transmitted. If packets fail to transmit, ``(nb_tx < nb_rx)``, then they
must be freed explicitly using ``rte_pktmbuf_free()``.
The forwarding loop can be interrupted and the application closed using
``Ctrl-C``.