Message ID | D0158A423229094DA7ABF71CF2FA0DA3118DFBF1@shsmsx102.ccr.corp.intel.com (mailing list archive) |
---|---|
State | Not Applicable, archived |
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [IPv6:::1]) by dpdk.org (Postfix) with ESMTP id DA3DC376E; Fri, 27 Feb 2015 12:28:39 +0100 (CET) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 2CD933005 for <dev@dpdk.org>; Fri, 27 Feb 2015 12:28:38 +0100 (CET) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 27 Feb 2015 03:28:37 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,659,1418112000"; d="scan'208,217";a="658047598" Received: from pgsmsx102.gar.corp.intel.com ([10.221.44.80]) by orsmga001.jf.intel.com with ESMTP; 27 Feb 2015 03:28:35 -0800 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 27 Feb 2015 19:28:33 +0800 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.62]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.192]) with mapi id 14.03.0195.001; Fri, 27 Feb 2015 19:28:32 +0800 From: "Liang, Cunming" <cunming.liang@intel.com> To: David Marchand <david.marchand@6wind.com> Thread-Topic: [PATCH v6 2/8] eal/linux: add rx queue interrupt FDs to intr handle struct Thread-Index: AQHQUknM7XNEbaTL6UC2u7dZmgB1uJ0DxuUAgACUNbA= Date: Fri, 27 Feb 2015 11:28:31 +0000 Message-ID: <D0158A423229094DA7ABF71CF2FA0DA3118DFBF1@shsmsx102.ccr.corp.intel.com> References: <1424710542-14637-1-git-send-email-danny.zhou@intel.com> <1425012976-10173-1-git-send-email-cunming.liang@intel.com> <1425012976-10173-3-git-send-email-cunming.liang@intel.com> <CALwxeUtr8iUCjroCf0ix0PPU2ers3EgTeTT6XUDAgwmwsOBS6Q@mail.gmail.com> In-Reply-To: <CALwxeUtr8iUCjroCf0ix0PPU2ers3EgTeTT6XUDAgwmwsOBS6Q@mail.gmail.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: "dev@dpdk.org" <dev@dpdk.org> Subject: Re: [dpdk-dev] [PATCH v6 2/8] eal/linux: add rx queue interrupt FDs to intr handle struct X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
Commit Message
Cunming Liang
Feb. 27, 2015, 11:28 a.m. UTC
From: David Marchand [mailto:david.marchand@6wind.com] Sent: Friday, February 27, 2015 6:33 PM To: Liang, Cunming Cc: dev@dpdk.org; Stephen Hemminger; Thomas Monjalon; Zhou, Danny Subject: Re: [PATCH v6 2/8] eal/linux: add rx queue interrupt FDs to intr handle struct Hello, On Fri, Feb 27, 2015 at 5:56 AM, Cunming Liang <cunming.liang@intel.com<mailto:cunming.liang@intel.com>> wrote: Per vector event fd will store in rte_intr_handle during init. Device drivers take responsibility to fill queue-vec mapping table(vec_num[]). Signed-off-by: Danny Zhou <danny.zhou@intel.com<mailto:danny.zhou@intel.com>> Signed-off-by: Cunming Liang <cunming.liang@intel.com<mailto:cunming.liang@intel.com>> --- v6 changes: - add mapping table between irq vector number and queue id. Ok, you will store vfio eventfds here, but vfio is an implementation, not the abstraction. [Liang, Cunming] If looking at the rte_intr_hanle_type, it includes UIO/VFIO_LEGACY/VFIO_MSI/VFIO_MSIX. I agree, VFIO is an implementation, but the different type combination is a kind of ‘abstraction’. So in rte_intr_handle (like a multiplexing), some specified field for vfio interrupter mapping, I feel it’s reasonable. -- David Marchand
Comments
2015-02-27 11:28, Liang, Cunming: > From: David Marchand [mailto:david.marchand@6wind.com] > Sent: Friday, February 27, 2015 6:33 PM > On Fri, Feb 27, 2015 at 5:56 AM, Cunming Liang <cunming.liang@intel.com<mailto:cunming.liang@intel.com>> wrote: > > --- 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,9 @@ > > > > #ifndef _RTE_LINUXAPP_INTERRUPTS_H_ > > #define _RTE_LINUXAPP_INTERRUPTS_H_ > > > > +#define VFIO_MAX_RXTX_INTR_ID 32 > > +#define VFIO_MAX_QUEUE_ID VFIO_MAX_RXTX_INTR_ID> > This is a little weird to talk about vfio here. > This file is "generic". > > Ok, you will store vfio eventfds here, but vfio is an implementation, not the abstraction. > [Liang, Cunming] If looking at the rte_intr_hanle_type, it includes UIO/VFIO_LEGACY/VFIO_MSI/VFIO_MSIX. > I agree, VFIO is an implementation, but the different type combination is a kind of ‘abstraction’. > So in rte_intr_handle (like a multiplexing), some specified field for vfio interrupter mapping, I feel it’s reasonable. > > > -- > David Marchand >
2015-02-27 11:28, Liang, Cunming: > From: David Marchand [mailto:david.marchand@6wind.com] > Sent: Friday, February 27, 2015 6:33 PM > > On Fri, Feb 27, 2015 at 5:56 AM, Cunming Liang wrote: > > > --- 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,9 @@ > > > > > > #ifndef _RTE_LINUXAPP_INTERRUPTS_H_ > > > #define _RTE_LINUXAPP_INTERRUPTS_H_ > > > > > > +#define VFIO_MAX_RXTX_INTR_ID 32 > > > +#define VFIO_MAX_QUEUE_ID VFIO_MAX_RXTX_INTR_ID > > > > This is a little weird to talk about vfio here. > > This file is "generic". > > > > Ok, you will store vfio eventfds here, but vfio is an implementation, > > not the abstraction. > > [Liang, Cunming] If looking at the rte_intr_hanle_type, it includes UIO/VFIO_LEGACY/VFIO_MSI/VFIO_MSIX. > I agree, VFIO is an implementation, but the different type combination is a kind of ‘abstraction’. > So in rte_intr_handle (like a multiplexing), some specified field for vfio interrupter mapping, I feel it’s reasonable. Not sure to understand. Are we trying to mask the different kernel drivers from an application point of view, and provide a generic interrupt mechanism? If yes, why some VFIO constants are needed? I'm not saying that the current implementation is perfect, but we should try to improve it. Thanks
> -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Friday, February 27, 2015 10:52 PM > To: Liang, Cunming > Cc: David Marchand; dev@dpdk.org; Stephen Hemminger; Zhou, Danny > Subject: Re: [PATCH v6 2/8] eal/linux: add rx queue interrupt FDs to intr handle > struct > > 2015-02-27 11:28, Liang, Cunming: > > From: David Marchand [mailto:david.marchand@6wind.com] > > Sent: Friday, February 27, 2015 6:33 PM > > > On Fri, Feb 27, 2015 at 5:56 AM, Cunming Liang wrote: > > > > --- 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,9 @@ > > > > > > > > #ifndef _RTE_LINUXAPP_INTERRUPTS_H_ > > > > #define _RTE_LINUXAPP_INTERRUPTS_H_ > > > > > > > > +#define VFIO_MAX_RXTX_INTR_ID 32 > > > > +#define VFIO_MAX_QUEUE_ID VFIO_MAX_RXTX_INTR_ID > > > > > > This is a little weird to talk about vfio here. > > > This file is "generic". > > > > > > Ok, you will store vfio eventfds here, but vfio is an implementation, > > > not the abstraction. > > > > [Liang, Cunming] If looking at the rte_intr_hanle_type, it includes > UIO/VFIO_LEGACY/VFIO_MSI/VFIO_MSIX. > > I agree, VFIO is an implementation, but the different type combination is a kind > of ‘abstraction’. > > So in rte_intr_handle (like a multiplexing), some specified field for vfio > interrupter mapping, I feel it’s reasonable. > > Not sure to understand. Are we trying to mask the different kernel drivers > from an application point of view, and provide a generic interrupt mechanism? > If yes, why some VFIO constants are needed? > I'm not saying that the current implementation is perfect, but we should try > to improve it. [LCM] VFIO_MAX_RXTX_INTR_ID is easy to fix, it can move to a private interrupt header file, as only be used inside EAL. VFIO_MAX_QUEUE_ID can be removed, so vec_num[] dynamic creation by the device driver. Sounds good ? > > Thanks
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..9f45377 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,9 @@ #ifndef _RTE_LINUXAPP_INTERRUPTS_H_ #define _RTE_LINUXAPP_INTERRUPTS_H_ +#define VFIO_MAX_RXTX_INTR_ID 32 +#define VFIO_MAX_QUEUE_ID VFIO_MAX_RXTX_INTR_ID + This is a little weird to talk about vfio here. This file is "generic".