On 8/7/19 7:09 PM, pbhagavat...@marvell.com wrote:
From: Pavan Nikhilesh <pbhagavat...@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 <pbhagavat...@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 <arybche...@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/
