From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) by dpdk.org (Postfix) with ESMTP id 340E51559 for ; Mon, 27 Nov 2017 07:34:55 +0100 (CET) Received: from pure.maildistiller.com (dispatch1.mdlocal [10.7.20.164]) by dispatch1-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTP id 9A0F2600B2; Mon, 27 Nov 2017 06:34:54 +0000 (UTC) X-Virus-Scanned: Proofpoint Essentials engine Received: from mx1-us1.ppe-hosted.com (us4-filterqueue.mdlocal [10.7.20.246]) by pure.maildistiller.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 0058928004D; Mon, 27 Nov 2017 06:34:54 +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-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id DC8A610007B; Mon, 27 Nov 2017 06:34:53 +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 22:34:50 -0800 To: Shahaf Shuler , "dev@dpdk.org" References: <20171123121419.144132-1-shahafs@mellanox.com> <20171123121419.144132-2-shahafs@mellanox.com> From: Andrew Rybchenko Message-ID: <7229daf4-fffd-764c-ec0f-b30e8be39af3@solarflare.com> Date: Mon, 27 Nov 2017 09:34:47 +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: 1511764494-YZADfA0siZC5 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 06:34:55 -0000 On 11/26/2017 10:41 AM, Shahaf Shuler wrote: > >>+            .ignore_offload_bitfield = 1, > >>+            .offloads = DEV_RX_OFFLOAD_CRC_STRIP, > > > > >It is not directly related to the patch. > >May be I miss something, but it looks like there is no way to say that > >"I always strip CRC and cannot preserve it". > > 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. > >>+            txq_conf = dev_info.default_txconf; > >>+            txq_conf.txq_flags = ETH_TXQ_FLAGS_IGNORE; > >>+            txq_conf.offloads = port_conf.txmode.offloads; > > > > >It looks like it is not 100% equivalent. As far as I can see dev_info > get does > >not convert txq_flags to offloads in default_txconf and in any case > txq_conf.offloads > >are overwritten here. So, if PMD provides default txq_flags, it is lost. > >If it is intentionally, it should be highlighted and explained. > > 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. > Moreover – it is a wrong approach, IMO, that the PMD set default > offloads flags to the application. It has no knowledge to do so. I > think this mechanism was initially created since the Tx offloads were > all set by default, so it provided a mean to have good OOB > configuration. Now when all offloads are set, I am not sure such API > is needed anymore. > > Will be happy to hear more opinion on that. > I agree that blindly using PMD default offloads is a wrong approach.