netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jiri Pirko <jiri@resnulli.us>
To: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
Cc: David Miller <davem@davemloft.net>, Netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH net-next 0/4] bnxt_en: Add new "enable_hot_fw_reset" generic devlink parameter
Date: Tue, 19 May 2020 07:27:45 +0200	[thread overview]
Message-ID: <20200519052745.GC4655@nanopsycho> (raw)
In-Reply-To: <CAACQVJpFB9OBLFThgjeC4L0MTiQ88FGQX0pp+33rwS9_SOiX7w@mail.gmail.com>

Tue, May 19, 2020 at 06:31:27AM CEST, vasundhara-v.volam@broadcom.com wrote:
>On Mon, May 18, 2020 at 4:31 PM Jiri Pirko <jiri@resnulli.us> wrote:
>>
>> Mon, May 18, 2020 at 10:27:15AM CEST, vasundhara-v.volam@broadcom.com wrote:
>> >This patchset adds support for a "enable_hot_fw_reset" generic devlink
>> >parameter and use it in bnxt_en driver.
>> >
>> >Also, firmware spec. is updated to 1.10.1.40.
>>
>> Hi.
>>
>> We've been discussing this internally for some time.
>> I don't like to use params for this purpose.
>> We already have "devlink dev flash" and "devlink dev reload" commands.
>> Combination of these two with appropriate attributes should provide what
>> you want. The "param" you are introducing is related to either "flash"
>> or "reload", so I don't think it is good to have separate param, when we
>> can extend the command attributes.
>>
>> How does flash&reload work for mlxsw now:
>>
>> # devlink flash
>> Now new version is pending, old FW is running
>> # devlink reload
>> Driver resets the device, new FW is loaded
>>
>> I propose to extend reload like this:
>>
>>  devlink dev reload DEV [ level { driver-default | fw-reset | driver-only | fw-live-patch } ]
>>    driver-default - means one of following to, according to what is
>>                     default for the driver
>>    fw-reset - does FW reset and driver entities re-instantiation
>>    driver-only - does driver entities re-instantiation only
>>    fw-live-patch - does only FW live patching - no effect on kernel
>>
>> Could be an enum or bitfield. Does not matter. The point is to use
>> reload with attribute to achieve what user wants. In your usecase, user
>> would do:
>>
>> # devlink flash
>> # devlink reload level fw-live-patch
>
>Jiri,
>
>I am adding this param to control the fw hot reset capability of the device.

I don't follow, sorry. Could you be more verbose about what you are
trying to achieve here?


>Permanent configuration mode will toggle the NVM config space which is
>very similar to enable_roce/enable_sriov param and runtime configuration
>mode will toggle the driver level knob to avoid/allow fw-live-reset.
>
>From above. I see that you are suggesting how to trigger the fw hot reset.
>This is good to have, but does not serve the purpose of enabling or disabling
>of the feature. Our driver is currently using "ethtool --reset" for
>triggering fw-reset
>or fw-live-patch.
>
>Thanks,
>Vasundhara

  reply	other threads:[~2020-05-19  5:27 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-18  8:27 [PATCH net-next 0/4] bnxt_en: Add new "enable_hot_fw_reset" generic devlink parameter Vasundhara Volam
2020-05-18  8:27 ` [PATCH net-next 1/4] devlink: Add new "enable_hot_fw_reset" generic device parameter Vasundhara Volam
2020-05-18  8:27 ` [PATCH net-next 2/4] bnxt_en: Update firmware spec. to 1.10.1.40 Vasundhara Volam
2020-05-18  8:27 ` [PATCH net-next 3/4] bnxt_en: Use enable_hot_fw_reset generic devlink parameter Vasundhara Volam
2020-05-18  8:27 ` [PATCH net-next 4/4] bnxt_en: Check if hot_fw_reset is allowed before doing ETHTOOL_RESET Vasundhara Volam
2020-05-18 11:01 ` [PATCH net-next 0/4] bnxt_en: Add new "enable_hot_fw_reset" generic devlink parameter Jiri Pirko
2020-05-18 23:43   ` Jakub Kicinski
2020-05-19  5:24     ` Jiri Pirko
2020-05-19 17:44       ` Jakub Kicinski
2020-05-19  4:31   ` Vasundhara Volam
2020-05-19  5:27     ` Jiri Pirko [this message]
2020-05-19  5:43       ` Vasundhara Volam
2020-05-19  7:30         ` Jiri Pirko
2020-05-19  8:41           ` Michael Chan
2020-05-19  9:41             ` Jiri Pirko
2020-05-19 10:50               ` Vasundhara Volam
2020-05-19 13:25                 ` Jiri Pirko
2020-05-19  7:13       ` Edwin Peer
2020-05-19  7:29         ` Jiri Pirko

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=20200519052745.GC4655@nanopsycho \
    --to=jiri@resnulli.us \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=vasundhara-v.volam@broadcom.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).