All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Shreyansh Jain <shreyansh.jain@nxp.com>,
	David Marchand <david.marchand@6wind.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: Clarification for eth_driver changes
Date: Fri, 11 Nov 2016 19:16:10 +0000	[thread overview]
Message-ID: <1a19615c-1121-fed4-b34f-aa0f4b654085@intel.com> (raw)
In-Reply-To: <86ece536-1574-6d84-661e-9b9e77180344@nxp.com>

On 11/10/2016 11:05 AM, Shreyansh Jain wrote:
> Hello David,
> 
> On Thursday 10 November 2016 01:46 PM, David Marchand wrote:
>> Hello Shreyansh,
>>
>> On Thu, Nov 10, 2016 at 8:26 AM, Shreyansh Jain <shreyansh.jain@nxp.com> wrote:
>>> I need some help and clarification regarding some changes I am doing to
>>> cleanup the EAL code.
>>>
>>> There are some changes which should be done for eth_driver/rte_eth_device
>>> structures:
>>>
>>> 1. most obvious, eth_driver should be renamed to rte_eth_driver.
>>> 2. eth_driver currently has rte_pci_driver embedded in it
>>>  - there can be ethernet devices which are _not_ PCI
>>>  - in which case, this structure should be removed.
>>
>> Do we really need to keep a eth_driver ?
> 
> No. As you have rightly mentioned below (as well as in your Jan'16 
> post), it is a mere convenience.

Isn't it good to separate the logic related which bus device connected
and what functionality it provides. Because these two can be flexible:

device -> virtual_bus -> ethernet_functionality
device -> pci_bus     -> crypto_functionality
device -> x_bus       -> y_function


what about:

create generic bus driver/device and all eal level deal with generic
bus. different buses inherit from generic bus logic

create generic functionality device/driver and pmd level deal with
these. different functionalities inherit from generic functionality logic

and use rte_device/rte_driver as glue logic for all these.

This makes easy to add new bus or functionality device/drivers without
breaking existing logic.


Something like this:

struct rte_device {
	char *name;
	struct rte_driver *drv;
	struct rte_bus_device *bus_dev;
	struct rte_funcional_device *func_dev;
	*devargs
}

struct rte_bus_device {
	struct rte_device *dev;
	/* generic bus device */
}

struct rte_pci_device {
	struct rte_bus_device bus_dev;
	/* generic pci bus */
}

struct rte_vdev_device {
	struct rte_bus_device bus_dev;
	/* generic vdev bus */
}

struct rte_funcional_device {
	struct rte_device *dev;
}

struct rte_eth_device {
	struct rte_funcional_device func_dev;
	/* generic eth device */
}

struct rte_crypto_device {
	struct rte_funcional_device func_dev;
	/* generic crypto device */
}


struct rte_driver {
	char *name;
	struct rte_device *dev;
	struct rte_bus_driver *bus_drv;
	struct rte_funcional_driver *func_drv;
}

struct rte_bus_driver {
	struct rte_driver *drv;
	rte_bus_probe_t *probe(dev, drv);
	rte_bus_remove_t *remove(dev);
	/* generic bus driver */
}

struct rte_pci_driver {
	struct rte_bus_driver bus_drv;
	*id_table;
	/* generic pci bus */
}

struct rte_vdev_driver {
	struct rte_bus_driver bus_drv;
	/* generic vdev bus */
}

struct rte_funcional_driver {
	struct rte_driver *drv;
	rte_funcional_init_t *init;
	rte_funcional_uninit_t *uninit;
}

struct rte_eth_driver {
	struct rte_funcional_driver func_drv;
	/* generic eth driver */
}

struct rte_crypto_driver {
	struct rte_funcional_driver func_drv;
	/* generic crypto driver */
}

pci_scan_one()
{
	dev = create();
	pci_dev = create();
	
	dev->bus_dev = pci_dev;
	pci_dev->bus_dev.dev = dev;
	
	insert(bus_dev_list);
}

register_drv(drv)
{
	insert(bus_drv_list)
	insert(func_drv_list)
	insert(drv_list)
}

rte_eal_bus_probe()
  for bus_dev in bus_dev_list
	bus_probe_all_drivers(bus_dev)
	  for bus_drv in bus_drv_list
	    bus_probe_one_driver(bus_drv, bus_dev)
		  bus_dev->dev->drv = bus_drv->drv;
		  bus_drv->drv->dev = bus_dev->dev;
		  probe(drv, dev)

probe(drv, dev)
{
	dev->func_dev = create();
	func_dev->dev = dev;

	func_drv = drv->func_drv;
	func_drv->init(func_dev);
}

eht_init(func_dev)
{
	eth_dev = (struct rte_eth_dev)func_dev;
	drv = func_dev->dev->drv;
}

  reply	other threads:[~2016-11-11 19:16 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-10  7:26 Clarification for eth_driver changes Shreyansh Jain
2016-11-10  7:51 ` Jianbo Liu
2016-11-10  8:03   ` Thomas Monjalon
2016-11-10  8:42     ` Shreyansh Jain
2016-11-10  8:58       ` Thomas Monjalon
2016-11-10  9:20         ` Jianbo Liu
2016-11-10 10:51           ` Stephen Hemminger
2016-11-10 11:07             ` Thomas Monjalon
2016-11-10 11:09             ` Shreyansh Jain
2016-11-10  8:38   ` Shreyansh Jain
2016-11-10  8:16 ` David Marchand
2016-11-10 11:05   ` Shreyansh Jain
2016-11-11 19:16     ` Ferruh Yigit [this message]
2016-11-12 17:44       ` Shreyansh Jain
2016-11-14 17:38         ` Ferruh Yigit
2016-11-16  5:09           ` Shreyansh Jain
2016-11-14  9:07       ` David Marchand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1a19615c-1121-fed4-b34f-aa0f4b654085@intel.com \
    --to=ferruh.yigit@intel.com \
    --cc=david.marchand@6wind.com \
    --cc=dev@dpdk.org \
    --cc=shreyansh.jain@nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.