[dpdk-users] [ovs-dev] adding dpdk ports sharing same pci address to ovs-dpdk bridge

[Loftus, Ciara]

> 20/09/2017 19:33, Kevin Traynor:
> > On 09/08/2017 10:56 AM, Loftus, Ciara wrote:
> > >> Hi,
> > >>
> > >> I have compiled and built ovs-dpdk using DPDK v17.08 and OVS v2.8.0.
> The
> > >> NIC that I am using is Mellanox ConnectX-3 Pro, which is a dual port 10G
> > >> NIC. The problem with this NIC is that it provides only one PCI address
> for
> > >> both the 10G ports.
> > >>
> > >> So when I am trying to add the two DPDK ports to my br0 bridge
> > >>
> > >> # ovs-vsctl --no-wait add-port br0 dpdk0 -- set Interface dpdk0
> type=dpdk
> > >> options:dpdk-devargs=0002:01:00.0
> > >>
> > >> # ovs-vsctl --no-wait add-port br0 dpdk1 -- set Interface dpdk1
> type=dpdk
> > >> options:dpdk-devargs=0002:01:00.0
> > >>
> > >> The port dpdk1 is added successfully and able to transfer data, but
> adding
> > >> dpdk0 to br0 fails:
> [...]
> > >> With OVS v2.6.1 I never had this problem as dpdk-devargs was not
> > >> mandatory
> > >> and just specifying port name was enough to add that port to bridge.
> > >>
> > >> Is there a way to add port both ports to bridge ?
> > >
> > > 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.
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.

> 
> 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.