<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 4, 2022 at 5:37 AM lihuisong (C) <<a href="mailto:lihuisong@huawei.com">lihuisong@huawei.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">[...]<br>
在 2022/7/1 19:36, Zhang, Peng1X 写道:<br>[...]<br>
> The reason why not use 'dev->data->rx_queue_state' is whether queue state is start or stop in primary<br>
> process depend on rx_conf->rx_deferred_start after start testpmd. And after having started testpmd,<br>
> queue state can be controlled by command for example 'port x rxq x start'.<br>
> Should we align with the same behavior of queues state for primary and secondary process after start testpmd?<br>
If primary process stops a queue, but secondary doesn't know.<br>
we have to simplify this queue state problem like you momentioned<br>
if we don't have a good idea.<br></blockquote><div><br></div><div>AFAIU, dev->data->rx_queue_state should be aligned with rx_conf->rx_deferred_start.</div><div></div><div><div>The reason why testpmd manages the queue state itself in the offending patch<br></div><div>is that not all PMDs implement `rte_eth_rx/tx_queue_info_get()`</div><div>and ethdev won't return `dev->data->rx_queue_state` in this case.</div></div></div></div>