All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
To: Jiri Pirko <jiri@resnulli.us>
Cc: shayd@nvidia.com, maciej.fijalkowski@intel.com,
	mateusz.polchlopek@intel.com, netdev@vger.kernel.org,
	jiri@nvidia.com, michal.kubiak@intel.com,
	intel-wired-lan@lists.osuosl.org, pio.raczynski@gmail.com,
	sridhar.samudrala@intel.com, jacob.e.keller@intel.com,
	wojciech.drewek@intel.com, przemyslaw.kitszel@intel.com
Subject: Re: [Intel-wired-lan] [iwl-next v1 08/14] ice: create port representor for SF
Date: Fri, 10 May 2024 09:31:15 +0200	[thread overview]
Message-ID: <Zj3NQw1BxqtOS9VG@mev-dev> (raw)
In-Reply-To: <ZjywddcaIae0W_w3@nanopsycho.orion>

On Thu, May 09, 2024 at 01:16:05PM +0200, Jiri Pirko wrote:
> Tue, May 07, 2024 at 01:45:09PM CEST, michal.swiatkowski@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.drewek@intel.com>
> >Signed-off-by: Michal Swiatkowski <michal.swiatkowski@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?

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

WARNING: multiple messages have this Message-ID (diff)
From: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
To: Jiri Pirko <jiri@resnulli.us>
Cc: intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
	jacob.e.keller@intel.com, michal.kubiak@intel.com,
	maciej.fijalkowski@intel.com, sridhar.samudrala@intel.com,
	przemyslaw.kitszel@intel.com, wojciech.drewek@intel.com,
	pio.raczynski@gmail.com, jiri@nvidia.com,
	mateusz.polchlopek@intel.com, shayd@nvidia.com
Subject: Re: [iwl-next v1 08/14] ice: create port representor for SF
Date: Fri, 10 May 2024 09:31:15 +0200	[thread overview]
Message-ID: <Zj3NQw1BxqtOS9VG@mev-dev> (raw)
In-Reply-To: <ZjywddcaIae0W_w3@nanopsycho.orion>

On Thu, May 09, 2024 at 01:16:05PM +0200, Jiri Pirko wrote:
> Tue, May 07, 2024 at 01:45:09PM CEST, michal.swiatkowski@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.drewek@intel.com>
> >Signed-off-by: Michal Swiatkowski <michal.swiatkowski@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?

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	other threads:[~2024-05-10  7:31 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-07 11:45 [Intel-wired-lan] [iwl-next v1 00/14] ice: support devlink subfunction Michal Swiatkowski
2024-05-07 11:45 ` Michal Swiatkowski
2024-05-07 11:45 ` [Intel-wired-lan] [iwl-next v1 01/14] ice: add new VSI type for subfunctions Michal Swiatkowski
2024-05-07 11:45   ` Michal Swiatkowski
2024-05-07 11:45 ` [Intel-wired-lan] [iwl-next v1 02/14] ice: export ice ndo_ops functions Michal Swiatkowski
2024-05-07 11:45   ` Michal Swiatkowski
2024-05-07 11:45 ` [Intel-wired-lan] [iwl-next v1 03/14] ice: add basic devlink subfunctions support Michal Swiatkowski
2024-05-07 11:45   ` Michal Swiatkowski
2024-05-09 11:06   ` [Intel-wired-lan] " Jiri Pirko
2024-05-09 11:06     ` Jiri Pirko
2024-05-10  7:13     ` [Intel-wired-lan] " Michal Swiatkowski
2024-05-10  7:13       ` Michal Swiatkowski
2024-05-10 11:05       ` [Intel-wired-lan] " Jiri Pirko
2024-05-10 11:05         ` Jiri Pirko
2024-05-10 12:25         ` [Intel-wired-lan] " Michal Swiatkowski
2024-05-10 12:25           ` Michal Swiatkowski
2024-05-07 11:45 ` [Intel-wired-lan] [iwl-next v1 04/14] ice: treat subfunction VSI the same as PF VSI Michal Swiatkowski
2024-05-07 11:45   ` Michal Swiatkowski
2024-05-07 11:45 ` [Intel-wired-lan] [iwl-next v1 05/14] ice: allocate devlink for subfunction Michal Swiatkowski
2024-05-07 11:45   ` Michal Swiatkowski
2024-05-07 11:45 ` [Intel-wired-lan] [iwl-next v1 06/14] ice: base subfunction aux driver Michal Swiatkowski
2024-05-07 11:45   ` Michal Swiatkowski
2024-05-09 11:13   ` [Intel-wired-lan] " Jiri Pirko
2024-05-09 11:13     ` Jiri Pirko
2024-05-10  7:20     ` [Intel-wired-lan] " Michal Swiatkowski
2024-05-10  7:20       ` Michal Swiatkowski
2024-05-10 11:06       ` [Intel-wired-lan] " Jiri Pirko
2024-05-10 11:06         ` Jiri Pirko
2024-05-07 11:45 ` [Intel-wired-lan] [iwl-next v1 07/14] ice: implement netdev for subfunction Michal Swiatkowski
2024-05-07 11:45   ` Michal Swiatkowski
2024-05-07 11:45 ` [Intel-wired-lan] [iwl-next v1 08/14] ice: create port representor for SF Michal Swiatkowski
2024-05-07 11:45   ` Michal Swiatkowski
2024-05-09 11:16   ` [Intel-wired-lan] " Jiri Pirko
2024-05-09 11:16     ` Jiri Pirko
2024-05-10  7:31     ` Michal Swiatkowski [this message]
2024-05-10  7:31       ` Michal Swiatkowski
2024-05-10 11:07       ` [Intel-wired-lan] " Jiri Pirko
2024-05-10 11:07         ` Jiri Pirko
2024-05-10 12:25         ` [Intel-wired-lan] " Michal Swiatkowski
2024-05-10 12:25           ` Michal Swiatkowski
2024-05-07 11:45 ` [Intel-wired-lan] [iwl-next v1 09/14] ice: don't set target VSI for subfunction Michal Swiatkowski
2024-05-07 11:45   ` Michal Swiatkowski
2024-05-07 11:45 ` [Intel-wired-lan] [iwl-next v1 10/14] ice: check if SF is ready in ethtool ops Michal Swiatkowski
2024-05-07 11:45   ` Michal Swiatkowski
2024-05-07 11:45 ` [Intel-wired-lan] [iwl-next v1 11/14] ice: netdevice ops for SF representor Michal Swiatkowski
2024-05-07 11:45   ` Michal Swiatkowski
2024-05-09 11:17   ` [Intel-wired-lan] " Jiri Pirko
2024-05-09 11:17     ` Jiri Pirko
2024-05-10  7:25     ` [Intel-wired-lan] " Michal Swiatkowski
2024-05-10  7:25       ` Michal Swiatkowski
2024-05-07 11:45 ` [Intel-wired-lan] [iwl-next v1 12/14] ice: support subfunction devlink Tx topology Michal Swiatkowski
2024-05-07 11:45   ` Michal Swiatkowski
2024-05-07 11:45 ` [Intel-wired-lan] [iwl-next v1 13/14] ice: basic support for VLAN in subfunctions Michal Swiatkowski
2024-05-07 11:45   ` Michal Swiatkowski
2024-05-07 11:45 ` [Intel-wired-lan] [iwl-next v1 14/14] ice: allow to activate and deactivate subfunction Michal Swiatkowski
2024-05-07 11:45   ` Michal Swiatkowski
2024-05-09 11:36   ` [Intel-wired-lan] " Jiri Pirko
2024-05-09 11:36     ` Jiri Pirko
2024-05-10  7:33     ` [Intel-wired-lan] " Michal Swiatkowski
2024-05-10  7:33       ` Michal Swiatkowski
2024-05-10 11:08       ` [Intel-wired-lan] " Jiri Pirko
2024-05-10 11:08         ` Jiri Pirko
2024-05-09 11:18 ` [Intel-wired-lan] [iwl-next v1 00/14] ice: support devlink subfunction Jiri Pirko
2024-05-09 11:18   ` Jiri Pirko
2024-05-10  7:24   ` [Intel-wired-lan] " Michal Swiatkowski
2024-05-10  7:24     ` Michal Swiatkowski
2024-05-10 11:09     ` [Intel-wired-lan] " Jiri Pirko
2024-05-10 11:09       ` Jiri Pirko
2024-05-10 12:26       ` [Intel-wired-lan] " Michal Swiatkowski
2024-05-10 12:26         ` Michal Swiatkowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Zj3NQw1BxqtOS9VG@mev-dev \
    --to=michal.swiatkowski@linux.intel.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=jacob.e.keller@intel.com \
    --cc=jiri@nvidia.com \
    --cc=jiri@resnulli.us \
    --cc=maciej.fijalkowski@intel.com \
    --cc=mateusz.polchlopek@intel.com \
    --cc=michal.kubiak@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=pio.raczynski@gmail.com \
    --cc=przemyslaw.kitszel@intel.com \
    --cc=shayd@nvidia.com \
    --cc=sridhar.samudrala@intel.com \
    --cc=wojciech.drewek@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.