All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Pirko <jiri@resnulli.us>
To: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
Cc: maciej.fijalkowski@intel.com, mateusz.polchlopek@intel.com,
	nex.sw.ncis.osdt.itp.upstreaming@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,
	Piotr Raczynski <piotr.raczynski@intel.com>,
	przemyslaw.kitszel@intel.com
Subject: Re: [Intel-wired-lan] [iwl-next v3 3/7] ice: add basic devlink subfunctions support
Date: Mon, 15 Apr 2024 11:10:50 +0200	[thread overview]
Message-ID: <ZhzvGlDiuaPSEHCX@nanopsycho> (raw)
In-Reply-To: <Zhzny769lYYmLUs0@mev-dev>

Mon, Apr 15, 2024 at 10:39:39AM CEST, michal.swiatkowski@linux.intel.com wrote:
>On Fri, Apr 12, 2024 at 09:12:18AM +0200, Jiri Pirko wrote:
>> Fri, Apr 12, 2024 at 08:30:49AM CEST, michal.swiatkowski@linux.intel.com wrote:
>> >From: Piotr Raczynski <piotr.raczynski@intel.com>

[...]

>> >+static int
>> >+ice_devlink_port_fn_state_get(struct devlink_port *port,
>> >+			      enum devlink_port_fn_state *state,
>> >+			      enum devlink_port_fn_opstate *opstate,
>> >+			      struct netlink_ext_ack *extack)
>> >+{
>> >+	struct ice_dynamic_port *dyn_port;
>> >+
>> >+	dyn_port = ice_devlink_port_to_dyn(port);
>> >+
>> >+	if (dyn_port->active) {
>> >+		*state = DEVLINK_PORT_FN_STATE_ACTIVE;
>> >+		*opstate = DEVLINK_PORT_FN_OPSTATE_ATTACHED;
>> 
>> Interesting. This means that you don't distinguish between admin state
>> and operational state. Meaning, when user does activate, you atomically
>> achive the hw attachment and it is ready to go before activation cmd
>> returns, correct? I'm just making sure I understand the code.
>> 
>
>I am setting the dyn_port->active after the activation heppens, so it is
>true, when active is set it is ready to go.
>
>Do you mean that dyn_port->active should be set even before the activation is
>finished? I mean when user only call devlink to active the port?

The devlink instance lock is taken the whole time, isn't it?

>
>> 
>> >+	} else {
>> >+		*state = DEVLINK_PORT_FN_STATE_INACTIVE;
>> >+		*opstate = DEVLINK_PORT_FN_OPSTATE_DETACHED;
>> >+	}
>> >+
>> >+	return 0;
>> >+}
>> >+

[...]

WARNING: multiple messages have this Message-ID (diff)
From: Jiri Pirko <jiri@resnulli.us>
To: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
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,
	nex.sw.ncis.osdt.itp.upstreaming@intel.com,
	mateusz.polchlopek@intel.com,
	Piotr Raczynski <piotr.raczynski@intel.com>
Subject: Re: [iwl-next v3 3/7] ice: add basic devlink subfunctions support
Date: Mon, 15 Apr 2024 11:10:50 +0200	[thread overview]
Message-ID: <ZhzvGlDiuaPSEHCX@nanopsycho> (raw)
In-Reply-To: <Zhzny769lYYmLUs0@mev-dev>

Mon, Apr 15, 2024 at 10:39:39AM CEST, michal.swiatkowski@linux.intel.com wrote:
>On Fri, Apr 12, 2024 at 09:12:18AM +0200, Jiri Pirko wrote:
>> Fri, Apr 12, 2024 at 08:30:49AM CEST, michal.swiatkowski@linux.intel.com wrote:
>> >From: Piotr Raczynski <piotr.raczynski@intel.com>

[...]

>> >+static int
>> >+ice_devlink_port_fn_state_get(struct devlink_port *port,
>> >+			      enum devlink_port_fn_state *state,
>> >+			      enum devlink_port_fn_opstate *opstate,
>> >+			      struct netlink_ext_ack *extack)
>> >+{
>> >+	struct ice_dynamic_port *dyn_port;
>> >+
>> >+	dyn_port = ice_devlink_port_to_dyn(port);
>> >+
>> >+	if (dyn_port->active) {
>> >+		*state = DEVLINK_PORT_FN_STATE_ACTIVE;
>> >+		*opstate = DEVLINK_PORT_FN_OPSTATE_ATTACHED;
>> 
>> Interesting. This means that you don't distinguish between admin state
>> and operational state. Meaning, when user does activate, you atomically
>> achive the hw attachment and it is ready to go before activation cmd
>> returns, correct? I'm just making sure I understand the code.
>> 
>
>I am setting the dyn_port->active after the activation heppens, so it is
>true, when active is set it is ready to go.
>
>Do you mean that dyn_port->active should be set even before the activation is
>finished? I mean when user only call devlink to active the port?

The devlink instance lock is taken the whole time, isn't it?

>
>> 
>> >+	} else {
>> >+		*state = DEVLINK_PORT_FN_STATE_INACTIVE;
>> >+		*opstate = DEVLINK_PORT_FN_OPSTATE_DETACHED;
>> >+	}
>> >+
>> >+	return 0;
>> >+}
>> >+

[...]

  reply	other threads:[~2024-04-15  9:11 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-12  6:30 [Intel-wired-lan] [iwl-next v3 0/7] ice: support devlink subfunction Michal Swiatkowski
2024-04-12  6:30 ` Michal Swiatkowski
2024-04-12  6:30 ` [Intel-wired-lan] [iwl-next v3 1/7] ice: add new VSI type for subfunctions Michal Swiatkowski
2024-04-12  6:30   ` Michal Swiatkowski
2024-04-12  6:30 ` [Intel-wired-lan] [iwl-next v3 2/7] ice: export ice ndo_ops functions Michal Swiatkowski
2024-04-12  6:30   ` Michal Swiatkowski
2024-04-12  6:30 ` [Intel-wired-lan] [iwl-next v3 3/7] ice: add basic devlink subfunctions support Michal Swiatkowski
2024-04-12  6:30   ` Michal Swiatkowski
2024-04-12  7:12   ` [Intel-wired-lan] " Jiri Pirko
2024-04-12  7:12     ` Jiri Pirko
2024-04-15  8:39     ` [Intel-wired-lan] " Michal Swiatkowski
2024-04-15  8:39       ` Michal Swiatkowski
2024-04-15  9:10       ` Jiri Pirko [this message]
2024-04-15  9:10         ` Jiri Pirko
2024-04-16  5:14         ` [Intel-wired-lan] " Michal Swiatkowski
2024-04-16  5:14           ` Michal Swiatkowski
2024-04-16  6:16           ` [Intel-wired-lan] " Michal Swiatkowski
2024-04-16  6:16             ` Michal Swiatkowski
2024-04-16 12:09             ` Jiri Pirko
2024-04-16 12:09               ` Jiri Pirko
2024-04-12  6:30 ` [Intel-wired-lan] [iwl-next v3 4/7] ice: allocate devlink for subfunction Michal Swiatkowski
2024-04-12  6:30   ` Michal Swiatkowski
2024-04-12  7:24   ` [Intel-wired-lan] " Jiri Pirko
2024-04-12  7:24     ` Jiri Pirko
2024-04-15  8:40     ` [Intel-wired-lan] " Michal Swiatkowski
2024-04-15  8:40       ` Michal Swiatkowski
2024-04-12  6:30 ` [Intel-wired-lan] [iwl-next v3 5/7] ice: base subfunction aux driver Michal Swiatkowski
2024-04-12  6:30   ` Michal Swiatkowski
2024-04-12  7:20   ` [Intel-wired-lan] " Jiri Pirko
2024-04-12  7:20     ` Jiri Pirko
2024-04-12 11:44   ` [Intel-wired-lan] " Przemek Kitszel
2024-04-12 11:44     ` Przemek Kitszel
2024-04-15  8:29     ` [Intel-wired-lan] " Michal Swiatkowski
2024-04-15  8:29       ` Michal Swiatkowski
2024-04-12  6:30 ` [Intel-wired-lan] [iwl-next v3 6/7] ice: implement netdev for subfunction Michal Swiatkowski
2024-04-12  6:30   ` Michal Swiatkowski
2024-04-12  7:21   ` [Intel-wired-lan] " Jiri Pirko
2024-04-12  7:21     ` Jiri Pirko
2024-04-12  6:30 ` [Intel-wired-lan] [iwl-next v3 7/7] ice: allow to activate and deactivate subfunction Michal Swiatkowski
2024-04-12  6:30   ` 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=ZhzvGlDiuaPSEHCX@nanopsycho \
    --to=jiri@resnulli.us \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=jacob.e.keller@intel.com \
    --cc=jiri@nvidia.com \
    --cc=maciej.fijalkowski@intel.com \
    --cc=mateusz.polchlopek@intel.com \
    --cc=michal.kubiak@intel.com \
    --cc=michal.swiatkowski@linux.intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=nex.sw.ncis.osdt.itp.upstreaming@intel.com \
    --cc=pio.raczynski@gmail.com \
    --cc=piotr.raczynski@intel.com \
    --cc=przemyslaw.kitszel@intel.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.