From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 86201A2EDB for ; Wed, 2 Oct 2019 15:41:31 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B96801BEF6; Wed, 2 Oct 2019 15:41:30 +0200 (CEST) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id 8B9691BEDA for ; Wed, 2 Oct 2019 15:41:29 +0200 (CEST) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us5.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id 2A54D4C005A; Wed, 2 Oct 2019 13:41:28 +0000 (UTC) Received: from [192.168.38.17] (91.220.146.112) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 2 Oct 2019 14:41:22 +0100 From: Andrew Rybchenko To: , , John McNamara , Marko Kovacevic , Thomas Monjalon , Ferruh Yigit CC: References: <20191001185219.5248-1-pbhagavatula@marvell.com> <20191002034716.6842-1-pbhagavatula@marvell.com> <20191002034716.6842-2-pbhagavatula@marvell.com> <3e9d9131-93c4-60b4-44b4-7f553071990b@solarflare.com> Message-ID: <1ea50f42-7e6a-ae14-209a-6535e32c2407@solarflare.com> Date: Wed, 2 Oct 2019 16:41:19 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <3e9d9131-93c4-60b4-44b4-7f553071990b@solarflare.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Originating-IP: [91.220.146.112] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24948.003 X-TM-AS-Result: No-13.739800-8.000000-10 X-TMASE-MatchedRID: nI1cAR4k0HbmLzc6AOD8DfHkpkyUphL9oae+ev6zOlIgVZAf8m502NEi m4gTRv0S0NmT5OIoWwKwYSb8s4Rdab6g3g5+1F/exTpJ3OQjb3dKgIbix5+XxPkuQv9PIVnNUZG E0qUrJUUDuJ5ayjjT0NgR+AcFnYMdZ28ZQS4q9Jw9oFMnLLzjBXkamQDZ6bhfB2QWi8BF5SiKW8 BvXyLiE5VsEH/Nobswf3m9ZmRc/ZEuGJVwjRzMf44VSIjAMorOQaH4g4P6Otbfc2Xd6VJ+yilA/ rS07QvhBhXpKMpfxZr5uD6QwNqXa0legzLj1vIWRpZ38TWrY5zr+i+blgZMaemNd9A84pxf+HmB PyReSgwTTyIOpxLPdCcxuvLRIImpn6Cb4UOqVaAylU6xjA3vw6FCGy3An0bgcBqXYDUNCaxKj9R zqMBfu0CNUamoOHgXwJov9v3WFTT1YpjvL2and8nUT+eskUQPAgvM6h73BtpKddiF2Wo8eSb8s2 NqRSr07c5gh6FjgRoZwn7DIQtGC+RDOJEwZ/POT7O/YHJhINBx4UrJDBdbJg34XnXcobKrbhFmr kG9+jPfPhslDCCNNh0XwFnoQFewv1l2Uvx6idpWdFebWIc3VsRB0bsfrpPIqxB32o9eGck77qjv 6+rnxBKagS1ojlbZu6OgzZhqHjaSputbK4rorDhaDUmazc8x X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--13.739800-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24948.003 X-MDID: 1570023689-bwPyprqGt5Vd Subject: Re: [dpdk-dev] [PATCH v7 1/7] ethdev: add set ptype function X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 10/2/19 4:37 PM, Andrew Rybchenko wrote: > Hi, > > looks good, just few comments below. > > Many thanks for working on it, > Andrew. > > On 10/2/19 6:47 AM, pbhagavatula@marvell.com wrote: >> From: Pavan Nikhilesh >> >> 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 >> Signed-off-by: Pavan Nikhilesh > > [snip] > >> diff --git a/lib/librte_ethdev/rte_ethdev.c >> b/lib/librte_ethdev/rte_ethdev.c >> index 17d183e1f..b1588fe7a 100644 >> --- a/lib/librte_ethdev/rte_ethdev.c >> +++ b/lib/librte_ethdev/rte_ethdev.c >> @@ -2602,6 +2602,56 @@ 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) >> +{ >> +    unsigned int i, j; >> +    struct rte_eth_dev *dev; >> +    const uint32_t *all_ptypes; >> + >> +    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_get, 0); >> + RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_supported_ptypes_set, 0); > > When 0 is returned above, we should set set_ptypes. So, below > check num vs set_types should be done before callbacks check and > I think it is OK to do >       set_ptypes[0] = RTE_PTYPE_UNKNOWN; of course if num > 0 > just after the check. It will allow to simplify code below and will > make it set correctly even if 0 returned because of no callbacks. > >> + >> +    if (num > 0 && set_ptypes == NULL) >> +        return -EINVAL; >> + >> +    if (ptype_mask == 0) { >> +        if (num > 0) >> +            set_ptypes[0] = RTE_PTYPE_UNKNOWN; >> + >> +        return (*dev->dev_ops->dev_supported_ptypes_set)(dev, >> +                ptype_mask); >> +    } >> + >> +    all_ptypes = (*dev->dev_ops->dev_supported_ptypes_get)(dev); >> +    if (all_ptypes == NULL) { >> +        if (num > 0) >> +            set_ptypes[0] = RTE_PTYPE_UNKNOWN; >> + >> +        return 0; >> +    } >> + >> +    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; > > I'd like to repeat my question about insufficient space to return > set_ptypes. Do we need to signal it somehow? If no, it should be > explained why in the comments here. > >> +        } >> +    } >> + >> +    if (set_ptypes != NULL) >> +        set_ptypes[j] = RTE_PTYPE_UNKNOWN; >> + >> +    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 d9871782e..c577a9172 100644 >> --- a/lib/librte_ethdev/rte_ethdev.h >> +++ b/lib/librte_ethdev/rte_ethdev.h >> @@ -2431,6 +2431,42 @@ 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 in which >> + * the recipient is interested. >> + * >> + * 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. >> + * @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 2922d5b7c..93bc34480 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 uint32_t (*eth_dev_supported_ptypes_set_t)(struct >> rte_eth_dev *dev, >> +                          uint32_t ptype_mask); >> +/**< @internal Inform device about packet types in which the >> recipient is interested. */ >> + > > Please, take a look at promiscuous mode callback and let's put > more verbose description here which better document interface > to drivers. I think ptyep_mask description should refer to corresponding > defines to be used. > > [snip] >