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 593CBF72; Sun, 12 Aug 2018 09:53:43 +0200 (CEST) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (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 28791B00066; Sun, 12 Aug 2018 07:53:42 +0000 (UTC) Received: from [192.168.1.16] (85.187.13.33) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Sun, 12 Aug 2018 08:53:19 +0100 To: Shahaf Shuler , Ferruh Yigit , Wei Zhao , "dev@dpdk.org" CC: "stable@dpdk.org" , Wenzhuo Lu References: <1532399811-52078-1-git-send-email-wei.zhao1@intel.com> From: Andrew Rybchenko Message-ID: <0f570014-6212-43d8-6947-fdbc22f1b7b4@solarflare.com> Date: Sun, 12 Aug 2018 10:52:50 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 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.33] 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-24026.003 X-TM-AS-Result: No-15.348200-8.000000-10 X-TMASE-MatchedRID: vEvJ7Rh1lGgOwH4pD14DsPHkpkyUphL9KOUfwPQyeFe1eX0jEQ9c6loq G7y2r1FiLOEx+hvEk7mgglhSgkQaQCECbd58CcPwTd1FGyH+HrIhotH7bEpEMmyZJ8/t392lYjj gSj+5At6QMIH3oTOLow8dteYFcHKI36/+PA3w/Ir0AHJaqpkQfHnL427v8Q46ymP/1piI/6E13c +d+aFMp+SLOd0ESvThWdeRBH74lRlCR/FskDJObhHRbGr1ECgHW1VjHhznmWggUEQTkIWiYsTrc lOEW8K1xL6yilzV9SJeKXnh1H8sGxCeHOe0i1J8XP5rFAucBUGUi9wB9gmcSsY/Qxi9/1Jciqr8 0tignQ6VMP2R4HFV3KmKgPDizPzWNyl1nd9CIt05f9Xw/xqKXVkMvWAuahr83Mh122xXdCt4N1j hRVQFLSAHAopEd76veV8ozMmCD1YOrVFguDBp/Q1JXd1DQ8N2q5lHKdsr3A64sp+NDzjVdA== X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--15.348200-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24026.003 X-MDID: 1534060422-O7Hbz1EJDoer Subject: Re: [dpdk-dev] [PATCH] net/ixgbe: remove hardcoded CRC STRIP config from ixgbe 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: Sun, 12 Aug 2018 07:53:43 -0000 On 12.08.2018 09:28, Shahaf Shuler wrote: > Thursday, August 9, 2018 11:32 AM, Ferruh Yigit: >> Subject: Re: [PATCH] net/ixgbe: remove hardcoded CRC STRIP config from >> ixgbe >> >> On 7/24/2018 3:36 AM, Wei Zhao wrote: >>> There is CRC related ifdefs for ixgbe: >>> CONFIG_RTE_LIBRTE_IXGBE_PF_DISABLE_STRIP_CRC=n >>> It is used in VF drivers ixgbevf_dev_configure() functions. >>> VF cannot change the CRC strip behavior and based on what PF >>> configured it needs to response proper to user >>> ixgbevf_dev_configure() request. Right now what PF set is defined by >>> above config options but this method is too static. >>> >>> Signed-off-by: Wei Zhao >>> Signed-off-by: Wenzhuo Lu >> <...> >>> @@ -334,6 +334,7 @@ struct rte_eth_rxmode { >>> * structure are allowed to be set. >>> */ >>> uint64_t offloads; >>> + uint64_t offloads_disable; >> Do we need a disable flag in ethdev, an offload not enabled is disabled by >> default isn't it. This conflicts with offloads flag and makes is confusing. > +1. > > **all** the offloads are disabled by default. > >> For igb/e1000 VF case, VF driver can't change what PF set and VF driver can't >> learn the PF setting dynamically, so this information needs to be passed to VF >> driver by application/user. >> Currently this information passed by compile time config option, my >> suggestion was using devargs. >> >> In your implementation testpmd parameter added to get this information >> and pass to driver, but this means all applications needs to do this, instead >> adding this support to driver looks better to me. I think we should add fixed offloads to dev_info. I.e. if offlload is supported, it could be marked as fixed (i.e. always enabled). If offload is not supported, it is always disabled (and cannot/should not be marked as fixed). May be the right name for it is not "fixed", but "always_enabled". Also it should be persistent. It should not be allowed in above ixgbe case to change the offload state on PF if there are other users (drivers attached). Otherwise, we need mechanism to notify apps about these changes - overcomplicated.