DPDK patches and discussions
 help / color / mirror / Atom feed
From: Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>
To: Andrew Rybchenko <arybchenko@solarflare.com>,
	Jerin Jacob Kollanukkaran <jerinj@marvell.com>,
	"ferruh.yigit@intel.com" <ferruh.yigit@intel.com>,
	"John McNamara" <john.mcnamara@intel.com>,
	Marko Kovacevic <marko.kovacevic@intel.com>,
	Thomas Monjalon <thomas@monjalon.net>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [EXT] Re: [PATCH 1/7] ethdev: add set ptype function
Date: Sat, 17 Aug 2019 16:27:38 +0000	[thread overview]
Message-ID: <CY4PR1801MB1863DEF9A762A9E146207D2DDEAE0@CY4PR1801MB1863.namprd18.prod.outlook.com> (raw)
In-Reply-To: <851302fb-0c2a-1b48-e37c-7ca6e69bdbf9@solarflare.com>



>-----Original Message-----
>From: Andrew Rybchenko <arybchenko@solarflare.com>
>Sent: Friday, August 16, 2019 1:53 PM
>To: Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>; Jerin
>Jacob Kollanukkaran <jerinj@marvell.com>; ferruh.yigit@intel.com;
>John McNamara <john.mcnamara@intel.com>; Marko Kovacevic
><marko.kovacevic@intel.com>; Thomas Monjalon
><thomas@monjalon.net>
>Cc: dev@dpdk.org
>Subject: [EXT] Re: [dpdk-dev] [PATCH 1/7] ethdev: add set ptype
>function
>
>External Email
>
>----------------------------------------------------------------------
>The patch should add item in release notes (as well as all other
>subsequent patches which add more features).

Will update release notes in v2.
>
>On 8/16/19 8:55 AM, pbhagavatula@marvell.com wrote:
>> 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)` and PMD
>> will set rte_mbuf::packet_type to 0.
>
>As I understand PMD may provide more reach classification
>than set. So, it is not obliged to set packet type to 0.

Yes it would be undefined. 
>
>> -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)`.
>>
>> Suggested-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
>> Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
>> ---
>>   doc/guides/nics/features.rst        | 12 ++++++++----
>>   lib/librte_ethdev/rte_ethdev.c      | 28
>++++++++++++++++++++++++++++
>>   lib/librte_ethdev/rte_ethdev.h      | 17 +++++++++++++++++
>>   lib/librte_ethdev/rte_ethdev_core.h |  6 ++++++
>>   4 files changed, 59 insertions(+), 4 deletions(-)
>>
>> diff --git a/doc/guides/nics/features.rst
>b/doc/guides/nics/features.rst
>> index c4e128d2f..d4d55f721 100644
>> --- a/doc/guides/nics/features.rst
>> +++ b/doc/guides/nics/features.rst
>> @@ -582,10 +582,14 @@ Supports inner packet L4 checksum.
>>   Packet type parsing
>>   -------------------
>>
>> -Supports packet type parsing and returns a list of supported types.
>> -
>> -* **[implements] eth_dev_ops**: ``dev_supported_ptypes_get``.
>> -* **[related]    API**: ``rte_eth_dev_get_supported_ptypes()``.
>> +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``,
>> +  ``dev_supported_ptypes_set``.
>> +* **[related]    API**: ``rte_eth_dev_get_supported_ptypes()``,
>> +  ``rte_eth_dev_set_supported_ptypes()``.
>> +* **[provides]   mbuf**: ``mbuf.packet_type``.
>>
>>
>>   .. _nic_features_timesync:
>> diff --git a/lib/librte_ethdev/rte_ethdev.c
>b/lib/librte_ethdev/rte_ethdev.c
>> index 17d183e1f..72fe660c3 100644
>> --- a/lib/librte_ethdev/rte_ethdev.c
>> +++ b/lib/librte_ethdev/rte_ethdev.c
>> @@ -2602,6 +2602,34 @@
>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)
>> +{
>> +	int i;
>> +	struct rte_eth_dev *dev;
>> +	const uint32_t *all_ptypes;
>> +	uint32_t all_ptype_mask = 0;
>> +
>> +	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
>> +	dev = &rte_eth_devices[port_id];
>> +	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops-
>>dev_supported_ptypes_set,
>> +				-ENOTSUP);
>> +	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops-
>>dev_supported_ptypes_get,
>> +				-ENOTSUP);
>> +	all_ptypes = (*dev->dev_ops-
>>dev_supported_ptypes_get)(dev);
>> +
>> +	if (!all_ptypes)
>
>If I remember correctly DPDK style prefers to compare vs 0.
>
>> +		return -ENOTSUP;
>> +
>> +	for (i = 0; all_ptypes[i] != RTE_PTYPE_UNKNOWN; ++i)
>> +		all_ptype_mask |= all_ptypes[i];
>> +
>> +	if ((all_ptype_mask & ptype_mask) != ptype_mask)
>> +		return -ENOTSUP;
>
>Do we really want so strict check here? May be just check
>that intersection is not empty if ptype_mask is not empty?
>
I was thinking the same maybe we can return the successfully set mask?  
And the application can use software parser to parse the rest?.

>I think that setting ptype_mask to 0 could be pretty often and
>may be it makes sense to avoid get in the case.

Agreed.

>Also consider
>to return OK even if there is no get/set callbacks at all.

I think if we are ok with the above approach i.e. returning successfully set ptypes, 
we will return 0 if there are no supported get/set call backs and the application 
can softparse the ptypes.

>
>> +
>> +	return (*dev->dev_ops->dev_supported_ptypes_set)(dev,
>ptype_mask);
>> +}
>> +
>>   void
>>   rte_eth_macaddr_get(uint16_t port_id, struct rte_ether_addr
>*mac_addr)
>>   {
>> diff --git a/lib/librte_ethdev/rte_ethdev.h
>b/lib/librte_ethdev/rte_ethdev.h
>> index dc6596bc9..f97f0a6e5 100644
>> --- a/lib/librte_ethdev/rte_ethdev.h
>> +++ b/lib/librte_ethdev/rte_ethdev.h
>> @@ -2431,6 +2431,23 @@ 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);
>> +/**
>> + * Request Ethernet device to set only specific packet types in the
>packet.
>> + *
>> + * 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.
>> + *
>> + * @param port_id
>> + *   The port identifier of the Ethernet device.
>> + * @param ptype_mask
>> + *   The ptype family that application is interested in.
>> + * @return
>> + *   - (0) Successfully set supported ptypes.
>> + *   - (-ENODEV) if *port_id* is invalid.
>> + *   - (-ENOTSUP) Packet type mask supplied is not supported by the
>Ethernet
>> + *		  device.
>> + */
>> +int rte_eth_dev_set_supported_ptypes(uint16_t port_id, uint32_t
>ptype_mask);
>
>Should it be experimental?
>
>Please, add it to .map file.

Will fix in v2.
>
>>   /**
>>    * 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 2922d5b7c..02ee7c12c 100644
>> --- a/lib/librte_ethdev/rte_ethdev_core.h
>> +++ b/lib/librte_ethdev/rte_ethdev_core.h
>> @@ -110,6 +110,10 @@ typedef void (*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. */
>>
>> +typedef int (*eth_dev_supported_ptypes_set_t)(struct
>rte_eth_dev *dev,
>> +					      uint32_t ptype_mask);
>> +/**< @internal Set required ptypes of an Ethernet device. */
>> +
>>   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. */
>> @@ -421,6 +425,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 device about the interested ptypes. */
>>
>>   	vlan_filter_set_t          vlan_filter_set; /**< Filter VLAN Setup. */
>>   	vlan_tpid_set_t            vlan_tpid_set; /**< Outer/Inner VLAN
>TPID Setup. */
>> --
>> 2.22.0
>>


  reply	other threads:[~2019-08-17 16:27 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-16  5:55 [dpdk-dev] [PATCH 0/7] ethdev: add new Rx offload flags pbhagavatula
2019-08-16  5:55 ` [dpdk-dev] [PATCH 1/7] ethdev: add set ptype function pbhagavatula
2019-08-16  8:22   ` Andrew Rybchenko
2019-08-17 16:27     ` Pavan Nikhilesh Bhagavatula [this message]
2019-08-16  5:55 ` [dpdk-dev] [PATCH 2/7] ethdev: add mbuf RSS update as a offload pbhagavatula
2019-08-16  7:48   ` Andrew Rybchenko
2019-08-17 11:47     ` Pavan Nikhilesh Bhagavatula
2019-08-18  4:52     ` Shahaf Shuler
2019-08-18  5:38       ` Andrew Rybchenko
2019-08-18  6:18         ` Shahaf Shuler
2019-08-18  7:00           ` Andrew Rybchenko
2019-08-18 12:11             ` Shahaf Shuler
2019-08-16  5:55 ` [dpdk-dev] [PATCH 3/7] ethdev: add flow action type update as an offload pbhagavatula
2019-08-16  8:05   ` Andrew Rybchenko
2019-08-17 14:23     ` [dpdk-dev] [EXT] " Pavan Nikhilesh Bhagavatula
2019-08-18  9:46       ` Andrew Rybchenko
2019-08-18  4:59     ` [dpdk-dev] " Shahaf Shuler
2019-08-18  5:57       ` Andrew Rybchenko
2019-08-18  6:20         ` Shahaf Shuler
2019-08-18  7:08           ` Andrew Rybchenko
2019-08-16  5:55 ` [dpdk-dev] [PATCH 4/7] net: update Rx RSS hash offload capabilities pbhagavatula
2019-08-16  7:49   ` Andrew Rybchenko
2019-08-17 12:26     ` Pavan Nikhilesh Bhagavatula
2019-08-16  5:55 ` [dpdk-dev] [PATCH 5/7] net: update Rx flow action " pbhagavatula
2019-08-16  7:50   ` Andrew Rybchenko
2019-08-16  5:55 ` [dpdk-dev] [PATCH 6/7] net: add ptype set default functionality pbhagavatula
2019-08-16  8:30   ` Andrew Rybchenko
2019-08-17 17:24     ` Pavan Nikhilesh Bhagavatula
2019-08-16  5:55 ` [dpdk-dev] [PATCH 7/7] examples/eventdev_pipeline: add new Rx RSS hash offload pbhagavatula
2019-08-16  6:01   ` Jerin Jacob Kollanukkaran
2019-08-16  6:02 ` [dpdk-dev] [PATCH 0/7] ethdev: add new Rx offload flags Jerin Jacob Kollanukkaran

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CY4PR1801MB1863DEF9A762A9E146207D2DDEAE0@CY4PR1801MB1863.namprd18.prod.outlook.com \
    --to=pbhagavatula@marvell.com \
    --cc=arybchenko@solarflare.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=jerinj@marvell.com \
    --cc=john.mcnamara@intel.com \
    --cc=marko.kovacevic@intel.com \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).