From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 0576E68C8 for ; Sat, 12 Apr 2014 13:22:16 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 12 Apr 2014 04:19:08 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.97,847,1389772800"; d="scan'208";a="491792502" Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by orsmga001.jf.intel.com with ESMTP; 12 Apr 2014 04:23:52 -0700 Received: from irsmsx107.ger.corp.intel.com (163.33.3.99) by IRSMSX102.ger.corp.intel.com (163.33.3.155) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sat, 12 Apr 2014 12:23:51 +0100 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.172]) by IRSMSX107.ger.corp.intel.com ([169.254.10.174]) with mapi id 14.03.0123.003; Sat, 12 Apr 2014 12:23:51 +0100 From: "Richardson, Bruce" To: Neil Horman , Thomas Monjalon Thread-Topic: [dpdk-dev] [PATCH v2 07/11 1/2] vdev: new registration API Thread-Index: AQHPVVjuiJJwaskozEGIu87RImbFLZsMK/eAgAAnzQCAACwrgIAAB9sAgAAYPgCAADHjUIAAnQAAgABTPICAABYV8A== Date: Sat, 12 Apr 2014 11:23:50 +0000 Message-ID: <59AF69C657FD0841A61C55336867B5B01A9FC150@IRSMSX103.ger.corp.intel.com> References: <1460632.jOzC6OEr8u@xps13> <20140411174454.GE911@hmsreliant.think-freely.org> <59AF69C657FD0841A61C55336867B5B01A9FC02F@IRSMSX103.ger.corp.intel.com> <24514389.3vY1j6NNAg@x220> <20140412110317.GA30887@hmsreliant.think-freely.org> In-Reply-To: <20140412110317.GA30887@hmsreliant.think-freely.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v2 07/11 1/2] vdev: new registration API 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: Sat, 12 Apr 2014 11:22:17 -0000 > -----Original Message----- > From: Neil Horman [mailto:nhorman@tuxdriver.com] > Sent: Saturday, April 12, 2014 12:03 PM > To: Thomas Monjalon > Cc: Richardson, Bruce; dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v2 07/11 1/2] vdev: new registration API >=20 > On Sat, Apr 12, 2014 at 08:05:22AM +0200, Thomas Monjalon wrote: > > Hi Bruce, > > > > 11/04/2014 20:08, Richardson, Bruce : > > > From: Neil Horman > > > > On Fri, Apr 11, 2014 at 06:18:08PM +0200, Thomas Monjalon wrote: > > > > > It seems that your patch is not removing > > > > > rte_eth_ring_pair_create/rte_eth_ring_pair_attach so I'm not > > > > > sure you can dynamically change the PMD in this case. > > > > > > > > Ew, I had missed those calls. Yes, those should be encapsulated > > > > as some driver ops or some such. I'll look at that when I rebase. > > > > Regardless however, I didn't mean to state that pmds could be > > > > switched while running, only that the pmd to use could be specified= at run > time. > > > > Though, you're correct, pmd_ring doesn't seem to hold in line with > > > > the other pmds in their isolation. > > > > > > The ring PMD is probably best treated separately from the other PMDs > > > as it's not really a device poll-mode driver. Instead, it's a > > > general library that presents an API to make a ring, or set of > > > rings, appear as a poll-mode driver ethdev. The EAL command to have > > > one created at startup time was just an addon after-the-fact in case > > > someone might find it useful :-). However, it's primary purpose was > > > to allow applications to be written which could use physical NICs or > > > rings interchangeably. For example, an app with multiple stages in a > > > pipeline, where each stage just reads from an ethdev without caring > > > if it's actually reading from a port or from packets sent from > > > another lcore/function etc. Another example might be where an > > > application wishes to sometimes loop packets back to itself, in this > > > case it uses the C API to create an additional ring ethdev which it > > > uses as output port for any packets it wants looped back - no > > > special handling needed, everything is an ethdev to it on which it > > > calls rx_burst or tx_burst. It's also likely that in future we will > > > develop other libraries which wish to present their functionality via > rx_burst/tx_burst functions i.e. as an ethdev. > > > > I think you are describing a vdev and you want to be able to > > instantiate this vdev in your application code. Right? > > So why not make a generic API to be able to instantiate a vdev? > > > +1, thats exactly what you're describing richard, an ethernet device > +thats > backed by rings (or pipes, or whatever other non-phycial transport you wa= nt to > use). Though we already have a method to generically instantiate a vdev,= its the > --vdev option in the eal library. It seems to me the simplest solution h= ere is to > remove the ring_create/attach api from public accessibility, and call it = directly > from the pmd init routine by passing parameters to it through the --vdev > command line argument. I've actually got that in the patch series that I= 'm > rebasing for the PMD DSO cleanups. >=20 The issue with that approach, is how do you create vdevs which are actually= backed by physical ethdevs, for example a vdev that is a set of bonded eth= devs e.g. for active/passive failover, or a vdev that actually does post-pr= ocessing on packets received from a physical ethdev?