From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH v2 07/11 1/2] vdev: new registration API Date: Sat, 12 Apr 2014 08:05:22 +0200 Message-ID: <24514389.3vY1j6NNAg@x220> References: <1460632.jOzC6OEr8u@xps13> <20140411174454.GE911@hmsreliant.think-freely.org> <59AF69C657FD0841A61C55336867B5B01A9FC02F@IRSMSX103.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev-VfR2kkLFssw@public.gmane.org To: "Richardson, Bruce" Return-path: In-Reply-To: <59AF69C657FD0841A61C55336867B5B01A9FC02F-kPTMFJFq+rELt2AQoY/u9bfspsVTdybXVpNB7YpNyf8@public.gmane.org> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" 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