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 03/14] ice: add basic devlink subfunctions support
Date: Fri, 10 May 2024 14:25:00 +0200	[thread overview]
Message-ID: <Zj4SHGvuxZWQEYuN@mev-dev> (raw)
In-Reply-To: <Zj3_fVh2QD7awpWN@nanopsycho.orion>

On Fri, May 10, 2024 at 01:05:33PM +0200, Jiri Pirko wrote:
> Fri, May 10, 2024 at 09:13:51AM CEST, michal.swiatkowski@linux.intel.com wrote:
> >On Thu, May 09, 2024 at 01:06:52PM +0200, Jiri Pirko wrote:
> >> Tue, May 07, 2024 at 01:45:04PM CEST, michal.swiatkowski@linux.intel.com wrote:
> >> >From: Piotr Raczynski <piotr.raczynski@intel.com>
> >> >
> >> >Implement devlink port handlers responsible for ethernet type devlink
> >> >subfunctions. Create subfunction devlink port and setup all resources
> >> >needed for a subfunction netdev to operate. Configure new VSI for each
> >> >new subfunction, initialize and configure interrupts and Tx/Rx resources.
> >> >Set correct MAC filters and create new netdev.
> >> >
> >> >For now, subfunction is limited to only one Tx/Rx queue pair.
> >> >
> >> >Only allocate new subfunction VSI with devlink port new command.
> >> >This makes sure that real resources are configured only when a new
> >> >subfunction gets activated. Allocate and free subfunction MSIX
> >> 
> >> Interesting. You talk about actitation, yet you don't implement it here.
> >> 
> >
> >I will rephrase it. I meant that new VSI needs to be created even before
> >any activation or configuration.
> >
> >> 
> >> 
> >> >interrupt vectors using new API calls with pci_msix_alloc_irq_at
> >> >and pci_msix_free_irq.
> >> >
> >> >Support both automatic and manual subfunction numbers. If no subfunction
> >> >number is provided, use xa_alloc to pick a number automatically. This
> >> >will find the first free index and use that as the number. This reduces
> >> >burden on users in the simple case where a specific number is not
> >> >required. It may also be slightly faster to check that a number exists
> >> >since xarray lookup should be faster than a linear scan of the dyn_ports
> >> >xarray.
> >> >
> >> >Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com>
> >> >Co-developed-by: Jacob Keller <jacob.e.keller@intel.com>
> >> >Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> >> >Signed-off-by: Piotr Raczynski <piotr.raczynski@intel.com>
> >> >Signed-off-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
> >> >---
> >> > .../net/ethernet/intel/ice/devlink/devlink.c  |   3 +
> >> > .../ethernet/intel/ice/devlink/devlink_port.c | 357 ++++++++++++++++++
> >> > .../ethernet/intel/ice/devlink/devlink_port.h |  33 ++
> >> > drivers/net/ethernet/intel/ice/ice.h          |   4 +
> >> > drivers/net/ethernet/intel/ice/ice_lib.c      |   5 +-
> >> > drivers/net/ethernet/intel/ice/ice_lib.h      |   2 +
> >> > drivers/net/ethernet/intel/ice/ice_main.c     |   9 +-
> >> > 7 files changed, 410 insertions(+), 3 deletions(-)
> >> >
> >> >diff --git a/drivers/net/ethernet/intel/ice/devlink/devlink.c b/drivers/net/ethernet/intel/ice/devlink/devlink.c
> >> >index 10073342e4f0..3fb3a7e828a4 100644
> >> >--- a/drivers/net/ethernet/intel/ice/devlink/devlink.c
> >> >+++ b/drivers/net/ethernet/intel/ice/devlink/devlink.c
> >> >@@ -6,6 +6,7 @@
> >> > #include "ice.h"
> >> > #include "ice_lib.h"
> >> > #include "devlink.h"
> >> >+#include "devlink_port.h"
> >> > #include "ice_eswitch.h"
> >> > #include "ice_fw_update.h"
> >> > #include "ice_dcb_lib.h"
> >> >@@ -1277,6 +1278,8 @@ static const struct devlink_ops ice_devlink_ops = {
> >> > 
> >> > 	.rate_leaf_parent_set = ice_devlink_set_parent,
> >> > 	.rate_node_parent_set = ice_devlink_set_parent,
> >> >+
> >> >+	.port_new = ice_devlink_port_new,
> >> > };
> >> > 
> >> >+
> >
> >[...]
> >
> >> >+/**
> >> >+ * ice_devlink_port_fn_hw_addr_set - devlink handler for mac address set
> >> >+ * @port: pointer to devlink port
> >> >+ * @hw_addr: hw address to set
> >> >+ * @hw_addr_len: hw address length
> >> >+ * @extack: extack for reporting error messages
> >> >+ *
> >> >+ * Sets mac address for the port, verifies arguments and copies address
> >> >+ * to the subfunction structure.
> >> >+ *
> >> >+ * Return: zero on success or an error code on failure.
> >> >+ */
> >> >+static int
> >> >+ice_devlink_port_fn_hw_addr_set(struct devlink_port *port, const u8 *hw_addr,
> >> >+				int hw_addr_len,
> >> >+				struct netlink_ext_ack *extack)
> >> >+{
> >> >+	struct ice_dynamic_port *dyn_port;
> >> >+
> >> >+	dyn_port = ice_devlink_port_to_dyn(port);
> >> >+
> >> >+	if (hw_addr_len != ETH_ALEN || !is_valid_ether_addr(hw_addr)) {
> >> >+		NL_SET_ERR_MSG_MOD(extack, "Invalid ethernet address");
> >> >+		return -EADDRNOTAVAIL;
> >> >+	}
> >> >+
> >> >+	ether_addr_copy(dyn_port->hw_addr, hw_addr);
> >> 
> >> How does this work? You copy the address to the internal structure, but
> >> where you update the HW?
> >>
> >
> >When the basic MAC filter is added in HW.
> 
> When is that. My point is, user can all this function at any time, and
> when he calls it, he expect it's applied right away. In case it can't be
> for example applied on activated SF, you should block the request.
> 
> 

Good point, I will block the request in this case. The filter is added
during VSI configuration, in this case during SF activation.

> >
> >> 
> >> >+
> >> >+	return 0;
> >> >+}
> >
> >[...]
> >
> >> > 
> >> >@@ -5383,6 +5389,7 @@ static void ice_remove(struct pci_dev *pdev)
> >> > 		ice_remove_arfs(pf);
> >> > 
> >> > 	devl_lock(priv_to_devlink(pf));
> >> >+	ice_dealloc_all_dynamic_ports(pf);
> >> > 	ice_deinit_devlink(pf);
> >> > 
> >> > 	ice_unload(pf);
> >> >@@ -6677,7 +6684,7 @@ static int ice_up_complete(struct ice_vsi *vsi)
> >> > 
> >> > 	if (vsi->port_info &&
> >> > 	    (vsi->port_info->phy.link_info.link_info & ICE_AQ_LINK_UP) &&
> >> >-	    vsi->netdev && vsi->type == ICE_VSI_PF) {
> >> >+	    ((vsi->netdev && vsi->type == ICE_VSI_PF))) {
> >> 
> >> I think this is some leftover, remove.
> >>
> >
> >Yeah, thanks, will remove it.
> >
> >> 
> >> > 		ice_print_link_msg(vsi, true);
> >> > 		netif_tx_start_all_queues(vsi->netdev);
> >> > 		netif_carrier_on(vsi->netdev);
> >> >-- 
> >> >2.42.0
> >> >
> >> >

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 03/14] ice: add basic devlink subfunctions support
Date: Fri, 10 May 2024 14:25:00 +0200	[thread overview]
Message-ID: <Zj4SHGvuxZWQEYuN@mev-dev> (raw)
In-Reply-To: <Zj3_fVh2QD7awpWN@nanopsycho.orion>

On Fri, May 10, 2024 at 01:05:33PM +0200, Jiri Pirko wrote:
> Fri, May 10, 2024 at 09:13:51AM CEST, michal.swiatkowski@linux.intel.com wrote:
> >On Thu, May 09, 2024 at 01:06:52PM +0200, Jiri Pirko wrote:
> >> Tue, May 07, 2024 at 01:45:04PM CEST, michal.swiatkowski@linux.intel.com wrote:
> >> >From: Piotr Raczynski <piotr.raczynski@intel.com>
> >> >
> >> >Implement devlink port handlers responsible for ethernet type devlink
> >> >subfunctions. Create subfunction devlink port and setup all resources
> >> >needed for a subfunction netdev to operate. Configure new VSI for each
> >> >new subfunction, initialize and configure interrupts and Tx/Rx resources.
> >> >Set correct MAC filters and create new netdev.
> >> >
> >> >For now, subfunction is limited to only one Tx/Rx queue pair.
> >> >
> >> >Only allocate new subfunction VSI with devlink port new command.
> >> >This makes sure that real resources are configured only when a new
> >> >subfunction gets activated. Allocate and free subfunction MSIX
> >> 
> >> Interesting. You talk about actitation, yet you don't implement it here.
> >> 
> >
> >I will rephrase it. I meant that new VSI needs to be created even before
> >any activation or configuration.
> >
> >> 
> >> 
> >> >interrupt vectors using new API calls with pci_msix_alloc_irq_at
> >> >and pci_msix_free_irq.
> >> >
> >> >Support both automatic and manual subfunction numbers. If no subfunction
> >> >number is provided, use xa_alloc to pick a number automatically. This
> >> >will find the first free index and use that as the number. This reduces
> >> >burden on users in the simple case where a specific number is not
> >> >required. It may also be slightly faster to check that a number exists
> >> >since xarray lookup should be faster than a linear scan of the dyn_ports
> >> >xarray.
> >> >
> >> >Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com>
> >> >Co-developed-by: Jacob Keller <jacob.e.keller@intel.com>
> >> >Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> >> >Signed-off-by: Piotr Raczynski <piotr.raczynski@intel.com>
> >> >Signed-off-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
> >> >---
> >> > .../net/ethernet/intel/ice/devlink/devlink.c  |   3 +
> >> > .../ethernet/intel/ice/devlink/devlink_port.c | 357 ++++++++++++++++++
> >> > .../ethernet/intel/ice/devlink/devlink_port.h |  33 ++
> >> > drivers/net/ethernet/intel/ice/ice.h          |   4 +
> >> > drivers/net/ethernet/intel/ice/ice_lib.c      |   5 +-
> >> > drivers/net/ethernet/intel/ice/ice_lib.h      |   2 +
> >> > drivers/net/ethernet/intel/ice/ice_main.c     |   9 +-
> >> > 7 files changed, 410 insertions(+), 3 deletions(-)
> >> >
> >> >diff --git a/drivers/net/ethernet/intel/ice/devlink/devlink.c b/drivers/net/ethernet/intel/ice/devlink/devlink.c
> >> >index 10073342e4f0..3fb3a7e828a4 100644
> >> >--- a/drivers/net/ethernet/intel/ice/devlink/devlink.c
> >> >+++ b/drivers/net/ethernet/intel/ice/devlink/devlink.c
> >> >@@ -6,6 +6,7 @@
> >> > #include "ice.h"
> >> > #include "ice_lib.h"
> >> > #include "devlink.h"
> >> >+#include "devlink_port.h"
> >> > #include "ice_eswitch.h"
> >> > #include "ice_fw_update.h"
> >> > #include "ice_dcb_lib.h"
> >> >@@ -1277,6 +1278,8 @@ static const struct devlink_ops ice_devlink_ops = {
> >> > 
> >> > 	.rate_leaf_parent_set = ice_devlink_set_parent,
> >> > 	.rate_node_parent_set = ice_devlink_set_parent,
> >> >+
> >> >+	.port_new = ice_devlink_port_new,
> >> > };
> >> > 
> >> >+
> >
> >[...]
> >
> >> >+/**
> >> >+ * ice_devlink_port_fn_hw_addr_set - devlink handler for mac address set
> >> >+ * @port: pointer to devlink port
> >> >+ * @hw_addr: hw address to set
> >> >+ * @hw_addr_len: hw address length
> >> >+ * @extack: extack for reporting error messages
> >> >+ *
> >> >+ * Sets mac address for the port, verifies arguments and copies address
> >> >+ * to the subfunction structure.
> >> >+ *
> >> >+ * Return: zero on success or an error code on failure.
> >> >+ */
> >> >+static int
> >> >+ice_devlink_port_fn_hw_addr_set(struct devlink_port *port, const u8 *hw_addr,
> >> >+				int hw_addr_len,
> >> >+				struct netlink_ext_ack *extack)
> >> >+{
> >> >+	struct ice_dynamic_port *dyn_port;
> >> >+
> >> >+	dyn_port = ice_devlink_port_to_dyn(port);
> >> >+
> >> >+	if (hw_addr_len != ETH_ALEN || !is_valid_ether_addr(hw_addr)) {
> >> >+		NL_SET_ERR_MSG_MOD(extack, "Invalid ethernet address");
> >> >+		return -EADDRNOTAVAIL;
> >> >+	}
> >> >+
> >> >+	ether_addr_copy(dyn_port->hw_addr, hw_addr);
> >> 
> >> How does this work? You copy the address to the internal structure, but
> >> where you update the HW?
> >>
> >
> >When the basic MAC filter is added in HW.
> 
> When is that. My point is, user can all this function at any time, and
> when he calls it, he expect it's applied right away. In case it can't be
> for example applied on activated SF, you should block the request.
> 
> 

Good point, I will block the request in this case. The filter is added
during VSI configuration, in this case during SF activation.

> >
> >> 
> >> >+
> >> >+	return 0;
> >> >+}
> >
> >[...]
> >
> >> > 
> >> >@@ -5383,6 +5389,7 @@ static void ice_remove(struct pci_dev *pdev)
> >> > 		ice_remove_arfs(pf);
> >> > 
> >> > 	devl_lock(priv_to_devlink(pf));
> >> >+	ice_dealloc_all_dynamic_ports(pf);
> >> > 	ice_deinit_devlink(pf);
> >> > 
> >> > 	ice_unload(pf);
> >> >@@ -6677,7 +6684,7 @@ static int ice_up_complete(struct ice_vsi *vsi)
> >> > 
> >> > 	if (vsi->port_info &&
> >> > 	    (vsi->port_info->phy.link_info.link_info & ICE_AQ_LINK_UP) &&
> >> >-	    vsi->netdev && vsi->type == ICE_VSI_PF) {
> >> >+	    ((vsi->netdev && vsi->type == ICE_VSI_PF))) {
> >> 
> >> I think this is some leftover, remove.
> >>
> >
> >Yeah, thanks, will remove it.
> >
> >> 
> >> > 		ice_print_link_msg(vsi, true);
> >> > 		netif_tx_start_all_queues(vsi->netdev);
> >> > 		netif_carrier_on(vsi->netdev);
> >> >-- 
> >> >2.42.0
> >> >
> >> >

  reply	other threads:[~2024-05-10 12:25 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         ` Michal Swiatkowski [this message]
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     ` [Intel-wired-lan] " Michal Swiatkowski
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=Zj4SHGvuxZWQEYuN@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.