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 B357BA2EDB for ; Tue, 1 Oct 2019 10:02:24 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id EB9A84CA6; Tue, 1 Oct 2019 10:02:23 +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 F0DB94C99 for ; Tue, 1 Oct 2019 10:02:22 +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 4BD164005C; Tue, 1 Oct 2019 08:02:20 +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; Tue, 1 Oct 2019 09:02:13 +0100 To: Pavan Nikhilesh Bhagavatula , "Jerin Jacob Kollanukkaran" , John McNamara , Marko Kovacevic , Thomas Monjalon , Ferruh Yigit CC: "dev@dpdk.org" References: From: Andrew Rybchenko Message-ID: <03f7f6ed-2b39-6576-ad1c-80fd981f35af@solarflare.com> Date: Tue, 1 Oct 2019 11:02:09 +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: 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-24946.003 X-TM-AS-Result: No-8.166200-8.000000-10 X-TMASE-MatchedRID: HXSqh3WYKfvmLzc6AOD8DfHkpkyUphL9Ud7Bjfo+5jTVEYfep7SzppWi xnDxF7NQtqy4fGtVdQqTH1CW/Tkdqh8owvkAm18tdhnFihmbnwVezmeoa8MJ85h4xM9oAcstXj9 brjtcRMvPgCh0lH02PwKD9eSpRMSaWODl9f4jD9EHRzaQbsazqLvGYJkNeu61DpCUEeEFm7CYOC eSu+37OpuxZiSeQrcYOO5vNUOII4IuGJVwjRzMf/ChiQolft/yy5s5a9BIzjabKItl61J/ybLn+ 0Vm71Lcq7rFUcuGp/EnRE+fI6etksBZ5NypywmR51XIh8/aGBZPWuD5kBor99Uq81+1UNqVB+v2 eezkrWdDOKpOgsIionYZb8E7kRq+pQ6eZCOaT6WwxMDYnZPngPAdfn5DyOPDXC6uJnc/p0Ssglk ltB8xdGpozkualSTDOvxFSbveVNw= X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--8.166200-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24946.003 X-MDID: 1569916942-fSzxpHWV-nSt Subject: Re: [dpdk-dev] [PATCH v4 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/1/19 10:36 AM, Pavan Nikhilesh Bhagavatula wrote: >> -----Original Message----- >> From: Andrew Rybchenko >> Sent: Tuesday, October 1, 2019 12:34 PM >> To: Pavan Nikhilesh Bhagavatula ; Jerin >> Jacob Kollanukkaran ; John McNamara >> ; Marko Kovacevic >> ; Thomas Monjalon >> ; Ferruh Yigit >> Cc: dev@dpdk.org >> Subject: [EXT] Re: [dpdk-dev] [PATCH v4 1/7] ethdev: add set ptype >> function >> On 10/1/19 9:34 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] >>> + if (ptype_mask & all_ptypes[i]) { >> Should it be done if all_ptypes[i] have some bits out of ptype_mask? >> Should set_ptypes have bits out of ptype_mask when set below? >> > Isn't all_ptypes[i] enum?. It makes sense if it's a bit mask. > Get ptypes has a similar logic. My bad. You're right.