- jing.d.c...@intel.com (invalid address?), +ethdev maintainers > From: Li, Xiaoyun <xiaoyun...@intel.com> > [...] > Sorry to be direct, but I don't think this patch makes sense. > I need the code to clarify the problems so I'll use this thread not > the one you're answering.
Thank you for explaining the issues in great detail! I'd like to understand one crucial point below to decide whether testpmd needs any changes at all. > [...] > And I don't think it's that harmful to just let those fwd running even > if you stop some rxq. Because their pair won't have pkts to do tx if > there's no rx. This patch was created with the assumption that stopped queues may not be used for Rx/Tx. No-op behavior of rte_eth_rx/tx_burst() for a stopped queue is not documented. Yes, at least some PMDs implement it this way. But is this behavior intended? It is the application that stops the queue or starts it deferred. Stopping is non-atomic, so polling the queue is not allowed during it. Hence, if the application intends to stop queues, it must either: a) Know the queue is not polled before stopping it. Use case: a secondary that was polling the queue has crashed, the primary is doing a recovery to free all mbufs. There is no issue since there is no poller to touch the queue. b) Tell the poller to skip the queue for the time of stopping it. Use case: deferred queue start or queue reconfiguration. But if the poller is cooperating anyway, what prevents it from not touching the queue for longer? The same considerations apply to starting a queue. No-op behavior is convenient from the application point of view. But it also means that pollers of stopped queues will go all the way down to PMD Rx/Tx routines, wasting cycles, and some PMDs will do a check for the queue state, even though it may never be needed for a particular application.
