[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200626122957.127d21e7@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date: Fri, 26 Jun 2020 12:29:57 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Jeff Kirsher <jeffrey.t.kirsher@...el.com>
Cc: davem@...emloft.net, Alice Michael <alice.michael@...el.com>,
netdev@...r.kernel.org, nhorman@...hat.com, sassmann@...hat.com,
Alan Brady <alan.brady@...el.com>,
Phani Burra <phani.r.burra@...el.com>,
Joshua Hay <joshua.a.hay@...el.com>,
Madhu Chittim <madhu.chittim@...el.com>,
Pavan Kumar Linga <pavan.kumar.linga@...el.com>,
Donald Skidmore <donald.c.skidmore@...el.com>,
Jesse Brandeburg <jesse.brandeburg@...el.com>,
Sridhar Samudrala <sridhar.samudrala@...el.com>
Subject: Re: [net-next v3 13/15] iecm: Add ethtool
On Thu, 25 Jun 2020 19:07:35 -0700 Jeff Kirsher wrote:
> @@ -794,7 +824,57 @@ static void iecm_vc_event_task(struct work_struct *work)
> int iecm_initiate_soft_reset(struct iecm_vport *vport,
> enum iecm_flags reset_cause)
> {
> - /* stub */
> + struct iecm_adapter *adapter = vport->adapter;
> + enum iecm_state current_state;
> + enum iecm_status status;
> + int err = 0;
> +
> + /* Make sure we do not end up in initiating multiple resets */
> + mutex_lock(&adapter->reset_lock);
> +
> + current_state = vport->adapter->state;
> + switch (reset_cause) {
> + case __IECM_SR_Q_CHANGE:
> + /* If we're changing number of queues requested, we need to
> + * send a 'delete' message before freeing the queue resources.
> + * We'll send an 'add' message in adjust_qs which doesn't
> + * require the queue resources to be reallocated yet.
> + */
> + if (current_state <= __IECM_DOWN) {
> + iecm_send_delete_queues_msg(vport);
> + } else {
> + set_bit(__IECM_DEL_QUEUES, adapter->flags);
> + iecm_vport_stop(vport);
> + }
> + iecm_deinit_rss(vport);
> + status = adapter->dev_ops.vc_ops.adjust_qs(vport);
> + if (status) {
> + err = -EFAULT;
> + goto reset_failure;
> + }
> + iecm_intr_rel(adapter);
> + iecm_vport_calc_num_q_vec(vport);
> + iecm_intr_req(adapter);
> + break;
> + case __IECM_SR_Q_DESC_CHANGE:
> + iecm_vport_stop(vport);
> + iecm_vport_calc_num_q_desc(vport);
> + break;
> + case __IECM_SR_Q_SCH_CHANGE:
> + case __IECM_SR_MTU_CHANGE:
> + iecm_vport_stop(vport);
> + break;
> + default:
> + dev_err(&adapter->pdev->dev, "Unhandled soft reset cause\n");
> + err = -EINVAL;
> + goto reset_failure;
> + }
> +
> + if (current_state == __IECM_UP)
> + err = iecm_vport_open(vport);
> +reset_failure:
> + mutex_unlock(&adapter->reset_lock);
> + return err;
> }
The close then open mode of operation will not cut it in 21st century.
You can't free all the resources and then fail to open if system is
tight on memory.
Powered by blists - more mailing lists