Re: [dpdk-dev] [PATCH v15 1/7] ethdev: add set ptype function

Re: [dpdk-dev] [PATCH v15 1/7] ethdev: add set ptype function

[Pavan Nikhilesh Bhagavatula]

>29/10/2019 16:37, pbhagavatula@marvell.com:
>> From: Pavan Nikhilesh <pbhagavatula@marvell.com>
>> --- a/doc/guides/rel_notes/release_19_11.rst
>> +++ b/doc/guides/rel_notes/release_19_11.rst
>> @@ -231,6 +231,14 @@ New Features
>>    * Added a console command to testpmd app, ``show port (port_id)
>ptypes`` which
>>      gives ability to print port supported ptypes in different protocol
>layers.
>>
>> +* **Added ethdev API to set supported packet types**
>> +
>> +  *  Added new API ``rte_eth_dev_set_supported_ptypes`` that
>allows an
>> +     application to inform PMD about packet types classification the
>application
>> +     is interested in
>> +  *  This scheme will allow PMDs to avoid lookup to internal ptype
>table on Rx
>> +     and thereby improve Rx performance if application wishes do so.
>
>You just added or rebased this paragraph at the end.
>As mentioned in the release notes files (top of the section),
>there is an order for presenting features.

Will fix in v16.

>
>>  Removed Items
>>  -------------
>> --- a/lib/librte_ethdev/rte_ethdev.h
>> +++ b/lib/librte_ethdev/rte_ethdev.h
>> +/**
>> + * @warning
>> + * @b EXPERIMENTAL: this API may change without prior notice.
>> + *
>> + * Inform Ethernet device of the packet types classification the
>recipient is
>> + * interested in.
>
>This is a bit convoluted.
>What about this?
>"Optimize driver handling of packet types by reducing its range."

@arybchenko@solarflare.com Thoughts?

>
>> + *
>> + * Application can use this function to set only specific ptypes that it's
>> + * interested. This information can be used by the PMD to optimize
>Rx path.
>> + *
>> + * The function accepts an array `set_ptypes` allocated by the caller
>to
>> + * store the packet types set by the driver, the last element of the
>array
>> + * is set to RTE_PTYPE_UNKNOWN. The size of the `set_ptype` array
>should be
>> + * `rte_eth_dev_get_supported_ptypes() + 1` else it might only be
>filled
>> + * partially.
>> + *
>> + * @param port_id
>> + *   The port identifier of the Ethernet device.
>> + * @param ptype_mask
>> + *   The ptype family that application is interested in should be
>bitwise OR of
>> + *   RTE_PTYPE_*_MASK or 0.
>> + * @param set_ptypes
>> + *   An array pointer to store set packet types, allocated by caller. The
>> + *   function marks the end of array with RTE_PTYPE_UNKNOWN.
>> + * @param num
>> + *   Size of the array pointed by param ptypes.
>> + *   Should be rte_eth_dev_get_supported_ptypes() + 1 to
>accommodate the
>> + *   set ptypes.
>> + * @return
>> + *   - (0) if Success.
>> + *   - (-ENODEV) if *port_id* invalid.
>> + *   - (-EINVAL) if *ptype_mask* is invalid (or) set_ptypes is NULL and
>> + *     num > 0.
>> + */
>
>John, please you check the English wording?
>
>> +__rte_experimental
>> +int rte_eth_dev_set_supported_ptypes(uint16_t port_id, uint32_t
>ptype_mask,
>> +				     uint32_t *set_ptypes, unsigned int
>num);
>
>I don't like the name of the function because they are
>not "supported" packet types but "requested".
>What about replacing "set_supported" with "set_allowed", or
>"white_list"?

"white_list" seems ok but hope it doesn't call for blacklisting API.

>

Re: [dpdk-dev] [PATCH v15 1/7] ethdev: add set ptype function

[Andrew Rybchenko]

On 10/31/19 7:38 PM, Pavan Nikhilesh Bhagavatula wrote:
>> 29/10/2019 16:37, pbhagavatula@marvell.com:
>>> From: Pavan Nikhilesh <pbhagavatula@marvell.com>
>>>  Removed Items
>>>  -------------
>>> --- a/lib/librte_ethdev/rte_ethdev.h
>>> +++ b/lib/librte_ethdev/rte_ethdev.h
>>> +/**
>>> + * @warning
>>> + * @b EXPERIMENTAL: this API may change without prior notice.
>>> + *
>>> + * Inform Ethernet device of the packet types classification the
>> recipient is
>>> + * interested in.
>> This is a bit convoluted.
>> What about this?
>> "Optimize driver handling of packet types by reducing its range."
> @arybchenko@solarflare.com Thoughts?

Optimize is a possible side effect of the operation, but there is
no any promise that something will be optimized.
I thought that current description explains what happens.
Below statements try to explain why it may be useful.
Any other options?

>>> + *
>>> + * Application can use this function to set only specific ptypes that it's
>>> + * interested. This information can be used by the PMD to optimize
>> Rx path.
>>> + *
>>> + * The function accepts an array `set_ptypes` allocated by the caller
>> to
>>> + * store the packet types set by the driver, the last element of the
>> array
>>> + * is set to RTE_PTYPE_UNKNOWN. The size of the `set_ptype` array
>> should be
>>> + * `rte_eth_dev_get_supported_ptypes() + 1` else it might only be
>> filled
>>> + * partially.
>>> + *
>>> + * @param port_id
>>> + *   The port identifier of the Ethernet device.
>>> + * @param ptype_mask
>>> + *   The ptype family that application is interested in should be
>> bitwise OR of
>>> + *   RTE_PTYPE_*_MASK or 0.
>>> + * @param set_ptypes
>>> + *   An array pointer to store set packet types, allocated by caller. The
>>> + *   function marks the end of array with RTE_PTYPE_UNKNOWN.
>>> + * @param num
>>> + *   Size of the array pointed by param ptypes.
>>> + *   Should be rte_eth_dev_get_supported_ptypes() + 1 to
>> accommodate the
>>> + *   set ptypes.
>>> + * @return
>>> + *   - (0) if Success.
>>> + *   - (-ENODEV) if *port_id* invalid.
>>> + *   - (-EINVAL) if *ptype_mask* is invalid (or) set_ptypes is NULL and
>>> + *     num > 0.
>>> + */
>> John, please you check the English wording?
>>
>>> +__rte_experimental
>>> +int rte_eth_dev_set_supported_ptypes(uint16_t port_id, uint32_t
>> ptype_mask,
>>> +				     uint32_t *set_ptypes, unsigned int
>> num);
>>
>> I don't like the name of the function because they are
>> not "supported" packet types but "requested".
>> What about replacing "set_supported" with "set_allowed", or
>> "white_list"?
> "white_list" seems ok but hope it doesn't call for blacklisting API.

"white_list" suggests that it is guaranteed that nothing else will
be reported. At least for me. However, I agree that set_supported
is not nice and I accepted it just to keep API naming symmetric.
May be it is really misleading here. May be just: rte_eth_dev_set_ptypes()?

Re: [dpdk-dev] [PATCH v15 1/7] ethdev: add set ptype function

[Thomas Monjalon]

01/11/2019 11:55, Andrew Rybchenko:
> On 10/31/19 7:38 PM, Pavan Nikhilesh Bhagavatula wrote:
> >> 29/10/2019 16:37, pbhagavatula@marvell.com:
> >>> From: Pavan Nikhilesh <pbhagavatula@marvell.com>
> >>>  Removed Items
> >>>  -------------
> >>> --- a/lib/librte_ethdev/rte_ethdev.h
> >>> +++ b/lib/librte_ethdev/rte_ethdev.h
> >>> +/**
> >>> + * @warning
> >>> + * @b EXPERIMENTAL: this API may change without prior notice.
> >>> + *
> >>> + * Inform Ethernet device of the packet types classification the
> >> recipient is
> >>> + * interested in.
> >> This is a bit convoluted.
> >> What about this?
> >> "Optimize driver handling of packet types by reducing its range."
> > @arybchenko@solarflare.com Thoughts?
> 
> Optimize is a possible side effect of the operation, but there is
> no any promise that something will be optimized.
> I thought that current description explains what happens.
> Below statements try to explain why it may be useful.
> Any other options?

"Reduce range of packet types to handle."

> >>> + * Application can use this function to set only specific ptypes that it's
> >>> + * interested. This information can be used by the PMD to optimize
> >> Rx path.
> >>> + *
> >>> + * The function accepts an array `set_ptypes` allocated by the caller
> >> to
> >>> + * store the packet types set by the driver, the last element of the
> >> array
> >>> + * is set to RTE_PTYPE_UNKNOWN. The size of the `set_ptype` array
> >> should be
> >>> + * `rte_eth_dev_get_supported_ptypes() + 1` else it might only be
> >> filled
> >>> + * partially.
> >>> + *
> >>> + * @param port_id
> >>> + *   The port identifier of the Ethernet device.
> >>> + * @param ptype_mask
> >>> + *   The ptype family that application is interested in should be
> >> bitwise OR of
> >>> + *   RTE_PTYPE_*_MASK or 0.
> >>> + * @param set_ptypes
> >>> + *   An array pointer to store set packet types, allocated by caller. The
> >>> + *   function marks the end of array with RTE_PTYPE_UNKNOWN.
> >>> + * @param num
> >>> + *   Size of the array pointed by param ptypes.
> >>> + *   Should be rte_eth_dev_get_supported_ptypes() + 1 to
> >> accommodate the
> >>> + *   set ptypes.
> >>> + * @return
> >>> + *   - (0) if Success.
> >>> + *   - (-ENODEV) if *port_id* invalid.
> >>> + *   - (-EINVAL) if *ptype_mask* is invalid (or) set_ptypes is NULL and
> >>> + *     num > 0.
> >>> + */
> >> John, please you check the English wording?
> >>
> >>> +__rte_experimental
> >>> +int rte_eth_dev_set_supported_ptypes(uint16_t port_id, uint32_t
> >> ptype_mask,
> >>> +				     uint32_t *set_ptypes, unsigned int
> >> num);
> >>
> >> I don't like the name of the function because they are
> >> not "supported" packet types but "requested".
> >> What about replacing "set_supported" with "set_allowed", or
> >> "white_list"?
> > "white_list" seems ok but hope it doesn't call for blacklisting API.
> 
> "white_list" suggests that it is guaranteed that nothing else will
> be reported. At least for me. However, I agree that set_supported
> is not nice and I accepted it just to keep API naming symmetric.
> May be it is really misleading here. May be just: rte_eth_dev_set_ptypes()?

Maybe the word "allowed" would better fit?

Re: [dpdk-dev] [PATCH v15 1/7] ethdev: add set ptype function

[Andrew Rybchenko]

On 11/2/19 1:25 AM, Thomas Monjalon wrote:
> 01/11/2019 11:55, Andrew Rybchenko:
>> On 10/31/19 7:38 PM, Pavan Nikhilesh Bhagavatula wrote:
>>>> 29/10/2019 16:37, pbhagavatula@marvell.com:
>>>>> From: Pavan Nikhilesh <pbhagavatula@marvell.com>
>>>>>  Removed Items
>>>>>  -------------
>>>>> --- a/lib/librte_ethdev/rte_ethdev.h
>>>>> +++ b/lib/librte_ethdev/rte_ethdev.h
>>>>> +/**
>>>>> + * @warning
>>>>> + * @b EXPERIMENTAL: this API may change without prior notice.
>>>>> + *
>>>>> + * Inform Ethernet device of the packet types classification the
>>>> recipient is
>>>>> + * interested in.
>>>> This is a bit convoluted.
>>>> What about this?
>>>> "Optimize driver handling of packet types by reducing its range."
>>> @arybchenko@solarflare.com Thoughts?
>> Optimize is a possible side effect of the operation, but there is
>> no any promise that something will be optimized.
>> I thought that current description explains what happens.
>> Below statements try to explain why it may be useful.
>> Any other options?
> "Reduce range of packet types to handle."

OK

>>>>> + * Application can use this function to set only specific ptypes that it's
>>>>> + * interested. This information can be used by the PMD to optimize
>>>> Rx path.
>>>>> + *
>>>>> + * The function accepts an array `set_ptypes` allocated by the caller
>>>> to
>>>>> + * store the packet types set by the driver, the last element of the
>>>> array
>>>>> + * is set to RTE_PTYPE_UNKNOWN. The size of the `set_ptype` array
>>>> should be
>>>>> + * `rte_eth_dev_get_supported_ptypes() + 1` else it might only be
>>>> filled
>>>>> + * partially.
>>>>> + *
>>>>> + * @param port_id
>>>>> + *   The port identifier of the Ethernet device.
>>>>> + * @param ptype_mask
>>>>> + *   The ptype family that application is interested in should be
>>>> bitwise OR of
>>>>> + *   RTE_PTYPE_*_MASK or 0.
>>>>> + * @param set_ptypes
>>>>> + *   An array pointer to store set packet types, allocated by caller. The
>>>>> + *   function marks the end of array with RTE_PTYPE_UNKNOWN.
>>>>> + * @param num
>>>>> + *   Size of the array pointed by param ptypes.
>>>>> + *   Should be rte_eth_dev_get_supported_ptypes() + 1 to
>>>> accommodate the
>>>>> + *   set ptypes.
>>>>> + * @return
>>>>> + *   - (0) if Success.
>>>>> + *   - (-ENODEV) if *port_id* invalid.
>>>>> + *   - (-EINVAL) if *ptype_mask* is invalid (or) set_ptypes is NULL and
>>>>> + *     num > 0.
>>>>> + */
>>>> John, please you check the English wording?
>>>>
>>>>> +__rte_experimental
>>>>> +int rte_eth_dev_set_supported_ptypes(uint16_t port_id, uint32_t
>>>> ptype_mask,
>>>>> +				     uint32_t *set_ptypes, unsigned int
>>>> num);
>>>>
>>>> I don't like the name of the function because they are
>>>> not "supported" packet types but "requested".
>>>> What about replacing "set_supported" with "set_allowed", or
>>>> "white_list"?
>>> "white_list" seems ok but hope it doesn't call for blacklisting API.
>> "white_list" suggests that it is guaranteed that nothing else will
>> be reported. At least for me. However, I agree that set_supported
>> is not nice and I accepted it just to keep API naming symmetric.
>> May be it is really misleading here. May be just: rte_eth_dev_set_ptypes()?
> Maybe the word "allowed" would better fit?

allowed could be treated as everything else is disallowed. So, I'm not sure.

Re: [dpdk-dev] [PATCH v15 1/7] ethdev: add set ptype function

[Thomas Monjalon]

29/10/2019 16:37, pbhagavatula@marvell.com:
> From: Pavan Nikhilesh <pbhagavatula@marvell.com>
> --- a/doc/guides/rel_notes/release_19_11.rst
> +++ b/doc/guides/rel_notes/release_19_11.rst
> @@ -231,6 +231,14 @@ New Features
>    * Added a console command to testpmd app, ``show port (port_id) ptypes`` which
>      gives ability to print port supported ptypes in different protocol layers.
>  
> +* **Added ethdev API to set supported packet types**
> +
> +  *  Added new API ``rte_eth_dev_set_supported_ptypes`` that allows an
> +     application to inform PMD about packet types classification the application
> +     is interested in
> +  *  This scheme will allow PMDs to avoid lookup to internal ptype table on Rx
> +     and thereby improve Rx performance if application wishes do so.

You just added or rebased this paragraph at the end.
As mentioned in the release notes files (top of the section),
there is an order for presenting features.

>  Removed Items
>  -------------
> --- a/lib/librte_ethdev/rte_ethdev.h
> +++ b/lib/librte_ethdev/rte_ethdev.h
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice.
> + *
> + * Inform Ethernet device of the packet types classification the recipient is
> + * interested in.

This is a bit convoluted.
What about this?
"Optimize driver handling of packet types by reducing its range."

> + *
> + * Application can use this function to set only specific ptypes that it's
> + * interested. This information can be used by the PMD to optimize Rx path.
> + *
> + * The function accepts an array `set_ptypes` allocated by the caller to
> + * store the packet types set by the driver, the last element of the array
> + * is set to RTE_PTYPE_UNKNOWN. The size of the `set_ptype` array should be
> + * `rte_eth_dev_get_supported_ptypes() + 1` else it might only be filled
> + * partially.
> + *
> + * @param port_id
> + *   The port identifier of the Ethernet device.
> + * @param ptype_mask
> + *   The ptype family that application is interested in should be bitwise OR of
> + *   RTE_PTYPE_*_MASK or 0.
> + * @param set_ptypes
> + *   An array pointer to store set packet types, allocated by caller. The
> + *   function marks the end of array with RTE_PTYPE_UNKNOWN.
> + * @param num
> + *   Size of the array pointed by param ptypes.
> + *   Should be rte_eth_dev_get_supported_ptypes() + 1 to accommodate the
> + *   set ptypes.
> + * @return
> + *   - (0) if Success.
> + *   - (-ENODEV) if *port_id* invalid.
> + *   - (-EINVAL) if *ptype_mask* is invalid (or) set_ptypes is NULL and
> + *     num > 0.
> + */

John, please you check the English wording?

> +__rte_experimental
> +int rte_eth_dev_set_supported_ptypes(uint16_t port_id, uint32_t ptype_mask,
> +				     uint32_t *set_ptypes, unsigned int num);

I don't like the name of the function because they are
not "supported" packet types but "requested".
What about replacing "set_supported" with "set_allowed", or "white_list"?

[dpdk-dev] [PATCH v15 1/7] ethdev: add set ptype function

[pbhagavatula]

From: Pavan Nikhilesh <pbhagavatula@marvell.com>

Add `rte_eth_dev_set_supported_ptypes` function that will allow the
application to inform the PMD the packet types it is interested in.
Based on the ptypes set PMDs can optimize their Rx path.

-If application doesn’t want any ptype information it can call
`rte_eth_dev_set_supported_ptypes(ethdev_id, RTE_PTYPE_UNKNOWN, NULL, 0)`
and PMD may skip packet type processing and set rte_mbuf::packet_type to
RTE_PTYPE_UNKNOWN.

-If application doesn’t call `rte_eth_dev_set_supported_ptypes` PMD can
return `rte_mbuf::packet_type` with `rte_eth_dev_get_supported_ptypes`.

-If application is interested only in L2/L3 layer, it can inform the PMD
to update `rte_mbuf::packet_type` with L2/L3 ptype by calling
`rte_eth_dev_set_supported_ptypes(ethdev_id,
		RTE_PTYPE_L2_MASK | RTE_PTYPE_L3_MASK, NULL, 0)`.

Suggested-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
Reviewed-by: Andrew Rybchenko <arybchenko@solarflare.com>
---
 doc/guides/nics/features.rst             |  7 +-
 doc/guides/rel_notes/release_19_11.rst   |  8 +++
 lib/librte_ethdev/rte_ethdev.c           | 87 +++++++++++++++++++++++-
 lib/librte_ethdev/rte_ethdev.h           | 37 ++++++++++
 lib/librte_ethdev/rte_ethdev_core.h      | 19 ++++++
 lib/librte_ethdev/rte_ethdev_version.map |  1 +
 6 files changed, 156 insertions(+), 3 deletions(-)

diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
index d96696801..6e20bee5f 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -583,9 +583,12 @@ Packet type parsing
 -------------------
 
 Supports packet type parsing and returns a list of supported types.
+Allows application to set ptypes it is interested in.
 
-* **[implements] eth_dev_ops**: ``dev_supported_ptypes_get``.
-* **[related]    API**: ``rte_eth_dev_get_supported_ptypes()``.
+* **[implements] eth_dev_ops**: ``dev_supported_ptypes_get``,
+* **[related]    API**: ``rte_eth_dev_get_supported_ptypes()``,
+  ``rte_eth_dev_set_supported_ptypes()``, ``dev_supported_ptypes_set``.
+* **[provides]   mbuf**: ``mbuf.packet_type``.
 
 
 .. _nic_features_timesync:
diff --git a/doc/guides/rel_notes/release_19_11.rst b/doc/guides/rel_notes/release_19_11.rst
index ae8e7b2f0..194afc8b9 100644
--- a/doc/guides/rel_notes/release_19_11.rst
+++ b/doc/guides/rel_notes/release_19_11.rst
@@ -231,6 +231,14 @@ New Features
   * Added a console command to testpmd app, ``show port (port_id) ptypes`` which
     gives ability to print port supported ptypes in different protocol layers.
 
+* **Added ethdev API to set supported packet types**
+
+  *  Added new API ``rte_eth_dev_set_supported_ptypes`` that allows an
+     application to inform PMD about packet types classification the application
+     is interested in
+  *  This scheme will allow PMDs to avoid lookup to internal ptype table on Rx
+     and thereby improve Rx performance if application wishes do so.
+
 
 Removed Items
 -------------
diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index 7743205d3..6ce8f5e75 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -2734,6 +2734,92 @@ rte_eth_dev_get_supported_ptypes(uint16_t port_id, uint32_t ptype_mask,
 	return j;
 }
 
+int
+rte_eth_dev_set_supported_ptypes(uint16_t port_id, uint32_t ptype_mask,
+				 uint32_t *set_ptypes, unsigned int num)
+{
+	const uint32_t valid_ptype_masks[] = {
+		RTE_PTYPE_L2_MASK,
+		RTE_PTYPE_L3_MASK,
+		RTE_PTYPE_L4_MASK,
+		RTE_PTYPE_TUNNEL_MASK,
+		RTE_PTYPE_INNER_L2_MASK,
+		RTE_PTYPE_INNER_L3_MASK,
+		RTE_PTYPE_INNER_L4_MASK,
+	};
+	const uint32_t *all_ptypes;
+	struct rte_eth_dev *dev;
+	uint32_t unused_mask;
+	unsigned int i, j;
+	int ret;
+
+	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+	dev = &rte_eth_devices[port_id];
+
+	if (num > 0 && set_ptypes == NULL)
+		return -EINVAL;
+
+	if (*dev->dev_ops->dev_supported_ptypes_get == NULL ||
+			*dev->dev_ops->dev_supported_ptypes_set == NULL) {
+		ret = 0;
+		goto ptype_unknown;
+	}
+
+	if (ptype_mask == 0) {
+		ret = (*dev->dev_ops->dev_supported_ptypes_set)(dev,
+				ptype_mask);
+		goto ptype_unknown;
+	}
+
+	unused_mask = ptype_mask;
+	for (i = 0; i < RTE_DIM(valid_ptype_masks); i++) {
+		uint32_t mask = ptype_mask & valid_ptype_masks[i];
+		if (mask && mask != valid_ptype_masks[i]) {
+			ret = -EINVAL;
+			goto ptype_unknown;
+		}
+		unused_mask &= ~valid_ptype_masks[i];
+	}
+
+	if (unused_mask) {
+		ret = -EINVAL;
+		goto ptype_unknown;
+	}
+
+	all_ptypes = (*dev->dev_ops->dev_supported_ptypes_get)(dev);
+	if (all_ptypes == NULL) {
+		ret = 0;
+		goto ptype_unknown;
+	}
+
+	/*
+	 * Accodommodate as many set_ptypes as possible. If the supplied
+	 * set_ptypes array is insufficient fill it partially.
+	 */
+	for (i = 0, j = 0; set_ptypes != NULL &&
+				(all_ptypes[i] != RTE_PTYPE_UNKNOWN); ++i) {
+		if (ptype_mask & all_ptypes[i]) {
+			if (j < num - 1) {
+				set_ptypes[j] = all_ptypes[i];
+				j++;
+				continue;
+			}
+			break;
+		}
+	}
+
+	if (set_ptypes != NULL && j < num)
+		set_ptypes[j] = RTE_PTYPE_UNKNOWN;
+
+	return (*dev->dev_ops->dev_supported_ptypes_set)(dev, ptype_mask);
+
+ptype_unknown:
+	if (num > 0)
+		set_ptypes[0] = RTE_PTYPE_UNKNOWN;
+
+	return ret;
+}
+
 int
 rte_eth_macaddr_get(uint16_t port_id, struct rte_ether_addr *mac_addr)
 {
@@ -2746,7 +2832,6 @@ rte_eth_macaddr_get(uint16_t port_id, struct rte_ether_addr *mac_addr)
 	return 0;
 }
 
-
 int
 rte_eth_dev_get_mtu(uint16_t port_id, uint16_t *mtu)
 {
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index c36c1b631..c4ec36ea7 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -2539,6 +2539,43 @@ int rte_eth_dev_fw_version_get(uint16_t port_id,
  */
 int rte_eth_dev_get_supported_ptypes(uint16_t port_id, uint32_t ptype_mask,
 				     uint32_t *ptypes, int num);
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Inform Ethernet device of the packet types classification the recipient is
+ * interested in.
+ *
+ * Application can use this function to set only specific ptypes that it's
+ * interested. This information can be used by the PMD to optimize Rx path.
+ *
+ * The function accepts an array `set_ptypes` allocated by the caller to
+ * store the packet types set by the driver, the last element of the array
+ * is set to RTE_PTYPE_UNKNOWN. The size of the `set_ptype` array should be
+ * `rte_eth_dev_get_supported_ptypes() + 1` else it might only be filled
+ * partially.
+ *
+ * @param port_id
+ *   The port identifier of the Ethernet device.
+ * @param ptype_mask
+ *   The ptype family that application is interested in should be bitwise OR of
+ *   RTE_PTYPE_*_MASK or 0.
+ * @param set_ptypes
+ *   An array pointer to store set packet types, allocated by caller. The
+ *   function marks the end of array with RTE_PTYPE_UNKNOWN.
+ * @param num
+ *   Size of the array pointed by param ptypes.
+ *   Should be rte_eth_dev_get_supported_ptypes() + 1 to accommodate the
+ *   set ptypes.
+ * @return
+ *   - (0) if Success.
+ *   - (-ENODEV) if *port_id* invalid.
+ *   - (-EINVAL) if *ptype_mask* is invalid (or) set_ptypes is NULL and
+ *     num > 0.
+ */
+__rte_experimental
+int rte_eth_dev_set_supported_ptypes(uint16_t port_id, uint32_t ptype_mask,
+				     uint32_t *set_ptypes, unsigned int num);
 
 /**
  * Retrieve the MTU of an Ethernet device.
diff --git a/lib/librte_ethdev/rte_ethdev_core.h b/lib/librte_ethdev/rte_ethdev_core.h
index 392aea8e6..d5245a7d0 100644
--- a/lib/librte_ethdev/rte_ethdev_core.h
+++ b/lib/librte_ethdev/rte_ethdev_core.h
@@ -234,6 +234,23 @@ typedef int (*eth_dev_infos_get_t)(struct rte_eth_dev *dev,
 typedef const uint32_t *(*eth_dev_supported_ptypes_get_t)(struct rte_eth_dev *dev);
 /**< @internal Get supported ptypes of an Ethernet device. */
 
+/**
+ * @internal
+ * Inform an Ethernet device about packet types classifications the recipient
+ * is interested in.
+ *
+ * @param dev
+ *   The Ethernet device identifier.
+ * @param ptype_mask
+ *   The ptype family that application is interested in should be bitwise OR of
+ *   RTE_PTYPE_*_MASK or 0.
+ * @return
+ *   - (0) if Success.
+ *   - (-EINVAL) if *ptype_mask* is invalid.
+ */
+typedef int (*eth_dev_supported_ptypes_set_t)(struct rte_eth_dev *dev,
+					      uint32_t ptype_mask);
+
 typedef int (*eth_queue_start_t)(struct rte_eth_dev *dev,
 				    uint16_t queue_id);
 /**< @internal Start rx and tx of a queue of an Ethernet device. */
@@ -550,6 +567,8 @@ struct eth_dev_ops {
 	eth_fw_version_get_t       fw_version_get; /**< Get firmware version. */
 	eth_dev_supported_ptypes_get_t dev_supported_ptypes_get;
 	/**< Get packet types supported and identified by device. */
+	eth_dev_supported_ptypes_set_t dev_supported_ptypes_set;
+	/**< Inform Ethernet device about packet types the recipient is interested in. */
 
 	vlan_filter_set_t          vlan_filter_set; /**< Filter VLAN Setup. */
 	vlan_tpid_set_t            vlan_tpid_set; /**< Outer/Inner VLAN TPID Setup. */
diff --git a/lib/librte_ethdev/rte_ethdev_version.map b/lib/librte_ethdev/rte_ethdev_version.map
index e59d51648..f511294d2 100644
--- a/lib/librte_ethdev/rte_ethdev_version.map
+++ b/lib/librte_ethdev/rte_ethdev_version.map
@@ -288,4 +288,5 @@ EXPERIMENTAL {
 	rte_eth_rx_burst_mode_get;
 	rte_eth_tx_burst_mode_get;
 	rte_eth_burst_mode_option_name;
+	rte_eth_dev_set_supported_ptypes;
 };
-- 
2.17.1