During PF-initiated resets iavf_clean_arq_element() has been observed to return success with a fully zeroed descriptor (opcode 0). These fell through to the default arm of the dispatch switch and produced a "Request 0 is not supported yet" log flood in the field.
Skip descriptors with opcode 0 so they are silently discarded and do not flood log. Signed-off-by: Anurag Mandal <[email protected]> --- drivers/net/intel/iavf/iavf_vchnl.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/drivers/net/intel/iavf/iavf_vchnl.c b/drivers/net/intel/iavf/iavf_vchnl.c index f346837bf1..56918ebcc1 100644 --- a/drivers/net/intel/iavf/iavf_vchnl.c +++ b/drivers/net/intel/iavf/iavf_vchnl.c @@ -614,6 +614,19 @@ iavf_handle_virtchnl_msg(struct rte_eth_dev *dev) break; } aq_opc = rte_le_to_cpu_16(info.desc.opcode); + + /* + * During PF-initiated resets, iavf_clean_arq_element() has + * been observed to return IAVF_SUCCESS with a fully zeroed + * descriptor (opcode 0). + * Without this guard, such descriptors would fall through + * to the default case of the dispatch switch below and the + * "Request 0 is not supported yet" log flood reported in + * the field would be produced. These are discarded now. + */ + if (aq_opc == 0) + continue; + /* For the message sent from pf to vf, opcode is stored in * cookie_high of struct iavf_aq_desc, while return error code * are stored in cookie_low, Which is done by PF driver. -- 2.34.1
