[dpdk-dev] [patch] doc: announce API change in ethdev offload flags
arybchenko at solarflare.com
Wed Aug 7 21:36:21 CEST 2019
On 8/7/19 7:09 PM, pbhagavatula at marvell.com wrote:
> From: Pavan Nikhilesh <pbhagavatula at marvell.com>
> Add new offload flags ``DEV_RX_OFFLOAD_PTYPE``, ``DEV_RX_OFFLOAD_RSS``
> and ``DEV_RX_OFFLOAD_FLOW_MARK``.
> Signed-off-by: Pavan Nikhilesh <pbhagavatula at marvell.com>
> doc/guides/rel_notes/deprecation.rst | 9 +++++++++
> 1 file changed, 9 insertions(+)
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index 37b8592b6..a10f69e98 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -78,3 +78,12 @@ Deprecation Notices
> to set new power environment if power environment was already initialized.
> In this case the function will return -1 unless the environment is unset first
> (using ``rte_power_unset_env``). Other function usage scenarios will not change.
> +* ethdev: New offload flags ``DEV_RX_OFFLOAD_PTYPE``, ``DEV_RX_OFFLOAD_RSS``
I'd name it DEV_RX_OFFLOAD_RSS_HASH
> + and ``DEV_RX_OFFLOAD_FLOW_MARK`` will be added in 19.11.
> + This will allow application to enable or disable PMDs from updating
> + ``rte_mbuf`` fields ``rte_mbuf::packet_type``, ``rte_mbuf::hash::rss`` and
> + ``rte_mbuf::hash::fdir`` respectively.
> + In 19.11 PMDs will still update the fields even when the offloads are not
> + enabled. This is done as an optimization to avoid writes to ``rte_mbuf`` fields,
> + the exact semantics of the flags will be worked out later.
Acked-by: Andrew Rybchenko <arybchenko at solarflare.com>
since I was going to propose something similar. However, there is a problem
with all three, since they are efficiently enabled by default now and it
proposal to change it. As Stephen pointed it out it is bad from application
point of view since it is invisible (no API breakage, compilation is
so it is hard for application to notice it. It should be discussed if it
or should be addressed in a different way (negative offloads? not ideal
I think that situation with tso_segsz for LRO, discussed in a separate
is very similar in fact. No problem with compilation, but semantics change.
More information about the dev