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 C44B23B5 for ; Wed, 4 Mar 2015 04:20:35 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 03 Mar 2015 19:20:34 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,685,1418112000"; d="scan'208";a="693626844" Received: from shwdeisgchi017.ccr.corp.intel.com (HELO [10.239.66.47]) ([10.239.66.47]) by orsmga002.jf.intel.com with ESMTP; 03 Mar 2015 19:20:33 -0800 Message-ID: <54F67A00.9030201@intel.com> Date: Wed, 04 Mar 2015 11:20:32 +0800 From: "Liang, Cunming" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Stephen Hemminger , David Marchand References: <1424710542-14637-1-git-send-email-danny.zhou@intel.com> <1425012976-10173-1-git-send-email-cunming.liang@intel.com> <20150303165257.7b7d0cd1@urahara> In-Reply-To: <20150303165257.7b7d0cd1@urahara> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v6 0/8] Interrupt mode PMD 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: Wed, 04 Mar 2015 03:20:36 -0000 Hi Stephen, On 3/4/2015 8:52 AM, Stephen Hemminger wrote: > On Fri, 27 Feb 2015 11:38:25 +0100 > David Marchand wrote: > >> Ok, so after looking at this patchset, I would say this is the right direction, but still this is too limited. >> The ethdev part and the vfio eventfds part look acceptable to me. >> But thinking about it, I could just reuse a standard event library with the eventfds I would get from ethdev without a need for a new eal api. > I would prefer that there was just an fd and a callback. > An application should be able to use what ever event model or library it wants. [LCM] I agree, on application perspective it is. As it's easy to get RX/TX interrupt fd, there's no limit for application to do all the things with the 3rd party event library. The improvement probably be 1) a rte_intr_vec_to_fd() API; 2) expose eal_intr_process_rxtx_interrupts() as a public API for RX/TX interrupt callback. However, it should allow to use the packet interrupt feature in case application don't choose any 3rd party event library. That's the motivation to give a very lightweight 'wait' EAL API. Sounds reasonable ? > > IMHO the existing interrupt thread model is incorrectly designed and creates > lots of opportunities for races because of that. Look at the effort it has to > use to pass the event back to link state code.