All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Saeed Mahameed <saeed@kernel.org>
Cc: "David S. Miller" <davem@davemloft.net>,
	Paolo Abeni <pabeni@redhat.com>,
	Eric Dumazet <edumazet@google.com>,
	Saeed Mahameed <saeedm@nvidia.com>,
	netdev@vger.kernel.org, Tariq Toukan <tariqt@nvidia.com>,
	Gal Pressman <gal@nvidia.com>
Subject: Re: [net-next 08/15] net/mlx5e: Add hairpin debugfs files
Date: Wed, 11 Jan 2023 19:46:08 -0800	[thread overview]
Message-ID: <20230111194608.7f15b9a1@kernel.org> (raw)
In-Reply-To: <Y78/y0cBQ9rmk8ge@x130>

On Wed, 11 Jan 2023 15:01:31 -0800 Saeed Mahameed wrote:
> Sorry i don't have much details here, Maybe Gal can chime in.. 
> but what i am sure of is changing the hairpin RQ/SQ configs comes
> with a risk.

Would be great if someone could chime in..

> >Plus IIRC you already have the EQ configuration via params.  
> 
> EQ is considered standard parameter in devlink.
> 
> We currently have 2 vendor specific params and they are related to
> steering pipeline/engines only.
> hairpin buffer/queue sizes is only a CX limitation, and implementation
> detail.
> 
> you can clearly see a pattern here, usually the steering pipeline
> requires vendor specific knobs :/ ..
> 
> Will you be ok if we moved hairpin config to devlink driver specific param
> ? given that we will create the vendor_specific.rst for easy tracking and
> grepping.

Alright, that sounds okay. But vendor_specific.rst needs to only cover
debugfs and ethtool private flags, right? Devlink params are already
documented in per-driver devlink docs, and splitting params into two
places would be odd.

  reply	other threads:[~2023-01-12  3:46 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-11  5:30 [pull request][net-next 00/15] mlx5 updates 2023-01-10 Saeed Mahameed
2023-01-11  5:30 ` [net-next 01/15] net/mlx5: Expose shared buffer registers bits and structs Saeed Mahameed
2023-01-11  9:10   ` patchwork-bot+netdevbpf
2023-01-11  5:30 ` [net-next 02/15] net/mlx5e: Add API to query/modify SBPR and SBCM registers Saeed Mahameed
2023-01-11  5:30 ` [net-next 03/15] net/mlx5e: Update shared buffer along with device buffer changes Saeed Mahameed
2023-01-11  5:30 ` [net-next 04/15] net/mlx5e: Add Ethernet driver debugfs Saeed Mahameed
2023-01-11  5:30 ` [net-next 05/15] net/mlx5e: kTLS, Add debugfs Saeed Mahameed
2023-01-11 18:32   ` Jakub Kicinski
2023-01-11 20:20     ` Saeed Mahameed
2023-01-11 20:52       ` Jakub Kicinski
2023-01-11  5:30 ` [net-next 06/15] net/mlx5e: Add hairpin params structure Saeed Mahameed
2023-01-11  5:30 ` [net-next 07/15] net/mlx5e: Add flow steering debugfs directory Saeed Mahameed
2023-01-11  5:30 ` [net-next 08/15] net/mlx5e: Add hairpin debugfs files Saeed Mahameed
2023-01-11 18:34   ` Jakub Kicinski
2023-01-11 20:46     ` Saeed Mahameed
2023-01-11 21:03       ` Jakub Kicinski
2023-01-11 23:01         ` Saeed Mahameed
2023-01-12  3:46           ` Jakub Kicinski [this message]
2023-01-12  9:17             ` Gal Pressman
2023-01-12 22:20               ` Jakub Kicinski
2023-01-15 10:04                 ` Gal Pressman
2023-01-17 18:48                   ` Jakub Kicinski
2023-01-11  5:30 ` [net-next 09/15] net/mlx5: Enable management PF initialization Saeed Mahameed
2023-01-11  5:30 ` [net-next 10/15] net/mlx5: Introduce and use opcode getter in command interface Saeed Mahameed
2023-01-11  5:30 ` [net-next 11/15] net/mlx5: Prevent high-rate FW commands from populating all slots Saeed Mahameed
2023-01-11  5:30 ` [net-next 12/15] net/mlx5e: Replace zero-length array with flexible-array member Saeed Mahameed
2023-01-11  5:30 ` [net-next 13/15] net/mlx5e: Replace 0-length array with flexible array Saeed Mahameed
2023-01-11  5:30 ` [net-next 14/15] net/mlx5: remove redundant ret variable Saeed Mahameed
2023-01-11  5:30 ` [net-next 15/15] net/mlx5e: Use kzalloc() in mlx5e_accel_fs_tcp_create() 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=20230111194608.7f15b9a1@kernel.org \
    --to=kuba@kernel.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=gal@nvidia.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=saeed@kernel.org \
    --cc=saeedm@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 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.