21/09/2017 10:04, Loftus, Ciara: > > 20/09/2017 19:33, Kevin Traynor: > > > On 09/08/2017 10:56 AM, Loftus, Ciara wrote: > > > > It seems the DPDK function rte_eth_dev_get_port_by_name() will > > > > always return the port ID of the first port on your NIC, > > > > when you specify the single PCI address and that's where the > > > > problem is. There doesn't seem to be a way currently to > > > > indicate to the calling application that in fact two > > > > (or more) port IDs are associated with the one PCI address. > > > > We have two ports (with the same PCI address) so we should have > > two different names. > > Where the names passed to rte_eth_dev_get_port_by_name() come from? > > It is the user parameter from options:dpdk-devargs=0002:01:00.0, right? > > Yes, we're using the PCI address specified by the user in dpdk-devargs. > > > > > I am cc-ing DPDK users mailing list for hopefully some input. > > > > Are there any plans for the rte_eth_dev_get_port_by_name function > > > > to be compatible with NICs with multiple ports under the same PCI > > > > address? > > > > We cannot return two different ports for the same name. > > There are two issues here: > > - the input should not be the PCI address > > - the ethdev function should look at ethdev name, not rte_device > > one > > This would require the user having to "guess" the DPDK ethdev name > which is something we'd like to avoid.
Yes, but you can provide a way to list the ports with their names and characteristics. > We had the same problem using DPDK port IDs and decided not to use > them anymore, and use the PCI instead as it took the guesswork out. > Ethdev names and port IDs can change between tests, unlike the PCI > address which tends to remain constant for a device. We can add a requirement on ethdev names and make sure they remain constant for a given port. > > The idea is that we have only one rte_device object and we instantiate > > two rte_eth_dev ports. > > An ethdev port can be identified with its id (a number) or its unique name. > > Unfortunately, the user cannot guess the port id or the name set by the > > PMD. > > Exactly. Thanks for clarifying what's going on under the hood. > > Ciara > > > > > > Hi Adrien/Nelio, > > > > > > Is this something you can answer? We're wondering how to handle this in > > > OVS and whether a temporary or long term solution is needed. > > > > I suggest to rely on ethdev name. > > You will need to show to the user the mapping between the bus information > > (PCI id here) and the device names. > > > > Another alternative is to add a new function returning all ethdev ports > > associated to a given rte_device resource. > > So you would get two ports and you could pick one on the first "add-port", > > and the other one for the second "add-port" command. > > It means the user would be forced to add them in the right order if he > > wants a reproducible result. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev