Re: [dpdk-dev] [patch] doc: announce API change in ethdev offload flags

[Andrew Rybchenko <arybchenko@solarflare.com>]

On 8/7/19 7:09 PM, pbhagavatula@marvell.com wrote:
> From: Pavan Nikhilesh <pbhagavatula@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@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@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 
is a
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 
still OK),
so it is hard for application to notice it. It should be discussed if it 
is acceptable
or should be addressed in a different way (negative offloads? not ideal 
as well).

I think that situation with tso_segsz for LRO, discussed in a separate 
thread [1],
is very similar in fact. No problem with compilation, but semantics change.

[1] https://patches.dpdk.org/patch/57493/