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

Thomas Monjalon thomas at monjalon.net
Thu Sep 21 00:08:45 CEST 2017

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?

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

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.

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

More information about the users mailing list