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 18197239 for ; Mon, 27 Nov 2017 08:40:25 +0100 (CET) Received: from pure.maildistiller.com (unknown [10.110.50.29]) by dispatch1-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTP id 57331200BA; Mon, 27 Nov 2017 07:40:25 +0000 (UTC) X-Virus-Scanned: Proofpoint Essentials engine Received: from mx1-us4.ppe-hosted.com (unknown [10.110.49.251]) by pure.maildistiller.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 8175C22004D; Mon, 27 Nov 2017 07:40:24 +0000 (UTC) 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 2409A280055; Mon, 27 Nov 2017 07:40:24 +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; Sun, 26 Nov 2017 23:40:16 -0800 To: Shahaf Shuler , "dev@dpdk.org" References: <20171123121419.144132-1-shahafs@mellanox.com> <20171123121419.144132-2-shahafs@mellanox.com> <7229daf4-fffd-764c-ec0f-b30e8be39af3@solarflare.com> From: Andrew Rybchenko CC: Ferruh Yigit , Thomas Monjalon , Bruce Richardson , Pablo de Lara Guarch , Stephen Hurd , Ajit Khaparde , Qi Zhang , Xiao Wang , Jingjing Wu , Beilei Xing , Wenzhuo Lu , Konstantin Ananyev , Adrien Mazarguil , Nelio Laranjeiro , Alejandro Lucero , Rasesh Mody , Harish Patil , Shahed Shaikh , Yuanhan Liu , Maxime Coquelin , Jerin Jacob , Maciej Czekaj , Santosh Shukla Message-ID: <72a5782d-3f6f-c713-0849-7b75a84a7a29@solarflare.com> Date: Mon, 27 Nov 2017 10:40:13 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: 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: 1511768425-o7UdvbScX89k Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH 01/39] examples/l2fwd: convert to new ethdev offloads 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: Mon, 27 Nov 2017 07:40:26 -0000 On 11/27/2017 10:03 AM, Shahaf Shuler wrote: > > Monday, November 27, 2017 8:35 AM, Andrew Rybchenko: > > Yes this is right. Not exposing the CRC offload flag means the device > don’t support CRC strip toggling, however it does not explicitly say > if device always strip/not. > > I guess device that has such limitation should specify it on the > “Limitation” section of the PMD guide. > > If it is interpreted in such way it sounds like loss of functionality. > Don't think it is a good way to rely on documentation here. It should > be more reliable way. PMD still can check if offload is not enabled and > complain, but there is no way to say that it is strictly required. > As I understand similar things are covered with so-called fixed offloads > in Linux. > > Can you elaborate which functionality is being lost here? > > If your suggestion is for the PMD to force the CRC STRIP offload in > case it is not supporting **not** to strip CRC then I am OK with that. > [AR] I mean that if we say that no CRC strip offload set means either strip or not-strip it is bad. Application and transmit part may rely on Ethernet CRC presence. My suggestion is to provide a way to say that CRC striping (and any other offload) cannot be disabled. > > Yes it is. > > With the new Tx offloads API the application can choose the Tx > offloads it wants to use according to its needs. > > For l2fwd case – it doesn’t use any of them. Any default txq flag the > PMD set there is irrelevant. > > What I tried to do is not to preserve the entire old behavior rather > to evolve the examples/applications while keeping the same > functionality (i.e. the offloads which the application use are set, > the rest are not). > > > That's true for checksum and VLAN offloads, but false for fast-free. > As I understand l2fwd and many other examples meet fast-free > requirements and if PMD supports it, it should be used since it will > show better performance results. > > I agree about the Fast free offload. However IMO such optimization can > be introduced on other series which further more optimize the > performance of such applications, what do you think? > [AR] If so, it is definitely a loss of functionality here. Since before the patch PMD can provide default TxQ flags and usage of these flags will allow an application to see the best performance. (Yes, if it was bad if application blindly use these flags). May be it should be covered by separate patches, but hanging it in the air for a long time is bad. I definitely would like to hear more opinions here from example application and PMD maintainers.