From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f178.google.com (mail-pd0-f178.google.com [209.85.192.178]) by dpdk.org (Postfix) with ESMTP id 27D2D592A for ; Thu, 21 May 2015 20:21:54 +0200 (CEST) Received: by pdbnk13 with SMTP id nk13so116522105pdb.1 for ; Thu, 21 May 2015 11:21:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=fgzUBmma10WoNhMbgLfJ5LuiQJ59ZdJvEZ29JqI/NxQ=; b=fDaKM3y7bEM8DWbS2HUYyj5uGlrYlGwfPupf4qS6zAI8IrHXGHGxG4XAVWnglVp1IU 6CkoYKhsWmL4IjKr+NtfoFB4h47dTwuUL9GVhTz1gPGXBVJZ9KxNpB67HNl4a2mYFhzK NrFxczwuY3GR/dyFg4E69P/8CjMxG3R50KXR4tvMmVYhohUW6qcBmVqqYz2SiDjJj0yH 0bmqtqyHXjtA82HBj0avyBWgiUkSulrtAFbTVc2o91x3micCCCeYHI7HdmMvdQsQ+ZID +NcdEz+x8dx7fbMhCFeqdKdC90vSnlcFqJ1T4tBsIaPNVsifrsN450lBMrfqCjneenv7 PGAQ== X-Gm-Message-State: ALoCoQmuCi2lvyLO0rFCiy8ADMBrYImTUPpAwLB5CpBNFWzxZEice7stHDAXfUY5GZZCvPR4/7jm X-Received: by 10.66.102.103 with SMTP id fn7mr8004561pab.85.1432232513262; Thu, 21 May 2015 11:21:53 -0700 (PDT) Received: from urahara (static-50-53-82-155.bvtn.or.frontiernet.net. [50.53.82.155]) by mx.google.com with ESMTPSA id ph4sm19927875pdb.43.2015.05.21.11.21.52 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 May 2015 11:21:52 -0700 (PDT) Date: Thu, 21 May 2015 11:21:56 -0700 From: Stephen Hemminger To: Neil Horman Message-ID: <20150521112156.3ec24f20@urahara> In-Reply-To: <20150521175846.GB32271@hmsreliant.think-freely.org> References: <1430804386-28949-1-git-send-email-cunming.liang@intel.com> <1432198563-16334-1-git-send-email-cunming.liang@intel.com> <1432198563-16334-2-git-send-email-cunming.liang@intel.com> <20150521103202.GA32271@hmsreliant.think-freely.org> <20150521104300.00757b4e@urahara> <20150521175846.GB32271@hmsreliant.think-freely.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org, liang-min.wang@intel.com Subject: Re: [dpdk-dev] [PATCH v8 01/11] eal/linux: add interrupt vectors support in intr_handle 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: Thu, 21 May 2015 18:21:54 -0000 On Thu, 21 May 2015 13:58:46 -0400 Neil Horman wrote: > On Thu, May 21, 2015 at 10:43:00AM -0700, Stephen Hemminger wrote: > > On Thu, 21 May 2015 06:32:02 -0400 > > Neil Horman wrote: > > > > > On Thu, May 21, 2015 at 04:55:53PM +0800, Cunming Liang wrote: > > > > The patch adds interrupt vectors support in rte_intr_handle. > > > > 'vec_en' is set when interrupt vectors are detected and associated event fds are set. > > > > Those event fds are stored in efds[]. > > > > 'intr_vec' is reserved for device driver to initialize the vector mapping table. > > > > When the event fds add to a specified epoll instance, 'elist' will hold the rte_epoll_event object pointer. > > > > > > > > Signed-off-by: Danny Zhou > > > > Signed-off-by: Cunming Liang > > > > --- > > > > v7 changes: > > > > - add eptrs[], it's used to store the register rte_epoll_event instances. > > > > - add vec_en, to log the vector capability status. > > > > > > > > v6 changes: > > > > - add mapping table between irq vector number and queue id. > > > > > > > > v5 changes: > > > > - Create this new patch file for changed struct rte_intr_handle that > > > > other patches depend on, to avoid breaking git bisect. > > > > > > > > lib/librte_eal/linuxapp/eal/include/exec-env/rte_interrupts.h | 10 ++++++++++ > > > > 1 file changed, 10 insertions(+) > > > > > > > > diff --git a/lib/librte_eal/linuxapp/eal/include/exec-env/rte_interrupts.h b/lib/librte_eal/linuxapp/eal/include/exec-env/rte_interrupts.h > > > > index 6a159c7..27174df 100644 > > > > --- a/lib/librte_eal/linuxapp/eal/include/exec-env/rte_interrupts.h > > > > +++ b/lib/librte_eal/linuxapp/eal/include/exec-env/rte_interrupts.h > > > > @@ -38,6 +38,8 @@ > > > > #ifndef _RTE_LINUXAPP_INTERRUPTS_H_ > > > > #define _RTE_LINUXAPP_INTERRUPTS_H_ > > > > > > > > +#define RTE_MAX_RXTX_INTR_VEC_ID 32 > > > > + > > > > enum rte_intr_handle_type { > > > > RTE_INTR_HANDLE_UNKNOWN = 0, > > > > RTE_INTR_HANDLE_UIO, /**< uio device handle */ > > > > @@ -48,6 +50,8 @@ enum rte_intr_handle_type { > > > > RTE_INTR_HANDLE_MAX > > > > }; > > > > > > > > +struct rte_epoll_event; > > > > + > > > > /** Handle for interrupts. */ > > > > struct rte_intr_handle { > > > > union { > > > > @@ -57,6 +61,12 @@ struct rte_intr_handle { > > > > }; > > > > int fd; /**< interrupt event file descriptor */ > > > > enum rte_intr_handle_type type; /**< handle type */ > > > > + uint32_t max_intr; /**< max interrupt requested */ > > > > + uint32_t nb_efd; /**< number of available efds */ > > > > + int efds[RTE_MAX_RXTX_INTR_VEC_ID]; /**< intr vectors/efds mapping */ > > > > + struct rte_epoll_event *elist[RTE_MAX_RXTX_INTR_VEC_ID]; > > > > + /**< intr vector epoll event ptr */ > > > > + int *intr_vec; /**< intr vector number array */ > > > > }; > > > > > > > > > > This is going to be ABI breaking if this from test_interrupts.c: > > > static struct rte_intr_handle intr_handles[TEST_INTERRUPT_HANDLE_MAX]; > > > > > > is a plausible way of using this structure. Even putting the data at the end of > > > the structure won't help, as the array indicies are off > > > > This needs to go in 2.0 and 2.0 has to have new ABI anyway. > > > We've already released 2.0, I think you mean 2.1, but 2.1 can't have a new ABI > because we didn't announce it in 1.8. The earliest we can update the ABI > (according to the ABI docs) at this point is 2.2, since we need to announce the > change in 2.1, then make it in 2.2 > > Neil > Then just skip 2.1 (or make it a trivial doc change only dummy release), and call it 2.2. I guess we need to proactively say every .x release will have new ABI. Sorry, this is a project under development.