doc: reword some sample app guides

I have reviewed these sections for grammar/clarity
and made small modifications to the formatting of sections
to adhere to a template which will create uniformalit

doc: reword some sample app guides

I have reviewed these sections for grammar/clarity
and made small modifications to the formatting of sections
to adhere to a template which will create uniformality
in the sample application user guides overall.

Signed-off-by: Nandini Persad <nandinipersad361@gmail.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>

show more ...

examples/l3fwd-graph: introduce mcore dispatch worker model

Add new parameter "model" to choose mcore dispatch or rtc model.
And in dispatch model, the node will affinity to worker core successively

examples/l3fwd-graph: introduce mcore dispatch worker model

Add new parameter "model" to choose mcore dispatch or rtc model.
And in dispatch model, the node will affinity to worker core successively.

RTE_GRAPH_MODEL_SELECT is set to RTE_GRAPH_MODEL_RTC by default. Must set
model the same as RTE_GRAPH_MODEL_SELECT if set it as rtc or mcore
dispatch explicitly. If not define it, it could choose by param model
in runtime.
Only support one RX node for mcore dispatch model in current
implementation.

./dpdk-l3fwd-graph -l 1,2,3,4 -n 4 -- -p 0x1 --config="(0,0,1)" -P
--model="dispatch"

Signed-off-by: Haiyue Wang <haiyue.wang@intel.com>
Signed-off-by: Cunming Liang <cunming.liang@intel.com>
Signed-off-by: Zhirun Yan <zhirun.yan@intel.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>
Acked-by: Pavan Nikhilesh <pbhagavatula@marvell.com>

show more ...

examples/l3fwd-graph: add IPv6 lookup and rewrite

Similar to IPv4, to support IPv6 lookup and rewrite node
routes and rewrite data needs to be added.

Patch adds routes for IPv6 to validate ip6_look

examples/l3fwd-graph: add IPv6 lookup and rewrite

Similar to IPv4, to support IPv6 lookup and rewrite node
routes and rewrite data needs to be added.

Patch adds routes for IPv6 to validate ip6_lookup node
and rewrite data to validate ip6_rewrite node.

Signed-off-by: Sunil Kumar Kori <skori@marvell.com>
Signed-off-by: Amit Prakash Shukla <amitprakashs@marvell.com>
Acked-by: Nithin Dabilpuram <ndabilpuram@marvell.com>

show more ...

graph: pcap capture for graph nodes

Implementation adds support to capture packets at each node with
packet metadata and node name.
The l3fwd-graph example is extended to support this new feature.

graph: pcap capture for graph nodes

Implementation adds support to capture packets at each node with
packet metadata and node name.
The l3fwd-graph example is extended to support this new feature.

Signed-off-by: Amit Prakash Shukla <amitprakashs@marvell.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>

show more ...

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_p

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>

show more ...

doc: use code snippets in sample app guides

Currently the sample app user guides use hard coded code snippets,
this patch changes these to use literalinclude which will dynamically
update the snippe

doc: use code snippets in sample app guides

Currently the sample app user guides use hard coded code snippets,
this patch changes these to use literalinclude which will dynamically
update the snippets as changes are made to the code.
This was introduced in commit 413c75c33c40 ("doc: show how to include
code in guides"). Comments within the sample apps were updated to
accommodate this as part of this patch. This will help to ensure that
the code within the sample app user guides is up to date and not out
of sync with the actual code.

Signed-off-by: Conor Fogarty <conor.fogarty@intel.com>
Signed-off-by: Conor Walsh <conor.walsh@intel.com>
Acked-by: John McNamara <john.mcnamara@intel.com>

show more ...

doc: remove references to make from apps guide

While make has been deprecated for DPDK, it's still applicable for
some example apps to be built standalone, this patch adjusts the
guides to take that

doc: remove references to make from apps guide

While make has been deprecated for DPDK, it's still applicable for
some example apps to be built standalone, this patch adjusts the
guides to take that into consideration.

Signed-off-by: Ciara Power <ciara.power@intel.com>
Acked-by: Nicolas Chautru <nicolas.chautru@intel.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>

show more ...

eal: rename lcore master and slave

Replace master lcore with main lcore and
replace slave lcore with worker lcore.

Keep the old functions and macros but mark them as deprecated
for this release.

T

eal: rename lcore master and slave

Replace master lcore with main lcore and
replace slave lcore with worker lcore.

Keep the old functions and macros but mark them as deprecated
for this release.

The "--master-lcore" command line option is also deprecated
and any usage will print a warning and use "--main-lcore"
as replacement.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>

show more ...

doc: add l3fwd-graph application user guide

Adding the user guide for l3fwd graph application.

Signed-off-by: Nithin Dabilpuram <ndabilpuram@marvell.com>