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 F0963A00E6 for ; Tue, 6 Aug 2019 20:03:18 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E67181B502; Tue, 6 Aug 2019 20:03:17 +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 100431B197 for ; Tue, 6 Aug 2019 20:03:15 +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-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id AC7B9780095; Tue, 6 Aug 2019 18:03:12 +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 19:03:06 +0100 To: Stephen Hemminger , "Pavan Nikhilesh Bhagavatula" CC: Jerin Jacob Kollanukkaran , John McNamara , Marko Kovacevic , Thomas Monjalon , Ferruh Yigit , "dev@dpdk.org" References: <20190806080206.1572-1-pbhagavatula@marvell.com> <20190806080206.1572-2-pbhagavatula@marvell.com> <798d0b07-9196-2b60-b395-ac5f01c391d7@solarflare.com> <20190806084527.0bce82d0@hermes.lan> From: Andrew Rybchenko Message-ID: Date: Tue, 6 Aug 2019 21:03:00 +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: <20190806084527.0bce82d0@hermes.lan> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit 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-6.431600-8.000000-10 X-TMASE-MatchedRID: C/snMIRQLS34ECMHJTM/ufZvT2zYoYOwt3aeg7g/usAutoY2UtFqGPgF luM+m+tyZnH9wlvrd9uYZfjORODtZQkGWAZ8v6JzR/j040fRFpIHmzHO3TfA+Hy/Hx1AgJrrstf L6WfCYzEKjaciaHASErS4DVkNpT/jOpPA8Ci9bQTzZhlMHRv4r2fQgc3VUSnOV8ukjx868O6UR6 6C6i5v861u9NkuhgWrb/sbz+8ciHMoikPnYXaki2si7j4330URt8cKn575yh5Bbp4JobErAizkC joQnhrcs8gqOsWgajI5FQfDpmxqT642liFPoJXkFvAJe/W5wA/Llinyo+kVDw6Sf7VOHCs52ZM4 dOAJvFDjSRS+xnOgRyED+vu0gS8uQBI3/CURWxyTeuX4xo2DECWo4o4gXl+Qilzcm2p6JE+PGut TIsMtmibOLM/JoFlQLAkCfScZ628VPUnG14+rRA0QY5VnQyAN5GNdGhmNEOGbKItl61J/ybLn+0 Vm71Lcq7rFUcuGp/FYF3qW3Je6+7W3ywXtKp4xt8jUFVCup7MFXdy0pJ8r1ntH3H4XM0FdWn25s RAayq4P7Y7YYz8xBoE5flFTRfERrJfmIvxx8vXCBc//bzru0fAdfn5DyOPDXC6uJnc/p0Ssglkl tB8xdGpozkualSTDO6clcnPxfVB+3BndfXUhXQ== X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--6.431600-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24824.003 X-MDID: 1565114593-AtXSauzIiQJR Subject: Re: [dpdk-dev] [EXT] Re: [RFC 1/3] ethdev: add ptype as an 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 6:45 PM, Stephen Hemminger wrote: > On Tue, 6 Aug 2019 14:31:43 +0000 > Pavan Nikhilesh Bhagavatula wrote: > >>> -----Original Message----- >>> From: Andrew Rybchenko >>> Sent: Tuesday, August 6, 2019 2:30 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] [RFC 1/3] ethdev: add ptype as an Rx >>> offload >>> >>> External Email >>> >>> ---------------------------------------------------------------------- >>> On 8/6/19 11:02 AM, pbhagavatula@marvell.com wrote: >>>> From: Pavan Nikhilesh >>>> >>>> Add ptype to DEV_RX_OFFLOAD_* flags which can be used to >>> enable/disable >>>> packet type parsing. >>>> >>>> Signed-off-by: Pavan Nikhilesh >>> I like the idea. I think there are few more Rx features which >>> lack Rx offload bit: >>>  - delivery of RSS hash in mbuf (it is not always required when >>>    RSS is used to distribute packets across Rx queues) >> Especially when applications use custom hash functions to store flows. >> >>>  - maybe Rx mark, since it is an extra information which could >>>    be passed by NIC to CPU and it is better to know in advance >>>    at Rx queue setup if it should be requested and processed >> Are you referring to RTE_FLOW_ACTION_TYPE_MARK? >> >>> API breakage should be considered here. I think it is OK to >>> introduce it in the next release cycle in a dummy way which >>> does not affect packet type delivery for existing PMDs >>> (i.e. add offload capability and advertise in PMD, but do not >>> take it into account when Rx mbuf is filled in) and >>> submit deprecation notice that it may be taken into account >>> by PMDs in 20.02 to avoid packet type delivery if the offload >>> is not requested. It will allow applications to make transition >>> smoother. >> Couldn’t agree with you more. I could extend the current RFC to include >> RSS and RX mark as we would be modifying the same offload fields across >> all drivers. Easier for PMD maintainers too. >> >>> Acked-by: Andrew Rybchenko > I would rather the ptype offload be always on and handled in software > for drivers that don't do it. It sounds like wasting of CPU cycle for nothing in some cases. Also where should software stop? There are various tunnels etc. If application is unhappy with supported classification provided by the driver, it can always use software parser if really required.