netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Edward Cree <ecree.xilinx@gmail.com>
To: Przemek Kitszel <przemyslaw.kitszel@intel.com>, edward.cree@amd.com
Cc: linux-net-drivers@amd.com, netdev@vger.kernel.org,
	habetsm.xilinx@gmail.com, sudheer.mogilappagari@intel.com,
	jdamato@fastly.com, mw@semihalf.com, linux@armlinux.org.uk,
	sgoutham@marvell.com, gakula@marvell.com, sbhatta@marvell.com,
	hkelam@marvell.com, saeedm@nvidia.com, leon@kernel.org,
	jacob.e.keller@intel.com, andrew@lunn.ch, ahmed.zaki@intel.com,
	davem@davemloft.net, kuba@kernel.org, edumazet@google.com,
	pabeni@redhat.com
Subject: Re: [PATCH v6 net-next 3/9] net: ethtool: record custom RSS contexts in the XArray
Date: Thu, 27 Jun 2024 15:24:57 +0100	[thread overview]
Message-ID: <582527ed-802b-f20e-4c50-f6f2ba460c4c@gmail.com> (raw)
In-Reply-To: <b6f4adee-76c2-466d-9d0c-f681fe32baf8@intel.com>

On 26/06/2024 10:05, Przemek Kitszel wrote:
> On 6/25/24 15:39, Edward Cree wrote:
>> On 20/06/2024 07:32, Przemek Kitszel wrote:
>>> why no error code set?
>>
>> Because at this point the driver *has* created the context, it's
>>   in the hardware.  If we wanted to return failure we'd have to
>>   call the driver again to delete it, and that would still leave
>>   an ugly case where that call fails.
> 
> driver is creating both HW context and ID at the same time, after
> you call it from ethtool, eh :(
> 
> then my only concern is why do we want to keep old context instead of
> update? (my only and last concern for this series by now)
> say dumb driver always says "ctx=1" because it does not now better,
> but wants to update the context

Tbh I'm not sure there's a clear case either way, if driver is
 screwing up we don't know why or how.  The old context could
 still be present too for all we know.  So my preference is to
 say "we don't know what happened, let's just not touch the
 xarray at all".
In any case the WARN_ON should hopefully quickly catch any
 drivers that are hitting this, and going forward new drivers
 using this API shouldn't get added.

If you still feel strongly this should be changed, please
 elaborate further on the reasoning.

  reply	other threads:[~2024-06-27 14:25 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-20  5:47 [PATCH v6 net-next 0/9] ethtool: track custom RSS contexts in the core edward.cree
2024-06-20  5:47 ` [PATCH v6 net-next 1/9] net: move ethtool-related netdev state into its own struct edward.cree
2024-06-20  5:47 ` [PATCH v6 net-next 2/9] net: ethtool: attach an XArray of custom RSS contexts to a netdevice edward.cree
2024-06-20  5:47 ` [PATCH v6 net-next 3/9] net: ethtool: record custom RSS contexts in the XArray edward.cree
2024-06-20  6:32   ` Przemek Kitszel
2024-06-20  6:37     ` Edward Cree
2024-06-25  7:17       ` Przemek Kitszel
2024-06-25  9:27         ` Edward Cree
2024-06-25 13:39     ` Edward Cree
2024-06-26  9:05       ` Przemek Kitszel
2024-06-27 14:24         ` Edward Cree [this message]
2024-06-28 12:15           ` Przemek Kitszel
2024-06-20  5:47 ` [PATCH v6 net-next 4/9] net: ethtool: let the core choose RSS context IDs edward.cree
2024-06-20  5:47 ` [PATCH v6 net-next 5/9] net: ethtool: add an extack parameter to new rxfh_context APIs edward.cree
2024-06-20  5:47 ` [PATCH v6 net-next 6/9] net: ethtool: add a mutex protecting RSS contexts edward.cree
2024-06-20  5:47 ` [PATCH v6 net-next 7/9] sfc: use new rxfh_context API edward.cree
2024-06-20  5:47 ` [PATCH v6 net-next 8/9] net: ethtool: use the tracking array for get_rxfh on custom RSS contexts edward.cree
2024-06-20 19:42   ` Simon Horman
2024-06-24 13:31     ` Edward Cree
2024-06-20  5:47 ` [PATCH v6 net-next 9/9] sfc: remove get_rxfh_context dead code edward.cree

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=582527ed-802b-f20e-4c50-f6f2ba460c4c@gmail.com \
    --to=ecree.xilinx@gmail.com \
    --cc=ahmed.zaki@intel.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=edward.cree@amd.com \
    --cc=gakula@marvell.com \
    --cc=habetsm.xilinx@gmail.com \
    --cc=hkelam@marvell.com \
    --cc=jacob.e.keller@intel.com \
    --cc=jdamato@fastly.com \
    --cc=kuba@kernel.org \
    --cc=leon@kernel.org \
    --cc=linux-net-drivers@amd.com \
    --cc=linux@armlinux.org.uk \
    --cc=mw@semihalf.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=przemyslaw.kitszel@intel.com \
    --cc=saeedm@nvidia.com \
    --cc=sbhatta@marvell.com \
    --cc=sgoutham@marvell.com \
    --cc=sudheer.mogilappagari@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).