[dpdk-dev] [PATCH v7 2/9] eal: introduce RTE common initialization level

Parav Pandit parav at mellanox.com
Tue Jul 21 13:18:59 CEST 2020


Hi David,

On 7/21/2020 3:04 PM, David Marchand wrote:
> On Mon, Jul 20, 2020 at 9:30 PM Ori Kam <orika at mellanox.com> wrote:
>>> net and vdpa code expect the common code being initialised.
>>> It is a dependency internal to mlx5 drivers, I see nothing generic.
>>>
>> First the idea was to declare a new bus not a PMD.
>> The issue is not from common code but from loading more than one
>> device on the same PCI.
>> So the logic is Mellanox PMD are registering to the new bus, the new bus
>> register to the PCI one.
> 
> - Is there a problem with the snippet I sent yesterday that removes
> the COMMON priority?
> 
> 
No. The problem as you describe below is in handling the inter
dependencies between mlx5_common, rte_pci and mlx5_{net/vdpa}.

mlx5_net/vdpa demands common to be loaded first.
mlx5_pci_bus expects mlx5_net_vdpa to register first.
More below.

> - Currently in the main branch, the net/mlx5 driver is a pci driver
> registered to the pci bus driver.
> This registration happens in a constructor which puts the net/mlx5 pci
> driver struct (with a populated id map) into the pci driver list.
> Later (out of constructor context), a probe on the pci bus uses this
> driver list.
> 
> 
> A new pci driver is introduced by Mellanox to solve resources
> dispatching between mlx5 drivers.
> I'd rather not call this new pci driver a bus, it is not registered as
> such (no rte_bus object) => no reason its constructor should be called
> from the RTE_PRIO_BUS priority.
> 
> This driver not being a bus, I would not put it in drivers/bus/,
> rather in the common code.
> If there is a build dependency issue with the pci bus driver, you can
> probably use the trick from qat
> (https://git.dpdk.org/dpdk/tree/drivers/Makefile#n17) and write an
> explicit dependency in drivers/Makefile.
> meson should be just fine.
> 
mlx5_common to depend on pci bus. (new Makefile change)
mlx5_net and mlx5_vdpa to depend on mlx5_common. (already there)

> 
> net/mlx5 and vdpa/mlx5 are not classes => no reason their constructor
> should be called from the RTE_PRIO_CLASS priority.
> The only classes we have are ethdev and vdpa.
> 
> 
> The new pci driver simply serves as a proxy for mlx5 net and vdpa drivers.
> From what I see, the new pci driver constructs its pci device id
> map/drv_flags when registering to the pci bus driver based on what
> mlx5 net and vdpa drivers registered before.
> This is where a dependency was created.
> 
> You can move the id_table/drv_flags construction from
> RTE_INIT(mlx5_bus_pci) to rte_mlx5_pci_register() itself.
ok. This is what were also discussing internally as well.

> This way, net/mlx5 and vdpa/mlx5 will pass their id_map to the mlx5
> pci driver whether it is registered to the pci bus or not yet.

And here pci_id_table will not be const *.
Is that ok?

Basically mlx5_pci_bus, mlx5_net and mlx5_vdpa will be called with same
priority RTE_PRIO_LAST.
driver id table and drv_flags dynamically updated as PMDs register.

Should we have another API after rte_pci_register() to indicate that
some field of the driver are updated, instead of just silently updating
it in a PMD?


More information about the dev mailing list