On 12/8/2023 2:28 PM, Brett Creeley wrote: >> -int >> -ice_vc_send_msg_to_vf(struct ice_vf *vf, u32 v_opcode, >> - enum virtchnl_status_code v_retval, u8 *msg, u16 msglen) >> +static int >> +ice_vc_send_response_to_vf(struct ice_vf *vf, u32 v_opcode, >> + enum virtchnl_status_code v_retval, >> + u8 *msg, u16 msglen) > > Is all of this rework needed? It seems like it's just a name change with > additional logic to check the REPLAYING state. IMHO the naming isn't > really any cleaner. > > Would it make more sense to just modify the current > ice_vc_send_msg_to_vf() to handle the REPLAYING state? It seems like > that would simplify this patch quite a bit. > > Is there a reason for these changes in follow up patches that I missed? > > Thanks, > > Brett I remember making the suggestion to switch from "ice_vc_send_msg_to_vf" to "ice_vc_send_response_to_vf" irrespective of the live migration. I guess i could see it as just thrash, but it reads more clear ot me that the action is about sending a response to the VF vs the generic "send_msg_to_vf" which could be about any type of message whether its in response or not. But to some extend thats just bike shedding. I'll drop this change in the next version regardless, because I'm going to move away from the virtchnl as the serialization format for the live migration data. Thanks, Jake
