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;
}
next prev parent 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.