Fri, May 10, 2024 at 09:31:15AM CEST, michal.swiatkow...@linux.intel.com wrote:
>On Thu, May 09, 2024 at 01:16:05PM +0200, Jiri Pirko wrote:
>> Tue, May 07, 2024 at 01:45:09PM CEST, michal.swiatkow...@linux.intel.com 
>> wrote:
>> >Store subfunction and VF pointer in port representor structure as an
>> >union. Add port representor type to distinguish between each of them.
>> >
>> >Keep the same flow of port representor creation, but instead of general
>> >attach function create helpers for VF and subfunction attach function.
>> >
>> >Type of port representor can be also known based on VSI type, but it
>> >is more clean to have it directly saved in port representor structure.
>> >
>> >Create port representor when subfunction port is created.
>> >
>> >Add devlink lock for whole VF port representor creation and destruction.
>> >It is done to be symmetric with what happens in case of SF port
>> >representor. SF port representor is always added or removed with devlink
>> >lock taken. Doing the same with VF port representor simplify logic.
>> >
>> >Reviewed-by: Wojciech Drewek <wojciech.dre...@intel.com>
>> >Signed-off-by: Michal Swiatkowski <michal.swiatkow...@linux.intel.com>
>> >---
>> > .../ethernet/intel/ice/devlink/devlink_port.c |   6 +-
>> > .../ethernet/intel/ice/devlink/devlink_port.h |   1 +
>> > drivers/net/ethernet/intel/ice/ice_eswitch.c  |  85 +++++++++---
>> > drivers/net/ethernet/intel/ice/ice_eswitch.h  |  22 +++-
>> > drivers/net/ethernet/intel/ice/ice_repr.c     | 124 +++++++++++-------
>> > drivers/net/ethernet/intel/ice/ice_repr.h     |  21 ++-
>> > drivers/net/ethernet/intel/ice/ice_sriov.c    |   4 +-
>> > drivers/net/ethernet/intel/ice/ice_vf_lib.c   |   4 +-
>> > 8 files changed, 187 insertions(+), 80 deletions(-)
>> 
>> This calls for a split to at least 2 patches. One patch to prepare and
>> one to add the SF support?
>
>Is 187 insertions and 80 deletions too many for one patch? Or the
>problem is with number of files changed?

The patch is hard to follow, that's the problem.


>
>I don't see what here can be moved to preparation part as most changes
>depends on each other. Do you want me to have one patch with unused
>functions that are adding/removing SF repr and another with calling
>them?
>
>Thanks,
>Michal

Reply via email to