On 11/26/21 07:50, Nobuhiro MIKI wrote: > In Tap PMD, file descriptors for rxq and txq are paired by dup(2) [1]. > Here, rxq and txq are created for the number of PMD threads +1 each. One > additional fd will be created for keepalive [2]. For example, if the > number of PMD threads is 4, the number of fd is 5 for rxq, 5 for txq, and > 1 for keepalive, so a total of 11 fd will be created. > > The user can specify any value as rxq from the CLI, but it must bespecified > here as rxq = PMD threads count +1. If you forget to specify rxq, or if you > specify a small value, there will be a queue that will not be watched, and > some packets will fail to be received.
Hmm. If DPDK creates more rx queues than it was requested by the application, that sounds like a DPDK bug to me that should be fixed in DPDK. Briefly reading the tap_setup_queue() function in the driver, I don't see it allocating something that wasn't requested. i.e. it doesn't seem to dup all the tx fds, it only dups ones that correspond to the requested rx queue id. But if kernel actually sends packets to these tx descriptors expecting the application to receive them, that's should be fixed in the driver, e.g. by prohibiting the n_rxq != n_txq configuration. Changing the n_rxq configuration every time the number of threads changed in OVS doesn't seem like a viable solution. Best regards, Ilya Maximets. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
