[dpdk-dev] transmit lockup on i210
Hello DPDK community, I haven’t found any relevant errata/fix notes so I’m asking here. I’m running into a transmit lockup on an i210 NIC: the transmit descriptor ring fills up and never drains. I’ve instrumented my code to dump out all extended stats and registers and found that when the transmitter gets ‘stuck’, the E1000_TDH register pegs to a particular index, and TDT catches up to it. I have the transmitter configured with these thresholds: pthresh == 8 hthresh == 1 wthresh == 16, four queues, 512 tx descriptors. I’m running DPDK 16.07. When this happens, restarting my application (including a NIC unbind/bind cycle) fixes it up, so the hardware isn’t wedged. I wonder if (a) anyone has run into a tx lockup with the IGB driver, and/or (b) what should I be looking at? Regards, and thanks for any help, Dennis Montgomery
[dpdk-dev] virtio: rte_ethdev port_ids consumed by rte_eal_init()
Hi, I've run into a problem with DPDK v17.08, when built with CONFIG_RTE_LIBRTE_VIRTIO_PMD=y. After rte_eal_init() calls rte_bus_probe() we end up with the first several entries (matching the number of virtio-pci eth devices on the system) in rte_eth_devices[] showing state == RTE_ETH_DEV_ATTACHED. Subsequently when we try to allocate a new device (via rte_eth_dev_attach()), rte_eth_dev_find_free_port() returns a nonzero number the for the first device we really want to use. The device functions properly so this isn't too much of a problem, but effectively it limits the number of virtio eth devices to be half of RTE_MAX_ETHPORTS. I'd greatly appreciate some guidance on how to work around this - i.e. whether it's fixed in a newer release or if the structures filled in by rte_bus_probe() can be started without attaching, or whatever. Thanks in advance, Dennis Montgomery
[dpdk-dev] How can I recover from CONFIG_RTE_MAX_MEMSEG overrun?
Hello, I?m running into an occasional problem where rte_eal_init() returns -ENOMEM and the following error is logged: EAL: Can only reserve 991 pages from 1024 requested Current CONFIG_RTE_MAX_MEMSEG=256 is not enough When this happens a reboot will take care of it, but I?m hoping for a more elegant solution. I don?t have much direct experience with hugetlbfs so I?m hoping someone on this list can suggest something. I did boost max-memseg and it works, but I?m worried that it will just crop up again - I instrumented rte_eal_hugepage_init() and found that the number of segments used slowly creeps up as I cycle my application (i.e. repeated rte_eal_init() invocations with process-type == primary). I?m theorizing that hugetlbfs fragments (for lack of a better phrase) over time. Does anyone on the list know of a way to reset hugetlbfs short of rebooting? DPDK version: EAL: RTE Version: 'RTE 1.8.0-rc0' Linux version 3.16.6-200.fc20.x86_64 (mockbuild at bkernel01.phx2.fedoraproject.org) (gcc version 4.8.3 20140911 (Red Hat 4.8.3-7) (GCC) ) #1 SMP Wed Oct 15 13:06:51 UTC 2014 Thank you, Dennis Montgomery PS this is my first post to this list; apologies if I?m violating any protocols.
