On Fri, May 10, 2024 at 01:07:44PM +0200, Jiri Pirko wrote: > 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. >
Ok, I will do my best to make it easier to read in next version. > > > > >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
