From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id 967E744CF for ; Wed, 17 Jan 2018 09:09:00 +0100 (CET) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (webmail.solarflare.com [12.187.104.26]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1-us4.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 5AF2F28006A; Wed, 17 Jan 2018 08:08:59 +0000 (UTC) Received: from [192.168.38.17] (84.52.114.114) by ocex03.SolarFlarecom.com (10.20.40.36) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 17 Jan 2018 00:08:55 -0800 To: Adrien Mazarguil , Qiming Yang CC: References: <20180111160405.182159-1-qiming.yang@intel.com> <20180116155532.GH4256@6wind.com> From: Andrew Rybchenko Message-ID: <829b2bae-3a48-85d0-93ee-e6486726a575@solarflare.com> Date: Wed, 17 Jan 2018 11:08:52 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180116155532.GH4256@6wind.com> Content-Language: en-GB X-Originating-IP: [84.52.114.114] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ocex03.SolarFlarecom.com (10.20.40.36) X-MDID: 1516176540-yIG7uoxyD83O Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [RFC] New packet type query API 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: , X-List-Received-Date: Wed, 17 Jan 2018 08:09:00 -0000 On 01/16/2018 06:55 PM, Adrien Mazarguil wrote: > I understand the motivation behind this proposal, however since new ideas > must be challenged, I have a few comments: > > - How about making packet type recognition an optional offload configurable > per queue like any other (e.g. DEV_RX_OFFLOAD_PTYPE)? That way the extra > processing cost could be avoided for applications that do not care. > > - Depending on HW, packet type information inside RX descriptors may not > necessarily fit 64-bit, or at least not without transformation. This > transformation would still cause wasted cycles on the PMD side. > > - In case enable_ptype_direct is enabled, the PMD may not waste CPU cycles > but the subsequent look-up with the proposed API would translate to a > higher cost on the application side. As a data plane API, how does this > benefit applications that want to retrieve packet type information? > > - Without a dedicated mbuf flag, an application cannot tell whether enclosed > packet type data is in HW format. Even if present, if port information is > discarded or becomes invalid (e.g. mbuf stored in an application queue for > lengthy periods or passed as is to an unrelated application), there is no > way to make sense of the data. > > In my opinion, mbufs should only contain data fields in a standardized > format. Managing packet types like an offload which can be toggled at will > seems to be the best compromise. Thoughts? +1