netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
To: Jiri Pirko <jiri@resnulli.us>
Cc: maciej.fijalkowski@intel.com, netdev@vger.kernel.org,
	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 v1 04/15] ice: add basic devlink subfunctions support
Date: Tue, 13 Feb 2024 13:02:43 +0100	[thread overview]
Message-ID: <ZctaY7AfjS/N2J9X@mev-dev> (raw)
In-Reply-To: <ZctSGPf6v0QlfMUu@nanopsycho>

On Tue, Feb 13, 2024 at 12:27:20PM +0100, Jiri Pirko wrote:
> Tue, Feb 13, 2024 at 10:39:47AM CET, michal.swiatkowski@linux.intel.com wrote:
> >On Tue, Feb 13, 2024 at 09:55:20AM +0100, Jiri Pirko wrote:
> >> Tue, Feb 13, 2024 at 08:27:13AM CET, michal.swiatkowski@linux.intel.com wrote:
> >> >From: Piotr Raczynski <piotr.raczynski@intel.com>
> 
> [...]
> 
> 
> >
> >> 
> >> >+}
> >> >+
> >> >+/**
> >> >+ * ice_dealloc_dynamic_port - Deallocate and remove a dynamic port
> >> >+ * @dyn_port: dynamic port instance to deallocate
> >> >+ *
> >> >+ * Free resources associated with a dynamically added devlink port. Will
> >> >+ * deactivate the port if its currently active.
> >> >+ */
> >> >+static void ice_dealloc_dynamic_port(struct ice_dynamic_port *dyn_port)
> >> >+{
> >> >+	struct devlink_port *devlink_port = &dyn_port->devlink_port;
> >> >+	struct ice_pf *pf = dyn_port->pf;
> >> >+
> >> >+	if (dyn_port->active)
> >> >+		ice_deactivate_dynamic_port(dyn_port);
> >> >+
> >> >+	if (devlink_port->attrs.flavour == DEVLINK_PORT_FLAVOUR_PCI_SF)
> >> 
> >> I don't understand how this check could be false. Remove it.
> >>
> >Yeah, will remove
> >
> >> 
> >> >+		xa_erase(&pf->sf_nums, devlink_port->attrs.pci_sf.sf);
> >> >+
> >> >+	devl_port_unregister(devlink_port);
> >> >+	ice_vsi_free(dyn_port->vsi);
> >> >+	xa_erase(&pf->dyn_ports, dyn_port->vsi->idx);
> >> >+	kfree(dyn_port);
> >> >+}
> >> >+
> >> >+/**
> >> >+ * ice_dealloc_all_dynamic_ports - Deallocate all dynamic devlink ports
> >> >+ * @pf: pointer to the pf structure
> >> >+ */
> >> >+void ice_dealloc_all_dynamic_ports(struct ice_pf *pf)
> >> >+{
> >> >+	struct devlink *devlink = priv_to_devlink(pf);
> >> >+	struct ice_dynamic_port *dyn_port;
> >> >+	unsigned long index;
> >> >+
> >> >+	devl_lock(devlink);
> >> >+	xa_for_each(&pf->dyn_ports, index, dyn_port)
> >> >+		ice_dealloc_dynamic_port(dyn_port);
> >> >+	devl_unlock(devlink);
> >> 
> >> Hmm, I would assume that the called should already hold the devlink
> >> instance lock when doing remove. What is stopping user from issuing
> >> port_new command here, after devl_unlock()?
> >>
> >It is only called from remove path, but I can move it upper.
> 
> I know it is called on remove path. Again, what is stopping user from
> issuing port_new after ice_dealloc_all_dynamic_ports() is called?
> 
> [...]
> 
What is a problem here? Calling port_new from user perspective will have
devlink lock, right? Do you mean that devlink lock should be taken for
whole cleanup, so from the start to the moment when devlink is
unregister? I wrote that, I will do that in next version (moving it
upper).

> 
> >> 
> >> >+	struct device *dev = ice_pf_to_dev(pf);
> >> >+	int err;
> >> >+
> >> >+	dev_dbg(dev, "%s flavour:%d index:%d pfnum:%d\n", __func__,
> >> >+		new_attr->flavour, new_attr->port_index, new_attr->pfnum);
> >> 
> >> How this message could ever help anyone?
> >>
> >Probably only developer of the code :p, will remove it
> 
> How exactly?
>
I meant this code developer, it probably was used to check if number and
indexes are correct, but now it should be removed. Like, leftover after
developing, sorry.

> [...]
> 
> 
> >> >+static int ice_sf_cfg_netdev(struct ice_dynamic_port *dyn_port)
> >> >+{
> >> >+	struct net_device *netdev;
> >> >+	struct ice_vsi *vsi = dyn_port->vsi;
> >> >+	struct ice_netdev_priv *np;
> >> >+	int err;
> >> >+
> >> >+	netdev = alloc_etherdev_mqs(sizeof(*np), vsi->alloc_txq,
> >> >+				    vsi->alloc_rxq);
> >> >+	if (!netdev)
> >> >+		return -ENOMEM;
> >> >+
> >> >+	SET_NETDEV_DEV(netdev, &vsi->back->pdev->dev);
> >> >+	set_bit(ICE_VSI_NETDEV_ALLOCD, vsi->state);
> >> >+	vsi->netdev = netdev;
> >> >+	np = netdev_priv(netdev);
> >> >+	np->vsi = vsi;
> >> >+
> >> >+	ice_set_netdev_features(netdev);
> >> >+
> >> >+	netdev->xdp_features = NETDEV_XDP_ACT_BASIC | NETDEV_XDP_ACT_REDIRECT |
> >> >+			       NETDEV_XDP_ACT_XSK_ZEROCOPY |
> >> >+			       NETDEV_XDP_ACT_RX_SG;
> >> >+
> >> >+	eth_hw_addr_set(netdev, dyn_port->hw_addr);
> >> >+	ether_addr_copy(netdev->perm_addr, dyn_port->hw_addr);
> >> >+	netdev->netdev_ops = &ice_sf_netdev_ops;
> >> >+	SET_NETDEV_DEVLINK_PORT(netdev, &dyn_port->devlink_port);
> >> >+
> >> >+	err = register_netdev(netdev);
> >> 
> >> It the the actual subfunction or eswitch port representor of the
> >> subfunction. Looks like the port representor. In that case. It should be
> >> created no matter if the subfunction is activated, when it it created.
> >> 
> >> If this is the actual subfunction netdev, you should not link it to
> >> devlink port here.
> >>
> >This is the actual subfunction netdev. Where in this case it should be
> >linked?
> 
> To the SF auxdev, obviously.
> 
> Here, you should have eswitch port representor netdev.
> 
Oh, ok, thanks, will link it correctly in next version.


  reply	other threads:[~2024-02-13 12:02 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-13  7:27 [iwl-next v1 00/15] ice: support devlink subfunctions Michal Swiatkowski
2024-02-13  7:27 ` [iwl-next v1 01/15] ice: move devlink port code to a separate file Michal Swiatkowski
2024-02-13  7:27 ` [iwl-next v1 02/15] ice: add new VSI type for subfunctions Michal Swiatkowski
2024-02-13  7:27 ` [iwl-next v1 03/15] ice: export ice ndo_ops functions Michal Swiatkowski
2024-02-13  7:27 ` [iwl-next v1 04/15] ice: add basic devlink subfunctions support Michal Swiatkowski
2024-02-13  8:55   ` Jiri Pirko
2024-02-13  9:39     ` [Intel-wired-lan] " Michal Swiatkowski
2024-02-13 11:27       ` Jiri Pirko
2024-02-13 12:02         ` Michal Swiatkowski [this message]
2024-02-13 14:57           ` Jiri Pirko
2024-02-14  6:26             ` Michal Swiatkowski
2024-02-14 19:45     ` Jacob Keller
2024-02-13  7:27 ` [iwl-next v1 05/15] ice: add subfunctions ethtool ops Michal Swiatkowski
2024-02-13  7:27 ` [iwl-next v1 06/15] ice: add subfunction aux driver support Michal Swiatkowski
2024-02-13  8:57   ` Jiri Pirko
2024-02-13  9:43     ` Michal Swiatkowski
2024-02-13 11:28       ` Jiri Pirko
2024-02-13 12:03         ` Michal Swiatkowski
2024-02-13  7:27 ` [iwl-next v1 07/15] ice: add auxiliary device sfnum attribute Michal Swiatkowski
2024-02-13  8:59   ` Jiri Pirko
2024-02-13  9:53     ` Michal Swiatkowski
2024-02-13 11:29       ` Jiri Pirko
2024-02-13 11:55         ` Michal Swiatkowski
2024-02-13 22:04           ` Jacob Keller
2024-02-14  8:45             ` Jiri Pirko
2024-02-14 19:41               ` Keller, Jacob E
2024-02-13  7:27 ` [iwl-next v1 08/15] ice: store SF data in VSI struct Michal Swiatkowski
2024-02-13  7:27 ` [iwl-next v1 09/15] ice: store representor ID in bridge port Michal Swiatkowski
2024-02-13  7:27 ` [iwl-next v1 10/15] ice: create port representor for SF Michal Swiatkowski
2024-02-13  9:00   ` Jiri Pirko
2024-02-13  9:55     ` Michal Swiatkowski
2024-02-13  7:27 ` [iwl-next v1 11/15] ice: check if SF is ready in ethtool ops Michal Swiatkowski
2024-02-13  7:27 ` [iwl-next v1 12/15] ice: netdevice ops for SF representor Michal Swiatkowski
2024-02-13  7:27 ` [iwl-next v1 13/15] ice: support subfunction devlink Tx topology Michal Swiatkowski
2024-02-13  7:27 ` [iwl-next v1 14/15] ice: basic support for VLAN in subfunctions Michal Swiatkowski
2024-02-13  7:27 ` [iwl-next v1 15/15] ice: move ice_devlink.[ch] to devlink folder 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=ZctaY7AfjS/N2J9X@mev-dev \
    --to=michal.swiatkowski@linux.intel.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=jacob.e.keller@intel.com \
    --cc=jiri@resnulli.us \
    --cc=maciej.fijalkowski@intel.com \
    --cc=michal.kubiak@intel.com \
    --cc=netdev@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).