Re: vmxnet3 no longer functional on DPDK 21.11

[Lewis Donzis <lew@perftech.com>]

----- On Dec 6, 2021, at 6:08 AM, Ananyev, Konstantin konstantin.ananyev@intel.com wrote:

> So to clarify, it fails at:
> static int
> vmxnet3_dev_start(struct rte_eth_dev *dev)
> {
>	...
> line 1695:
>	if (rte_intr_enable(dev->intr_handle) < 0) {
>                PMD_INIT_LOG(ERR, "interrupt enable failed");
>                return -EIO;
>        }
> 
> Right?

That's right.  And further, the failure inside of rte_intr_enable() is the test on rte_intr_dev_fd_get():

int
rte_intr_enable(const struct rte_intr_handle *intr_handle)
{
        ...
        if (rte_intr_fd_get(intr_handle) < 0 ||
                        rte_intr_dev_fd_get(intr_handle) < 0) {
                rc = -1;
                goto out;
        }

        switch (rte_intr_type_get(intr_handle)) {
        /* not used at this moment */
        case RTE_INTR_HANDLE_ALARM:
                rc = -1;
                break;
        /* not used at this moment */
        case RTE_INTR_HANDLE_DEV_EVENT:
                rc = -1;
                break;
        /* unknown handle type */
        default:
                RTE_LOG(ERR, EAL, "Unknown handle type of fd %d\n",
                        rte_intr_fd_get(intr_handle));
                rc = -1;
                break;
        }

out:
        rte_eal_trace_intr_enable(intr_handle, rc);
        return rc;
}


Two things about this code that confuse me:

1. rte_intr_dev_fd_get(intr_handle) just returns the value of intr_handle->dev_fd, which is never set to anything other than -1 in any code I can find.

2. Even if it made it past that "if" statement, I don't see how the switch that follows ever *doesn't* return an error, i.e., every single case results in an error!  Even if it got past rte_intr_dev_fd_get(), the interrupt type is neither of the first two cases, so it would presumably execute the default case.


> The strange thing here is that 7a0935239b9e
> doesn't change dev_start or rte_intr code in any way.

I agree, and also don't see any way the diffs between those two commits could cause this.


> Anyway, if git blames that commit, let's try to figure out what is going on.
> Unfortunately, I don't have freebsd with vmxnet3, so will need to rely on your
> help here.

Sure no problem.  If it helps, we could arrange for remote access to a FreeBSD VM, but I suspect this is going to be something simple, so let's see if we can get it figured out.


> As the first thing can you try to run testpmd build with last good commit
> (c87d435a4d79)
> and then testpmd build with bad commit applied and collect for both cases:
> - contents of 'struct rte_eth_dev' and ' rte_eth_dev->intr_handle' for
>  your vmxnet3 port
> - debug log output (--log-level=eal,debug --log-level=pmd,debug)

Ok, we'll check it out.

Thanks,
lew