[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <47a78150-711a-4aff-b18c-f77131131acf@intel.com>
Date: Mon, 23 Jun 2025 16:37:06 -0700
From: Jacob Keller <jacob.e.keller@...el.com>
To: Przemek Kitszel <przemyslaw.kitszel@...el.com>
CC: <netdev@...r.kernel.org>, Madhu Chittim <madhu.chittim@...el.com>, "Yahui
Cao" <yahui.cao@...el.com>, Anthony Nguyen <anthony.l.nguyen@...el.com>,
"Intel Wired LAN" <intel-wired-lan@...ts.osuosl.org>
Subject: Re: [PATCH iwl-next 0/8] ice: cleanups and preparation for live
migration
On 6/23/2025 1:36 AM, Przemek Kitszel wrote:
> On 6/19/25 00:24, Jacob Keller wrote:
>> Various cleanups and preparation to the ice driver code for supporting
>> SR-IOV live migration.
>>
>> The logic for unpacking Rx queue context data is added. This is the inverse
>> of the existing packing logic. Thanks to <linux/packing.h> this is trivial
>> to add.
>>
>> Code to enable both reading and writing the Tx queue context for a queue
>> over a shared hardware register interface is added. Thanks to ice_adapter,
>> this is locked across all PFs that need to use it, preventing concurrency
>> issues with multiple PFs.
>>
>> The RSS hash configuration requested by a VF is cached within the VF
>> structure. This will be used to track and restore the same configuration
>> during migration load.
>>
>> ice_sriov_set_msix_vec_count() is updated to use pci_iov_vf_id() instead of
>> open-coding a worse equivalent, and checks to avoid rebuilding MSI-X if the
>> current request is for the existing amount of vectors.
>>
>> A new ice_get_vf_by_dev() helper function is added to simplify accessing a
>> VF from its PCI device structure. This will be used more heavily within the
>> live migration code itself.
>>
>> REVIEW NOTES:
>>
>> This is the first eight patches of my full series to support live
>> migration. The full series (based on net-next) is available at [1] for
>> early preview if you want to see the changes in context.
>>
>> Some of these changes are not "used" until the live migration patches
>> themselves. However, I felt they were sufficiently large and review-able on
>> their own. Additionally, if I keep them included within the live migration
>> series it is 15 patches which is at the limit of acceptable size for
>> netdev. I'd prefer to merge these cleanups first in order to reduce the
>> burden of review for the whole feature.
>
> I find the split to be very good decision, here we have the easy bits,
> with the complex things left to separate series (instead reviewers
> facing them after reading eight and already tired ;))
>
> for the series:
> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@...el.com>
>
Yep, thats part of why I wanted to split. Thanks for reviewing.
Regards,
Jake
Powered by blists - more mailing lists