On 08/12/2017 15:02, Remy Horton wrote:
On 20/11/2017 07:46, Ferruh Yigit wrote:
[..]
Why we need this PMD?
It looks like this has been used only for parameter parsing.
Can it be possible to rte_representor_broker_init() will allocate
ethdevs and
fill brokers with this information?
Possible, but not sure it gains much in practice. It would require
workarounds to avoid pulling in driver code dependencies (e.g.
drivers/bus/vdev/rte_bus_vdev.h).
I think it possible to create the representor without pulling in driver
codes. We probably can avoid using the rte_eth_vdev_allocate by calling
the rte_eth_dev_allocate() directly.
Right now, the port representor register API looks like
int
rte_representor_port_register(struct rte_representor_broker *broker,
uint32_t vport_id, struct rte_eth_dev *ethdev);
So, we probably can have that API (and make it public) as below.
int
rte_representor_port_register(const char *devargs);
We can parse the devargs to get all the parameters, create the ethdev
using rte_eth_dev_allocate(), fill all the private data, pci_device,
pci_driver etc. and register to the broker.
This way we can avoid having a separate PMD for port representor. This
comes with a limitation/benefit that user do need need to pass the vdev
info as EAL argument.
Regards,
Awal.
