> -----Original Message-----
> From: Jakub Kicinski <k...@kernel.org>
> Sent: Friday, June 26, 2020 12:30 PM
> To: Kirsher, Jeffrey T <jeffrey.t.kirs...@intel.com>
> Cc: da...@davemloft.net; Michael, Alice <alice.mich...@intel.com>;
> netdev@vger.kernel.org; nhor...@redhat.com; sassm...@redhat.com;
> Brady, Alan <alan.br...@intel.com>; Burra, Phani R <phani.r.bu...@intel.com>;
> Hay, Joshua A <joshua.a....@intel.com>; Chittim, Madhu
> <madhu.chit...@intel.com>; Linga, Pavan Kumar
> <pavan.kumar.li...@intel.com>; Skidmore, Donald C
> <donald.c.skidm...@intel.com>; Brandeburg, Jesse
> <jesse.brandeb...@intel.com>; Samudrala, Sridhar
> <sridhar.samudr...@intel.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.
We will refactor this flow to take memory allocations into account. We're
planning to push another version next week with this fixed. Thanks.
Alan
