[dpdk-dev] net/mlx5: use PCI BDF as the port name
Checks
Commit Message
It is suggested to use PCI BDF to identify a port for port addition
in OVS-DPDK. While mlx5 has its own naming style: name it by ib dev
name. This breaks the typical OVS DPDK use case and brings more puzzle
to the end users.
To fix it, this patch changes it to use PCI BDF as the name, too.
Also, a postfix " port %u" is added, just in case their might be more
than 1 port assoicated with a PCI device.
Signed-off-by: Yuanhan Liu <yliu@fridaylinux.org>
---
drivers/net/mlx5/mlx5.c | 22 +++++++++-------------
1 file changed, 9 insertions(+), 13 deletions(-)
Comments
Hi Yuanhan,
On Mon, Jan 22, 2018 at 05:30:06PM +0800, Yuanhan Liu wrote:
> It is suggested to use PCI BDF to identify a port for port addition
> in OVS-DPDK. While mlx5 has its own naming style: name it by ib dev
> name. This breaks the typical OVS DPDK use case and brings more puzzle
> to the end users.
>
> To fix it, this patch changes it to use PCI BDF as the name, too.
> Also, a postfix " port %u" is added, just in case their might be more
> than 1 port assoicated with a PCI device.
Seems only ixgbe, sfc, szedata2 use it whereas ark, bnxt, mlx4, mlx5,
mrvl, softnic don't.
Why not addressing all drivers at once?
> Signed-off-by: Yuanhan Liu <yliu@fridaylinux.org>
Acked-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
Tuesday, January 23, 2018 10:24 AM, Nélio Laranjeiro:
> Hi Yuanhan,
>
> On Mon, Jan 22, 2018 at 05:30:06PM +0800, Yuanhan Liu wrote:
> > It is suggested to use PCI BDF to identify a port for port addition in
> > OVS-DPDK. While mlx5 has its own naming style: name it by ib dev name.
> > This breaks the typical OVS DPDK use case and brings more puzzle to
> > the end users.
> >
> > To fix it, this patch changes it to use PCI BDF as the name, too.
> > Also, a postfix " port %u" is added, just in case their might be more
> > than 1 port assoicated with a PCI device.
>
> Seems only ixgbe, sfc, szedata2 use it whereas ark, bnxt, mlx4, mlx5, mrvl,
> softnic don't.
>
> Why not addressing all drivers at once?
>
> > Signed-off-by: Yuanhan Liu <yliu@fridaylinux.org>
> Acked-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
Applied to next-net-mlx, thanks.
>
> --
> Nélio Laranjeiro
> 6WIND
On 1/22/2018 9:30 AM, Yuanhan Liu wrote:
> It is suggested to use PCI BDF to identify a port for port addition
> in OVS-DPDK. While mlx5 has its own naming style: name it by ib dev
> name. This breaks the typical OVS DPDK use case and brings more puzzle
> to the end users.
>
> To fix it, this patch changes it to use PCI BDF as the name, too.
> Also, a postfix " port %u" is added, just in case their might be more
> than 1 port assoicated with a PCI device.
>
> Signed-off-by: Yuanhan Liu <yliu@fridaylinux.org>
<...>
> @@ -633,14 +635,15 @@ mlx5_pci_probe(struct rte_pci_driver *pci_drv, struct rte_pci_device *pci_dev)
> .inline_max_packet_sz = MLX5_ARG_UNSET,
> };
>
> + len = snprintf(name, sizeof(name), PCI_PRI_FMT,
> + pci_dev->addr.domain, pci_dev->addr.bus,
> + pci_dev->addr.devid, pci_dev->addr.function);
> + if (device_attr.orig_attr.phys_port_cnt > 1)
> + snprintf(name + len, sizeof(name), " port %u", i);
Getting a build error [1] with icc [2].
Because commit 9a761de8ea14 ("net/mlx5: flow counter support") adds variable
"device_attr" into loop scope, but there is already a variable with same name in
function scope.
In this case the variable in the loop scope should be used and compiler error
looks correct, not sure why others compilers not complain about it.
[1]
.../dpdk/drivers/net/mlx5/mlx5.c(729): error #592: variable "device_attr" is
used before its value is set
if (device_attr.orig_attr.phys_port_cnt > 1)
^
[2]
icc (ICC) 18.0.1 20171018
@@ -610,6 +610,8 @@ mlx5_pci_probe(struct rte_pci_driver *pci_drv, struct rte_pci_device *pci_dev)
INFO("%u port(s) detected", device_attr.orig_attr.phys_port_cnt);
for (i = 0; i < device_attr.orig_attr.phys_port_cnt; i++) {
+ char name[RTE_ETH_NAME_MAX_LEN];
+ int len;
uint32_t port = i + 1; /* ports are indexed from one */
uint32_t test = (1 << i);
struct ibv_context *ctx = NULL;
@@ -633,14 +635,15 @@ mlx5_pci_probe(struct rte_pci_driver *pci_drv, struct rte_pci_device *pci_dev)
.inline_max_packet_sz = MLX5_ARG_UNSET,
};
+ len = snprintf(name, sizeof(name), PCI_PRI_FMT,
+ pci_dev->addr.domain, pci_dev->addr.bus,
+ pci_dev->addr.devid, pci_dev->addr.function);
+ if (device_attr.orig_attr.phys_port_cnt > 1)
+ snprintf(name + len, sizeof(name), " port %u", i);
+
mlx5_dev[idx].ports |= test;
if (rte_eal_process_type() == RTE_PROC_SECONDARY) {
- /* from rte_ethdev.c */
- char name[RTE_ETH_NAME_MAX_LEN];
-
- snprintf(name, sizeof(name), "%s port %u",
- ibv_get_device_name(ibv_dev), port);
eth_dev = rte_eth_dev_attach_secondary(name);
if (eth_dev == NULL) {
ERROR("can not attach rte ethdev");
@@ -834,14 +837,7 @@ mlx5_pci_probe(struct rte_pci_driver *pci_drv, struct rte_pci_device *pci_dev)
priv_get_mtu(priv, &priv->mtu);
DEBUG("port %u MTU is %u", priv->port, priv->mtu);
- /* from rte_ethdev.c */
- {
- char name[RTE_ETH_NAME_MAX_LEN];
-
- snprintf(name, sizeof(name), "%s port %u",
- ibv_get_device_name(ibv_dev), port);
- eth_dev = rte_eth_dev_allocate(name);
- }
+ eth_dev = rte_eth_dev_allocate(name);
if (eth_dev == NULL) {
ERROR("can not allocate rte ethdev");
err = ENOMEM;