[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAACQVJrY+VxAR_z-EHGjWxAGbpK2PJkWeMrsaSQGPVh4-gco9g@mail.gmail.com>
Date: Wed, 24 Jun 2020 10:14:05 +0530
From: Vasundhara Volam <vasundhara-v.volam@...adcom.com>
To: Michal Kubecek <mkubecek@...e.cz>
Cc: David Miller <davem@...emloft.net>,
Netdev <netdev@...r.kernel.org>,
Michael Chan <michael.chan@...adcom.com>,
Jakub Kicinski <kuba@...nel.org>,
Jiri Pirko <jiri@...lanox.com>,
Jiří Pírko <jiri@...nulli.us>
Subject: Re: [RFC net-next] devlink: Add reset subcommand.
On Wed, Jun 24, 2020 at 2:26 AM Michal Kubecek <mkubecek@...e.cz> wrote:
>
> On Tue, Jun 23, 2020 at 05:02:49PM +0530, Vasundhara Volam wrote:
> > Advanced NICs support live reset of some of the hardware
> > components, that resets the device immediately with all the
> > host drivers loaded.
> >
> > Add devlink reset subcommand to support live and deferred modes
> > of reset. It allows to reset the hardware components of the
> > entire device and supports the following fields:
> >
> > component:
> > ----------
> > 1. MGMT : Management processor.
> > 2. IRA : Interrupt requester.
> > 3. DMA : DMA engine.
> > 4. FILTER : Filtering/flow direction.
> > 5. OFFLOAD : Protocol offload.
> > 6. MAC : Media access controller.
> > 7. PHY : Transceiver/PHY.
> > 8. RAM : RAM shared between multiple components.
> > 9. ROCE : RoCE management processor.
> > 10. AP : Application processor.
> > 11. All : All possible components.
> >
> > Drivers are allowed to reset only a subset of requested components.
> >
> > width:
> > ------
> > 1. single - Single function.
> > 2. multi - Multiple functions.
> >
> > mode:
> > -----
> > 1. deferred - Reset will happen after unloading all the host drivers
> > on the device. This is be default reset type, if user
> > does not specify the type.
> > 2. live - Reset will happen immediately with all host drivers loaded
> > in real time. If the live reset is not supported, driver
> > will return the error.
> >
> > This patch is a proposal in continuation to discussion to the
> > following thread:
> >
> > "[PATCH v3 net-next 0/6] bnxt_en: Add 'enable_live_dev_reset' and 'allow_live_dev_reset' generic devlink params."
> >
> > and here is the URL to the patch series:
> >
> > https://patchwork.ozlabs.org/project/netdev/list/?series=180426&state=*
> >
> > If the proposal looks good, I will re-send the whole patchset
> > including devlink changes and driver usage.
> >
> > Signed-off-by: Vasundhara Volam <vasundhara-v.volam@...adcom.com>
> > Reviewed-by: Michael Chan <michael.chan@...adcom.com>
>
> IIUC this is an extension (or rather replacement) of the ETHTOOL_RESET
> ethtool subcommand. If this is the case, it would be probably better to
> implement the driver backend only once and let ethtool_reset() use the
> devlink handlers (future versions of ethtool utility could then use
> devlink interface directly).
Yes.
>
> For this purpose, I would suggest to switch the flags for AP and ROCE in
> enum devlink_reset_component:
Sure, I will do it. Thank you.
Thanks,
Vasundhara
>
> > +enum devlink_reset_component {
> > + DEVLINK_RESET_COMP_MGMT = (1 << 0),
> > + DEVLINK_RESET_COMP_IRQ = (1 << 1),
> > + DEVLINK_RESET_COMP_DMA = (1 << 2),
> > + DEVLINK_RESET_COMP_FILTER = (1 << 3),
> > + DEVLINK_RESET_COMP_OFFLOAD = (1 << 4),
> > + DEVLINK_RESET_COMP_MAC = (1 << 5),
> > + DEVLINK_RESET_COMP_PHY = (1 << 6),
> > + DEVLINK_RESET_COMP_RAM = (1 << 7),
> > + DEVLINK_RESET_COMP_ROCE = (1 << 8),
> > + DEVLINK_RESET_COMP_AP = (1 << 9),
> > + DEVLINK_RESET_COMP_ALL = 0xffffffff,
> > +};
>
> to make the flags match corresponding ETH_RESET_* flags.
>
> Michal
Powered by blists - more mailing lists