netdev - Re: [Intel-wired-lan] [iwl-next v1 08/14] ice: create port representor for SF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Zj4SS6hPPDEhvBCX@mev-dev>
Date: Fri, 10 May 2024 14:25:47 +0200
From: Michal Swiatkowski <michal.swiatkowski@...ux.intel.com>
To: Jiri Pirko <jiri@...nulli.us>
Cc: shayd@...dia.com, maciej.fijalkowski@...el.com,
	mateusz.polchlopek@...el.com, netdev@...r.kernel.org,
	jiri@...dia.com, michal.kubiak@...el.com,
	intel-wired-lan@...ts.osuosl.org, pio.raczynski@...il.com,
	sridhar.samudrala@...el.com, jacob.e.keller@...el.com,
	wojciech.drewek@...el.com, przemyslaw.kitszel@...el.com
Subject: Re: [Intel-wired-lan] [iwl-next v1 08/14] ice: create port
 representor for SF

On Fri, May 10, 2024 at 01:07:44PM +0200, Jiri Pirko wrote:
> Fri, May 10, 2024 at 09:31:15AM CEST, michal.swiatkowski@...ux.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.swiatkowski@...ux.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.drewek@...el.com>
> >> >Signed-off-by: Michal Swiatkowski <michal.swiatkowski@...ux.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