netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Saeed Mahameed <saeedm@nvidia.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Saeed Mahameed <saeed@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Paolo Abeni <pabeni@redhat.com>,
	Eric Dumazet <edumazet@google.com>,
	netdev@vger.kernel.org, Tariq Toukan <tariqt@nvidia.com>,
	Shay Drory <shayd@nvidia.com>, Moshe Shemesh <moshe@nvidia.com>
Subject: Re: [net-next 14/15] net/mlx5: Light probe local SFs
Date: Sat, 10 Jun 2023 21:15:57 -0700	[thread overview]
Message-ID: <ZIVKfT97Ua0Xo93M@x130> (raw)
In-Reply-To: <20230610000123.04c3a32f@kernel.org>

On 10 Jun 00:01, Jakub Kicinski wrote:
>On Fri,  9 Jun 2023 18:42:53 -0700 Saeed Mahameed wrote:
>> In case user wants to configure the SFs, for example: to use only vdpa
>> functionality, he needs to fully probe a SF, configure what he wants,
>> and afterward reload the SF.
>>
>> In order to save the time of the reload, local SFs will probe without
>> any auxiliary sub-device, so that the SFs can be configured prior to
>> its full probe.
>
>I feel like we talked about this at least twice already, and I keep
>saying that the features should be specified when the device is
>spawned. Am I misremembering?
>

I think we did talk about this, but after internal research we prefer to
avoid adding additional knobs, unless you insist :) .. 
I think we already did a research and we feel that all of our users are
going to re-configure the SF anyway, so why not make all SFs start with
"blank state" ?

>Will this patch not surprise existing users? You're changing the

I think we already checked, the feature is still not widely known.
Let me double check.

>defaults. Does "local" mean on the IPU? Also "lightweight" feels
>uncomfortably close to marketing language.
>

That wasn't out intention, poor choice of words, will reword to "blank SF"

>> The defaults of the enable_* devlink params of these SFs are set to
>> false.
>>
>> Usage example:
>
>Is this a real example? Because we have..
>
>> Create SF:
>> $ devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 11
>
>sfnum 11 here
>

This an arbitrary user index.

>> $ devlink port function set pci/0000:08:00.0/32768 \
>
>then port is 32768
>

This is the actual HW port index, our SFs indexing start with an offset.

>>                hw_addr 00:00:00:00:00:11 state active
>>
>> Enable ETH auxiliary device:
>> $ devlink dev param set auxiliary/mlx5_core.sf.1 \
>
>and instance is sf.1
>

This was the first SF aux dev to be created on the system. :/

It's a mess ha...
  
Maybe we need to set the SF aux device index the same as the user index.
But the HW/port index will always be different, otherwise we will need a map
inside the driver.


  reply	other threads:[~2023-06-11  4:16 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-10  1:42 [pull request][net-next 00/15] mlx5 updates 2023-06-09 Saeed Mahameed
2023-06-10  1:42 ` [net-next 01/15] net/mlx5: Simplify unload all rep code Saeed Mahameed
2023-06-12 11:00   ` patchwork-bot+netdevbpf
2023-06-10  1:42 ` [net-next 02/15] net/mlx5: mlx5_ifc updates for embedded CPU SRIOV Saeed Mahameed
2023-06-10  1:42 ` [net-next 03/15] net/mlx5: Enable devlink port for embedded cpu VF vports Saeed Mahameed
2023-06-10  1:42 ` [net-next 04/15] net/mlx5: Update vport caps query/set for EC VFs Saeed Mahameed
2023-06-10  1:42 ` [net-next 05/15] net/mlx5: Add management of EC VF vports Saeed Mahameed
2023-06-10  1:42 ` [net-next 06/15] net/mlx5: Add/remove peer miss rules for EC VFs Saeed Mahameed
2023-06-10  1:42 ` [net-next 07/15] net/mlx5: Add new page type for EC VF pages Saeed Mahameed
2023-06-10  1:42 ` [net-next 08/15] net/mlx5: Use correct vport when restoring GUIDs Saeed Mahameed
2023-06-10  1:42 ` [net-next 09/15] net/mlx5: Query correct caps for min msix vectors Saeed Mahameed
2023-06-10  1:42 ` [net-next 10/15] net/mlx5: Update SRIOV enable/disable to handle EC/VFs Saeed Mahameed
2023-06-10  1:42 ` [net-next 11/15] net/mlx5: Set max number of embedded CPU VFs Saeed Mahameed
2023-06-10  1:42 ` [net-next 12/15] net/mlx5: Split function_setup() to enable and open functions Saeed Mahameed
2023-06-10  1:42 ` [net-next 13/15] net/mlx5: Move esw multiport devlink param to eswitch code Saeed Mahameed
2023-06-10  1:42 ` [net-next 14/15] net/mlx5: Light probe local SFs Saeed Mahameed
2023-06-10  7:01   ` Jakub Kicinski
2023-06-11  4:15     ` Saeed Mahameed [this message]
2023-06-11  5:10       ` Samudrala, Sridhar
2023-06-13 23:41         ` Saeed Mahameed
2023-06-12 17:51       ` Jakub Kicinski
2023-06-13 23:32         ` Saeed Mahameed
2023-06-14  2:05           ` Jakub Kicinski
2023-06-15 10:51             ` Jiri Pirko
2023-06-15 16:37               ` Jakub Kicinski
2023-06-15 17:37                 ` Jiri Pirko
2023-06-15 19:33                   ` Jakub Kicinski
2023-06-21 13:14                     ` Jiri Pirko
2023-06-21 18:23                       ` Jakub Kicinski
2023-06-22  6:42                         ` Jiri Pirko
2023-06-22  6:38                       ` Jiri Pirko
2023-06-22 16:35                         ` Jakub Kicinski
2023-06-23  9:27                           ` Jiri Pirko
2023-06-23 15:21                             ` Jakub Kicinski
2023-06-24  9:33                               ` Jiri Pirko
2023-06-24 20:47                                 ` Jakub Kicinski
2023-06-27 10:12                                   ` Jiri Pirko
2023-06-27 15:24                                     ` Jakub Kicinski
2023-06-27 17:16                                       ` Jiri Pirko
2023-06-27 17:35                                         ` Jakub Kicinski
2023-06-10  1:42 ` [net-next 15/15] net/mlx5e: Remove a useless function call Saeed Mahameed

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=ZIVKfT97Ua0Xo93M@x130 \
    --to=saeedm@nvidia.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=moshe@nvidia.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=saeed@kernel.org \
    --cc=shayd@nvidia.com \
    --cc=tariqt@nvidia.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).