From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id AC03E2E81 for ; Mon, 22 Sep 2014 08:20:22 +0200 (CEST) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by orsmga101.jf.intel.com with ESMTP; 21 Sep 2014 23:26:24 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.04,570,1406617200"; d="scan'208";a="479101441" Received: from irsmsx103.ger.corp.intel.com ([163.33.3.157]) by azsmga001.ch.intel.com with ESMTP; 21 Sep 2014 23:26:23 -0700 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.24]) by IRSMSX103.ger.corp.intel.com ([169.254.3.112]) with mapi id 14.03.0195.001; Mon, 22 Sep 2014 07:26:22 +0100 From: "Wodkowski, PawelX" To: Neil Horman Thread-Topic: [dpdk-dev] [PATCH 2/2] bond: add mode 4 support Thread-Index: AQHP0oLWm9lr6LYAYECquqxpYdLEtpwFXfgAgAEYBtCAAIgjAIABXSYAgABNXYCABAzrYA== Date: Mon, 22 Sep 2014 06:26:21 +0000 Message-ID: References: <1410963713-13837-1-git-send-email-pawelx.wodkowski@intel.com> <1410963713-13837-3-git-send-email-pawelx.wodkowski@intel.com> <20140917151304.GD4213@localhost.localdomain> <20140918160234.GJ20389@hmsreliant.think-freely.org> <20140919172907.GE12897@hmsreliant.think-freely.org> In-Reply-To: <20140919172907.GE12897@hmsreliant.think-freely.org> Accept-Language: pl-PL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" , "Jastrzebski, MichalX K" Subject: Re: [dpdk-dev] [PATCH 2/2] bond: add mode 4 support X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 06:20:23 -0000 > I think that will work, but I believe you're making it more complicated (= and > less reusable) than it needs to be. What I think you really need to do i= s > create a new rte api call, rte_eal_alarm_cancel_sync (something like the > equivalent of del_timer_sync in linux, that wraps up the > while(rte_eal_alarm_cancel(...) =3D=3D 0) {rte_pause} in its own function= (so other > call sites can use it, as I don't think this is an uncommon problem), The= n just > create a bonding-internal state flag to signal the periodic callback that= it > shouldn't re-arm the timer. That way all you have to do is set the flag,= and > call rte_eal_alarm_cancel_sync, and you're done. And other applications = will be > able to handle this common type of operation as well >=20 > Neil I agree with you that alarms should be upgraded but this need to discussed = and=20 tested. Now there is not time for that. Thank you Pawel