Re: [Intel-wired-lan] [PATCH iwl-next v4 03/12] ice: Introduce VF state ICE_VF_STATE_REPLAYING_VC for migration

[Jacob Keller <jacob.e.keller@intel.com>]

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