On 18/06/20 10:06 +0000, Parav Pandit wrote:
>
>
> > From: Gaëtan Rivet <gr...@u256.net>
> > Sent: Tuesday, June 16, 2020 3:26 AM
> >
> > On 10/06/20 17:17 +0000, Parav Pandit wrote:
> > > Enable class driver to match with the mlx5 pci devices.
> > > Migrate mlx5 net PMD and vdpa PMD to start using mlx5 common class
> > > driver.
> > >
> > > Signed-off-by: Parav Pandit <pa...@mellanox.com>
> > > ---
> > > drivers/bus/Makefile | 3 ++
> > > drivers/bus/mlx5_pci/mlx5_pci_bus.c | 60
> > +++++++++++++++++++++++++++++
> > > drivers/net/mlx5/Makefile | 3 +-
> > > drivers/net/mlx5/linux/mlx5_os.c | 1 -
> > > drivers/net/mlx5/linux/mlx5_os.h | 3 --
> > > drivers/net/mlx5/meson.build | 2 +-
> > > drivers/net/mlx5/mlx5.c | 7 ++--
> > > drivers/net/mlx5/mlx5.h | 1 -
> > > drivers/vdpa/mlx5/Makefile | 3 +-
> > > drivers/vdpa/mlx5/meson.build | 2 +-
> > > drivers/vdpa/mlx5/mlx5_vdpa.c | 10 ++---
> > > mk/rte.app.mk | 1 +
> > > 12 files changed, 79 insertions(+), 17 deletions(-)
> > >
> >
[...]
> > > -struct rte_pci_driver mlx5_driver = {
> > > +static struct rte_mlx5_pci_driver mlx5_driver = {
> > > .driver = {
> > > .name = MLX5_DRIVER_NAME
> > > },
> > > + .dev_class = MLX5_CLASS_NET,
> > > .id_table = mlx5_pci_id_map,
> > > .probe = mlx5_os_pci_probe,
> > > .remove = mlx5_pci_remove,
> > > .dma_map = mlx5_dma_map,
> > > .dma_unmap = mlx5_dma_unmap,
> > > - .drv_flags = PCI_DRV_FLAGS,
> >
> > You mask the drv_flags, do you plan on merging those flags in the demuxing
> > drivers above? It seems LSC | RMV | PROBE_AGAIN is not used afterward,
> > seems missing.
> >
> > Using an rte_pci_driver instead of an rte_driver as core object for you
> > driver
> > would allow managing this by the way.
> Yes. but how would mlx5_pci bus will process the drv_flags passed by the
> class drivers such a vdpa/net?
>
LSC and RMV are used within rte_eth_copy_pci_info(), which is called by
each individual netdevice PCI probe callback, after creating an ethdev.
PROBE_AGAIN is used by the PCI bus to determine whether to throw -EEXIST
when attempting to probe again a device.
They will all access it through the demux PCI device -> PCI driver,
which will be in that case your demux driver. It needs to have a correct
value that will not mask underlying device capability or behavior.
Binary-AND between classes is bare-minimum, and would probably not work
for LSC. Some finer-grained control could be used to work well with
other layers.
--
Gaëtan
