From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <thomas.monjalon@6wind.com>
Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41])
 by dpdk.org (Postfix) with ESMTP id 05E9E593B
 for <dev@dpdk.org>; Sat, 12 Apr 2014 08:03:47 +0200 (CEST)
Received: by mail-wg0-f41.google.com with SMTP id n12so6155661wgh.0
 for <dev@dpdk.org>; Fri, 11 Apr 2014 23:05:25 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:organization
 :user-agent:in-reply-to:references:mime-version
 :content-transfer-encoding:content-type;
 bh=Tv5S9hIxSyv7K3ZCqPR7T2CAa1qUMCd3txcPczi+kTo=;
 b=UNqkW+2KxWYOLvlazi89rxhHbsWdkWUxt8YzSL4akjUo2sw2Y3E+BBW4iOBoqK4LFJ
 HfJ4MTRxSQrVrMqzETbhvmI+1JnLapC/rIHMmDgYwkCrYRaBomOUHf9bZNMSnKEgTw2y
 WqE7hJJYvdKIU9RdOL8a+JvcjN1cRnSJcaujEeZWmxKwgdPmYhAs6nUFvNjOraKw13kh
 cLdIeEEETPFfmNmtcEv5GiovVX91H39Bcd8iJs7jszTURCO78ygVVdjd781y9QmnjEvk
 V7HrDfgUiDU9+1TENwd+fLhKm8t/9mb78V626efuXTfuY0EaMrPKKhZyla2kfpdvwidA
 ci0w==
X-Gm-Message-State: ALoCoQkuqxT86CDQROjUm6VNMPZv79uprPKBA9X0XITLrnQ53sUtgUTzQ5YU66XOPXJx9t5KN/rz
X-Received: by 10.194.59.226 with SMTP id c2mr24068965wjr.6.1397282725350;
 Fri, 11 Apr 2014 23:05:25 -0700 (PDT)
Received: from x220.localnet (abo-213-55-68.mts.modulonet.fr. [85.68.55.213])
 by mx.google.com with ESMTPSA id
 s3sm14391171wje.36.2014.04.11.23.05.23 for <multiple recipients>
 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Fri, 11 Apr 2014 23:05:24 -0700 (PDT)
From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: "Richardson, Bruce" <bruce.richardson@intel.com>
Date: Sat, 12 Apr 2014 08:05:22 +0200
Message-ID: <24514389.3vY1j6NNAg@x220>
Organization: 6WIND
User-Agent: KMail/4.12.2 (Linux/3.12.9-2-ARCH; KDE/4.12.2; x86_64; ; )
In-Reply-To: <59AF69C657FD0841A61C55336867B5B01A9FC02F@IRSMSX103.ger.corp.intel.com>
References: <1460632.jOzC6OEr8u@xps13>
 <20140411174454.GE911@hmsreliant.think-freely.org>
 <59AF69C657FD0841A61C55336867B5B01A9FC02F@IRSMSX103.ger.corp.intel.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
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 <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>
X-List-Received-Date: Sat, 12 Apr 2014 06:03:48 -0000

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?

-- 
Thomas