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 13001A00E6 for ; Tue, 6 Aug 2019 11:06:49 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id EE4071BDFF; Tue, 6 Aug 2019 11:06:48 +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 B14614C80 for ; Tue, 6 Aug 2019 11:06:46 +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-us4.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id 90BCAB40069; Tue, 6 Aug 2019 09:06:45 +0000 (UTC) Received: from [192.168.1.11] (85.187.13.152) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 6 Aug 2019 10:06:40 +0100 To: Pavan Nikhilesh Bhagavatula , Hemant Agrawal , Jerin Jacob Kollanukkaran CC: "dev@dpdk.org" References: <20190806080206.1572-1-pbhagavatula@marvell.com> From: Andrew Rybchenko Message-ID: <93b4326d-6eb2-4f31-44bf-b9dd7e91aac4@solarflare.com> Date: Tue, 6 Aug 2019 12:06:35 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [85.187.13.152] 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-24824.003 X-TM-AS-Result: No-0.051000-8.000000-10 X-TMASE-MatchedRID: UuaOI1zLN1j4ECMHJTM/ufZvT2zYoYOwt3aeg7g/usAutoY2UtFqGBlg ra56oHr6qmgjSDIYwlA8GNWjfeMm9aqkg+o+yGWucI7vRACwF0IHgh3sKJBzP6ZqsdAj8YIt4vF 69pWV59G39IjDtOCtdWJES4eKERjmmz6Ddn99ld1hXXywTJLpfDuDayXS0LqB5wA4LRxAiq9ueM FwDJsv/I21Kobj+A4Brs4c77Ktk7VUIV59BFXczhFnPs2NvAjSWNbBpQ++I1mZt08TfNy6OIgnL dHU7oiOCKRTUHgPhBxTeY5oKlk6L87krHcMds8IZdorcofH/GkPo0vi0aZfNYJMlS+kMGbcbIBu 7UhxFGuCy9cjC4gSrZGTpe1iiCJq71zr0FZRMbAPXo4gvwUD3foA9r2LThYYKrauXd3MZDXQEsT eiCm2ltvSOnEXrO8jV28pyHnLtsDUeIyCa831NR/YVmB257KwD9uwslP+jgccmIz2ANP3ptkL1h Nsg5b4lFpU2By2/mNTSJHI6UYUqwbEQIfFpkwHBtlgFh29qnpKzBwu5JpklicuA5lkRJwA73QlC BbmrKs= X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10-0.051000-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24824.003 X-MDID: 1565082406-e_NW0fBi1IK2 Subject: Re: [dpdk-dev] [RFC 0/3] ethdev: add ptype as Rx offload 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 8/6/19 11:47 AM, Pavan Nikhilesh Bhagavatula wrote: > >> -----Original Message----- >> From: Hemant Agrawal >> Sent: Tuesday, August 6, 2019 1:49 PM >> To: Pavan Nikhilesh Bhagavatula ; Jerin >> Jacob Kollanukkaran >> Cc: dev@dpdk.org >> Subject: RE: [dpdk-dev] [RFC 0/3] ethdev: add ptype as Rx offload >>> Add PTYPE to DEV_RX_OFFLOAD_* flags. >>> >>> Currently, most of the NICs already support PTYPE parsing and update >> the >>> mbuf->packet_type through an internal lookup table, but there is no >> way to >>> disable the lookup if the application is not intrested in ptypes >> returned by >>> `rte_eth_dev_get_supported_ptypes`. >>> >> [Hemant] it will also mean introducing another check in datapath, if the >> application has asked for PTYPE offload - copy the results to mbuf- >>> packet_type otherwise don't do it. > I think that having the check would give better performance than loading ptype table to L1 > doing a lookup and copying it to mbuf when the application doesn't need it. Anyway, if PMD decides that it is better to always provide packet type information - there is no harm. Basically if the offload is not requested it makes packet_type undefined in mbuf. >> Your second patch is incomplete in the sense that it only adds the >> capability. But it does not disable the lookups? > It is upto the maintainer of the PMD to disable the lookup in data path. If there is a scope of optimization > then they could do it. There is no harm in exposing PTYPE even RX_OFFLOAD_PTYPE is not enabled. > I was hesitant to touch data path as it would be impossible to verify performance effect on all NICs. I think it is the right way to approach it especially taking transition into account.