On Thursday 22 December 2016 10:42 AM, Shreyansh Jain wrote:
On Thursday 22 December 2016 05:03 AM, Stephen Hemminger wrote:
On Wed, 21 Dec 2016 16:38:42 +0100
Jan Blunck <jblu...@infradead.org> wrote:

On Tue, Dec 20, 2016 at 6:11 PM, Stephen Hemminger
<step...@networkplumber.org> wrote:
On Tue, 20 Dec 2016 14:17:14 +0100
Jan Blunck <jblu...@infradead.org> wrote:

On Fri, Dec 16, 2016 at 2:10 PM, Shreyansh Jain
<shreyansh.j...@nxp.com> wrote:
This patch introduces the rte_bus abstraction for devices and
drivers in
EAL framework. The model is:
 - One or more buses are connected to a CPU (or core)
 - One or more devices are conneted to a Bus
 - Drivers are running instances which manage one or more devices
 - Bus is responsible for identifying devices (and interrupt
propogation)
 - Driver is responsible for initializing the device

This patch adds a 'rte_bus' class which rte_driver and rte_device
refer.
This way, each device (rte_xxx_device) would have reference to the
bus
it is based on. As well as, each driver (rte_xxx_driver) would
have link
to the bus and devices on it for servicing.

                                  __ rte_bus_list
                                 /
                     +----------'---+
                     |rte_bus       |
                     | driver_list------> List of rte_bus specific
                     | device_list----    devices
                     |              | `-> List of rte_bus associated
                     |              |     drivers
                     +--|------|----+
              _________/        \_________
    +--------/----+                     +-\---------------+
    |rte_device   |                     |rte_driver       |
    | rte_bus     |                     | rte_bus         |
    | rte_driver  |                     | ...             |
    | ...         |                     +---------...-----+
    |             |                               |||
    +---||--------+                               |||
        ||                                        |||
        | \                                        \\\
        |  \_____________                           \\\
        |                \                          |||
 +------|---------+ +----|----------+               |||
 |rte_pci_device  | |rte_xxx_device |               |||
 | ....           | | ....          |               |||
 +----------------+ +---------------+              / | \
                                                  /  |  \
                            _____________________/  /    \
                           /                    ___/      \
            +-------------'--+    +------------'---+
+--'------------+
            |rte_pci_driver  |    |rte_vdev_driver |
|rte_xxx_driver |
            | ....           |    | ....           |    |
....          |
            +----------------+    +----------------+
+---------------+

This patch only enables the bus references on rte_driver and
rte_driver.
EAL wide global device and driver list continue to exist until an
instance
of bus is added in subsequent patches.

This patch also introduces RTE_REGISTER_BUS macro on the lines of
RTE_PMD_REGISTER_XXX. Key difference is that the constructor
priority has
been explicitly set to 101 so as to execute bus registration
before PMD.

Signed-off-by: Shreyansh Jain <shreyansh.j...@nxp.com>


Ok, but let's keep this as bus type not bus. It gets really hard and
complex
to enumerate all layers of PCI bus and bridges.

As far as I understand it this isn't the intention to replicate the
hierarchy of buses we have in the kernel. The PCI bus in this case
becomes a list of PCI devices.

One of the motivations seems to be "lets be able to handle lots of
devices",
but the current model with an array of ports is not going to scale
well for that.

It is time to make rte_eth_devices into rb-tree and get rid of
MAX_PORTS config
option.


That is a nice idea. Probably once we get the EAL compatible for 'lots
of devices', this would be next good change.

Just out of curiosity - I think only need here is to do away with 'MAX_PORTS'. There is no need for a 'fast' lookup of ports as this part wouldn't be part of datapath. Am I wrong in assuming this?


-
Shreyansh



Reply via email to