From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id D517FA0096 for ; Wed, 5 Jun 2019 18:28:16 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B95071BBB4; Wed, 5 Jun 2019 18:28:15 +0200 (CEST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 218C71BA96 for ; Wed, 5 Jun 2019 18:28:14 +0200 (CEST) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 787193086200; Wed, 5 Jun 2019 16:28:13 +0000 (UTC) Received: from [10.36.112.53] (ovpn-112-53.ams2.redhat.com [10.36.112.53]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2AB5E1001E64; Wed, 5 Jun 2019 16:28:11 +0000 (UTC) To: "Stillwell Jr, Paul M" , "Rong, Leyi" , "Zhang, Qi Z" Cc: "dev@dpdk.org" , "Raj, Victor" References: <20190604054248.68510-1-leyi.rong@intel.com> <20190604054248.68510-8-leyi.rong@intel.com> <6dbb719f-0a20-e147-a5b2-eb1f3679631c@redhat.com> <70122f09-000a-52d5-f32f-3f68c25f3822@redhat.com> From: Maxime Coquelin Message-ID: <2bc36e2c-16f7-b4a1-6c93-39eb7fa62a53@redhat.com> Date: Wed, 5 Jun 2019 18:28:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.42]); Wed, 05 Jun 2019 16:28:13 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH 07/49] net/ice/base: replay advanced rule after reset 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 6/5/19 6:16 PM, Stillwell Jr, Paul M wrote: >> -----Original Message----- >> From: Maxime Coquelin >> Sent: Wednesday, June 5, 2019 8:59 AM >> To: Stillwell Jr, Paul M ; Rong, Leyi >> ; Zhang, Qi Z >> Cc: dev@dpdk.org; Raj, Victor >> Subject: Re: [dpdk-dev] [PATCH 07/49] net/ice/base: replay advanced rule >> after reset >> >> >> >> On 6/5/19 5:53 PM, Stillwell Jr, Paul M wrote: >>>>> diff --git a/drivers/net/ice/base/ice_switch.c >>>>> b/drivers/net/ice/base/ice_switch.c >>>>> index c53021aed..ca0497ca7 100644 >>>>> --- a/drivers/net/ice/base/ice_switch.c >>>>> +++ b/drivers/net/ice/base/ice_switch.c >>>>> @@ -3033,6 +3033,27 @@ ice_rem_sw_rule_info(struct ice_hw *hw, >>>> struct LIST_HEAD_TYPE *rule_head) >>>>> } >>>>> } >>>>> >>>>> +/** >>>>> + * ice_rem_adv_rule_info >>>>> + * @hw: pointer to the hardware structure >>>>> + * @rule_head: pointer to the switch list structure that we want to >>>>> +delete */ static void ice_rem_adv_rule_info(struct ice_hw *hw, >>>>> +struct LIST_HEAD_TYPE *rule_head) { >>>>> + struct ice_adv_fltr_mgmt_list_entry *tmp_entry; >>>>> + struct ice_adv_fltr_mgmt_list_entry *lst_itr; >>>>> + >>>>> + if (LIST_EMPTY(rule_head)) >>>>> + return; >>>> >>>> Is it necessary? If the list is empty, LIST_FOR_EACH_ENTRY will not >>>> loop and status will be returned: >>>> >>> Yes, the check is necessary. This code gets consumed by multiple different >> OSs and not all OSs implement the LIST_FOR_EACH_ENTRY_SAFE in the way >> that DPDK did. For example, if I'm understanding the Linux code correctly, >> the list_for_each_entry_safe code in Linux would not work correctly without >> checking LIST_EMPTY since the Linux implementation doesn't have a check >> for null in it's implementation of list_for_each_entry_safe. >> >> Do you mean the same patch is upstreamed into Linux Kernel without any >> adaptations? > > The same patch is planned to be upstreamed in the Linux kernel without any adaptations. Like I said, for Linux you have to check for LIST_EMPTY since the implementation of list_for_each_entry_safe doesn't check for NULL. > OK, thanks for the clarification. That's a surprise to me that OS abstraction layers are now accepted in upstream kernel (Like ice_acquire_lock for instance). Let's drop my comments about LIST_EMPTY then. Maxime