From: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
To: Jiri Pirko <jiri@resnulli.us>
Cc: maciej.fijalkowski@intel.com, sridhar.samudrala@intel.com,
netdev@vger.kernel.org, mateusz.polchlopek@intel.com,
wojciech.drewek@intel.com, michal.kubiak@intel.com,
intel-wired-lan@lists.osuosl.org, pio.raczynski@gmail.com,
jiri@nvidia.com, jacob.e.keller@intel.com,
nex.sw.ncis.osdt.itp.upstreaming@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: Tue, 16 Apr 2024 08:16:17 +0200 [thread overview]
Message-ID: <Zh4XsXwDxeu936kw@mev-dev> (raw)
In-Reply-To: <Zh4JQ4RDRIAYC+V7@mev-dev>
On Tue, Apr 16, 2024 at 07:14:43AM +0200, Michal Swiatkowski wrote:
> On Mon, Apr 15, 2024 at 11:10:50AM +0200, Jiri Pirko wrote:
> > 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?
> >
>
> I don't take PF devlink lock here. Only subfunction devlink lock is
> taken during the initialization of subfunction.
>
Did you mean that the devlink lock is taken for DEVLINK_CMD_PORT_SET/GET
command? In this case, I think so, it is for the whole time of the
command execution.
Sorry I probably missed the point.
> > >
> > >>
> > >> >+ } else {
> > >> >+ *state = DEVLINK_PORT_FN_STATE_INACTIVE;
> > >> >+ *opstate = DEVLINK_PORT_FN_OPSTATE_DETACHED;
> > >> >+ }
> > >> >+
> > >> >+ return 0;
> > >> >+}
> > >> >+
> >
> > [...]
WARNING: multiple messages have this Message-ID (diff)
From: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
To: Jiri Pirko <jiri@resnulli.us>
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: Tue, 16 Apr 2024 08:16:17 +0200 [thread overview]
Message-ID: <Zh4XsXwDxeu936kw@mev-dev> (raw)
In-Reply-To: <Zh4JQ4RDRIAYC+V7@mev-dev>
On Tue, Apr 16, 2024 at 07:14:43AM +0200, Michal Swiatkowski wrote:
> On Mon, Apr 15, 2024 at 11:10:50AM +0200, Jiri Pirko wrote:
> > 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?
> >
>
> I don't take PF devlink lock here. Only subfunction devlink lock is
> taken during the initialization of subfunction.
>
Did you mean that the devlink lock is taken for DEVLINK_CMD_PORT_SET/GET
command? In this case, I think so, it is for the whole time of the
command execution.
Sorry I probably missed the point.
> > >
> > >>
> > >> >+ } else {
> > >> >+ *state = DEVLINK_PORT_FN_STATE_INACTIVE;
> > >> >+ *opstate = DEVLINK_PORT_FN_OPSTATE_DETACHED;
> > >> >+ }
> > >> >+
> > >> >+ return 0;
> > >> >+}
> > >> >+
> >
> > [...]
next prev parent reply other threads:[~2024-04-16 6:16 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 ` [Intel-wired-lan] " Jiri Pirko
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 ` Michal Swiatkowski [this message]
2024-04-16 6:16 ` [Intel-wired-lan] " 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=Zh4XsXwDxeu936kw@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=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.