All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Yan <yanaijie@huawei.com>
To: John Garry <john.garry@huawei.com>,
	martin.petersen@oracle.com, jejb@linux.vnet.ibm.com
Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
	zhaohongjiang@huawei.com, hare@suse.com,
	dan.j.williams@intel.com, jthumshirn@suse.de, hch@lst.de,
	huangdaode@hisilicon.com, chenxiang66@hisilicon.com,
	xiexiuqi@huawei.com, tj@kernel.org, miaoxie@huawei.com,
	Ewan Milne <emilne@redhat.com>, Tomas Henzl <thenzl@redhat.com>
Subject: Re: [PATCH v2 3/7] scsi: libsas: optimize the debug print of the revalidate process
Date: Thu, 31 Jan 2019 09:31:14 +0800	[thread overview]
Message-ID: <5C524FE2.9070801@huawei.com> (raw)
In-Reply-To: <2ffa6821-93d4-7925-d435-e34338f323ec@huawei.com>



On 2019/1/31 0:41, John Garry wrote:
> On 30/01/2019 08:24, Jason Yan wrote:
>> sas_rediscover() returns error code if discover failed for a expander
>> phy. And sas_ex_revalidate_domain() only returns the last phy's error
>> code. So when sas_revalidate_domain() prints the return value of the
>> discover process, we do not know if the revalidation for every phy is
>> successful or not. We just know the last bcast phy revalidation
>> succeeded or not.
>>
>> No need to return a error code for sas_ex_revalidate_domain() and
>> sas_rediscover(), and just print the debug log for each bcast phy
>> directly
>> in sas_rediscover().
>
> do we want to know about every PHY, or just the PHY where res != 0?
>

Here I mean every PHY that raises bcast.

>>
>
> I don't see any optimisation here. Maybe an improvement.
>

Thanks, I will change the wording.

>
>> Signed-off-by: Jason Yan <yanaijie@huawei.com>
>> CC: John Garry <john.garry@huawei.com>
>> CC: Johannes Thumshirn <jthumshirn@suse.de>
>> CC: Ewan Milne <emilne@redhat.com>
>> CC: Christoph Hellwig <hch@lst.de>
>> CC: Tomas Henzl <thenzl@redhat.com>
>> CC: Dan Williams <dan.j.williams@intel.com>
>> CC: Hannes Reinecke <hare@suse.com>
>> ---
>>  drivers/scsi/libsas/sas_discover.c |  7 +++----
>>  drivers/scsi/libsas/sas_expander.c | 11 ++++++-----
>>  include/scsi/libsas.h              |  2 +-
>>  3 files changed, 10 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/scsi/libsas/sas_discover.c
>> b/drivers/scsi/libsas/sas_discover.c
>> index 726ada9b8c79..ffc571a12916 100644
>> --- a/drivers/scsi/libsas/sas_discover.c
>> +++ b/drivers/scsi/libsas/sas_discover.c
>> @@ -500,7 +500,6 @@ static void sas_discover_domain(struct work_struct
>> *work)
>>
>>  static void sas_revalidate_domain(struct work_struct *work)
>>  {
>> -    int res = 0;
>>      struct sas_discovery_event *ev = to_sas_discovery_event(work);
>>      struct asd_sas_port *port = ev->port;
>>      struct sas_ha_struct *ha = port->ha;
>> @@ -521,10 +520,10 @@ static void sas_revalidate_domain(struct
>> work_struct *work)
>>
>>      if (ddev && (ddev->dev_type == SAS_FANOUT_EXPANDER_DEVICE ||
>>               ddev->dev_type == SAS_EDGE_EXPANDER_DEVICE))
>> -        res = sas_ex_revalidate_domain(ddev);
>> +        sas_ex_revalidate_domain(ddev);
>>
>> -    pr_debug("done REVALIDATING DOMAIN on port %d, pid:%d, res 0x%x\n",
>> -         port->id, task_pid_nr(current), res);
>> +    pr_debug("done REVALIDATING DOMAIN on port %d, pid:%d\n",
>> +         port->id, task_pid_nr(current));
>>   out:
>>      mutex_unlock(&ha->disco_mutex);
>>
>> diff --git a/drivers/scsi/libsas/sas_expander.c
>> b/drivers/scsi/libsas/sas_expander.c
>> index 7b0e6dcef6e6..5cd720f93f96 100644
>> --- a/drivers/scsi/libsas/sas_expander.c
>> +++ b/drivers/scsi/libsas/sas_expander.c
>> @@ -2062,7 +2062,7 @@ static int sas_rediscover_dev(struct
>> domain_device *dev, int phy_id, bool last)
>>   * first phy,for other phys in this port, we add it to the port to
>>   * forming the wide-port.
>>   */
>> -static int sas_rediscover(struct domain_device *dev, const int phy_id)
>> +static void sas_rediscover(struct domain_device *dev, const int phy_id)
>>  {
>>      struct expander_device *ex = &dev->ex_dev;
>>      struct ex_phy *changed_phy = &ex->ex_phy[phy_id];
>> @@ -2090,7 +2090,9 @@ static int sas_rediscover(struct domain_device
>> *dev, const int phy_id)
>>          res = sas_rediscover_dev(dev, phy_id, last);
>>      } else
>>          res = sas_discover_new(dev, phy_id);
>> -    return res;
>> +
>> +    pr_debug("ex %016llx phy%d discover returned 0x%x\n",
>
> Hmmm.. this is not just discover, but also rediscover
>

Yes, will fix.

>> +         SAS_ADDR(dev->sas_addr), phy_id, res);
>>  }
>>
>>  /**
>> @@ -2102,7 +2104,7 @@ static int sas_rediscover(struct domain_device
>> *dev, const int phy_id)
>>   * Discover process only interrogates devices in order to discover the
>>   * domain.
>>   */
>> -int sas_ex_revalidate_domain(struct domain_device *port_dev)
>> +void sas_ex_revalidate_domain(struct domain_device *port_dev)
>>  {
>>      int res;
>>      struct domain_device *dev = NULL;
>> @@ -2117,11 +2119,10 @@ int sas_ex_revalidate_domain(struct
>> domain_device *port_dev)
>>              res = sas_find_bcast_phy(dev, &phy_id, i, true);
>
> this was missed

Yes, the return value of sas_find_bcast_phy() is actually unused, and
inside the function debug info has been printed. So we can directly
make it a void function.

>
>>              if (phy_id == -1)
>>                  break;
>> -            res = sas_rediscover(dev, phy_id);
>> +            sas_rediscover(dev, phy_id);
>>              i = phy_id + 1;
>>          } while (i < ex->num_phys);
>>      }
>> -    return res;
>>  }
>>
>>  void sas_smp_handler(struct bsg_job *job, struct Scsi_Host *shost,
>> diff --git a/include/scsi/libsas.h b/include/scsi/libsas.h
>> index 420156cea3ee..e557bcb0c266 100644
>> --- a/include/scsi/libsas.h
>> +++ b/include/scsi/libsas.h
>> @@ -692,7 +692,7 @@ int  sas_discover_root_expander(struct
>> domain_device *);
>>
>>  void sas_init_ex_attr(void);
>>
>> -int  sas_ex_revalidate_domain(struct domain_device *);
>> +void sas_ex_revalidate_domain(struct domain_device *);
>>
>>  void sas_unregister_domain_devices(struct asd_sas_port *port, int gone);
>>  void sas_init_disc(struct sas_discovery *disc, struct asd_sas_port *);
>>
>
>
>
> .
>

WARNING: multiple messages have this Message-ID (diff)
From: Jason Yan <yanaijie@huawei.com>
To: John Garry <john.garry@huawei.com>, <martin.petersen@oracle.com>,
	<jejb@linux.vnet.ibm.com>
Cc: <linux-scsi@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<zhaohongjiang@huawei.com>, <hare@suse.com>,
	<dan.j.williams@intel.com>, <jthumshirn@suse.de>, <hch@lst.de>,
	<huangdaode@hisilicon.com>, <chenxiang66@hisilicon.com>,
	<xiexiuqi@huawei.com>, <tj@kernel.org>, <miaoxie@huawei.com>,
	Ewan Milne <emilne@redhat.com>, Tomas Henzl <thenzl@redhat.com>
Subject: Re: [PATCH v2 3/7] scsi: libsas: optimize the debug print of the revalidate process
Date: Thu, 31 Jan 2019 09:31:14 +0800	[thread overview]
Message-ID: <5C524FE2.9070801@huawei.com> (raw)
In-Reply-To: <2ffa6821-93d4-7925-d435-e34338f323ec@huawei.com>



On 2019/1/31 0:41, John Garry wrote:
> On 30/01/2019 08:24, Jason Yan wrote:
>> sas_rediscover() returns error code if discover failed for a expander
>> phy. And sas_ex_revalidate_domain() only returns the last phy's error
>> code. So when sas_revalidate_domain() prints the return value of the
>> discover process, we do not know if the revalidation for every phy is
>> successful or not. We just know the last bcast phy revalidation
>> succeeded or not.
>>
>> No need to return a error code for sas_ex_revalidate_domain() and
>> sas_rediscover(), and just print the debug log for each bcast phy
>> directly
>> in sas_rediscover().
>
> do we want to know about every PHY, or just the PHY where res != 0?
>

Here I mean every PHY that raises bcast.

>>
>
> I don't see any optimisation here. Maybe an improvement.
>

Thanks, I will change the wording.

>
>> Signed-off-by: Jason Yan <yanaijie@huawei.com>
>> CC: John Garry <john.garry@huawei.com>
>> CC: Johannes Thumshirn <jthumshirn@suse.de>
>> CC: Ewan Milne <emilne@redhat.com>
>> CC: Christoph Hellwig <hch@lst.de>
>> CC: Tomas Henzl <thenzl@redhat.com>
>> CC: Dan Williams <dan.j.williams@intel.com>
>> CC: Hannes Reinecke <hare@suse.com>
>> ---
>>  drivers/scsi/libsas/sas_discover.c |  7 +++----
>>  drivers/scsi/libsas/sas_expander.c | 11 ++++++-----
>>  include/scsi/libsas.h              |  2 +-
>>  3 files changed, 10 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/scsi/libsas/sas_discover.c
>> b/drivers/scsi/libsas/sas_discover.c
>> index 726ada9b8c79..ffc571a12916 100644
>> --- a/drivers/scsi/libsas/sas_discover.c
>> +++ b/drivers/scsi/libsas/sas_discover.c
>> @@ -500,7 +500,6 @@ static void sas_discover_domain(struct work_struct
>> *work)
>>
>>  static void sas_revalidate_domain(struct work_struct *work)
>>  {
>> -    int res = 0;
>>      struct sas_discovery_event *ev = to_sas_discovery_event(work);
>>      struct asd_sas_port *port = ev->port;
>>      struct sas_ha_struct *ha = port->ha;
>> @@ -521,10 +520,10 @@ static void sas_revalidate_domain(struct
>> work_struct *work)
>>
>>      if (ddev && (ddev->dev_type == SAS_FANOUT_EXPANDER_DEVICE ||
>>               ddev->dev_type == SAS_EDGE_EXPANDER_DEVICE))
>> -        res = sas_ex_revalidate_domain(ddev);
>> +        sas_ex_revalidate_domain(ddev);
>>
>> -    pr_debug("done REVALIDATING DOMAIN on port %d, pid:%d, res 0x%x\n",
>> -         port->id, task_pid_nr(current), res);
>> +    pr_debug("done REVALIDATING DOMAIN on port %d, pid:%d\n",
>> +         port->id, task_pid_nr(current));
>>   out:
>>      mutex_unlock(&ha->disco_mutex);
>>
>> diff --git a/drivers/scsi/libsas/sas_expander.c
>> b/drivers/scsi/libsas/sas_expander.c
>> index 7b0e6dcef6e6..5cd720f93f96 100644
>> --- a/drivers/scsi/libsas/sas_expander.c
>> +++ b/drivers/scsi/libsas/sas_expander.c
>> @@ -2062,7 +2062,7 @@ static int sas_rediscover_dev(struct
>> domain_device *dev, int phy_id, bool last)
>>   * first phy,for other phys in this port, we add it to the port to
>>   * forming the wide-port.
>>   */
>> -static int sas_rediscover(struct domain_device *dev, const int phy_id)
>> +static void sas_rediscover(struct domain_device *dev, const int phy_id)
>>  {
>>      struct expander_device *ex = &dev->ex_dev;
>>      struct ex_phy *changed_phy = &ex->ex_phy[phy_id];
>> @@ -2090,7 +2090,9 @@ static int sas_rediscover(struct domain_device
>> *dev, const int phy_id)
>>          res = sas_rediscover_dev(dev, phy_id, last);
>>      } else
>>          res = sas_discover_new(dev, phy_id);
>> -    return res;
>> +
>> +    pr_debug("ex %016llx phy%d discover returned 0x%x\n",
>
> Hmmm.. this is not just discover, but also rediscover
>

Yes, will fix.

>> +         SAS_ADDR(dev->sas_addr), phy_id, res);
>>  }
>>
>>  /**
>> @@ -2102,7 +2104,7 @@ static int sas_rediscover(struct domain_device
>> *dev, const int phy_id)
>>   * Discover process only interrogates devices in order to discover the
>>   * domain.
>>   */
>> -int sas_ex_revalidate_domain(struct domain_device *port_dev)
>> +void sas_ex_revalidate_domain(struct domain_device *port_dev)
>>  {
>>      int res;
>>      struct domain_device *dev = NULL;
>> @@ -2117,11 +2119,10 @@ int sas_ex_revalidate_domain(struct
>> domain_device *port_dev)
>>              res = sas_find_bcast_phy(dev, &phy_id, i, true);
>
> this was missed

Yes, the return value of sas_find_bcast_phy() is actually unused, and
inside the function debug info has been printed. So we can directly
make it a void function.

>
>>              if (phy_id == -1)
>>                  break;
>> -            res = sas_rediscover(dev, phy_id);
>> +            sas_rediscover(dev, phy_id);
>>              i = phy_id + 1;
>>          } while (i < ex->num_phys);
>>      }
>> -    return res;
>>  }
>>
>>  void sas_smp_handler(struct bsg_job *job, struct Scsi_Host *shost,
>> diff --git a/include/scsi/libsas.h b/include/scsi/libsas.h
>> index 420156cea3ee..e557bcb0c266 100644
>> --- a/include/scsi/libsas.h
>> +++ b/include/scsi/libsas.h
>> @@ -692,7 +692,7 @@ int  sas_discover_root_expander(struct
>> domain_device *);
>>
>>  void sas_init_ex_attr(void);
>>
>> -int  sas_ex_revalidate_domain(struct domain_device *);
>> +void sas_ex_revalidate_domain(struct domain_device *);
>>
>>  void sas_unregister_domain_devices(struct asd_sas_port *port, int gone);
>>  void sas_init_disc(struct sas_discovery *disc, struct asd_sas_port *);
>>
>
>
>
> .
>


  reply	other threads:[~2019-01-31  1:31 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-30  8:24 [PATCH v2 0/7] libsas: fix issue of swapping or replacing disks Jason Yan
2019-01-30  8:24 ` Jason Yan
2019-01-30  8:24 ` [PATCH v2 1/7] scsi: libsas: reset the negotiated_linkrate when phy is down Jason Yan
2019-01-30  8:24   ` Jason Yan
2019-01-30 13:08   ` John Garry
2019-01-30 13:08     ` John Garry
2019-01-31  1:11     ` Jason Yan
2019-01-31  1:11       ` Jason Yan
2019-01-31  9:00       ` John Garry
2019-01-31  9:00         ` John Garry
2019-01-30  8:24 ` [PATCH v2 2/7] scsi: libsas: only clear phy->in_shutdown after shutdown event done Jason Yan
2019-01-30  8:24   ` Jason Yan
2019-01-30 16:26   ` John Garry
2019-01-30 16:26     ` John Garry
2019-01-31  1:13     ` Jason Yan
2019-01-31  1:13       ` Jason Yan
2019-01-30  8:24 ` [PATCH v2 3/7] scsi: libsas: optimize the debug print of the revalidate process Jason Yan
2019-01-30  8:24   ` Jason Yan
2019-01-30 16:41   ` John Garry
2019-01-30 16:41     ` John Garry
2019-01-31  1:31     ` Jason Yan [this message]
2019-01-31  1:31       ` Jason Yan
2019-01-31 10:25       ` John Garry
2019-01-31 10:25         ` John Garry
2019-01-30  8:24 ` [PATCH v2 4/7] scsi: libsas: split the replacement of sas disks in two steps Jason Yan
2019-01-30  8:24   ` Jason Yan
2019-01-30 17:22   ` John Garry
2019-01-30 17:22     ` John Garry
2019-01-31  2:04     ` Jason Yan
2019-01-31  2:04       ` Jason Yan
2019-01-31 10:29       ` John Garry
2019-01-31 10:29         ` John Garry
2019-01-31 16:38         ` John Garry
2019-01-31 16:38           ` John Garry
2019-02-01  1:58           ` Jason Yan
2019-02-01  1:58             ` Jason Yan
2019-02-01  9:34             ` John Garry
2019-02-01  9:34               ` John Garry
2019-01-30  8:24 ` [PATCH v2 5/7] scsi: libsas: check if the same device when flutter Jason Yan
2019-01-30  8:24   ` Jason Yan
2019-01-30  8:24 ` [PATCH v2 6/7] scsi: libsas: reset the phy address if discover failed Jason Yan
2019-01-30  8:24   ` Jason Yan
2019-01-30 17:36   ` John Garry
2019-01-30 17:36     ` John Garry
2019-01-31  2:13     ` Jason Yan
2019-01-31  2:13       ` Jason Yan
2019-01-31  9:10       ` John Garry
2019-01-31  9:10         ` John Garry
2019-01-30  8:24 ` [PATCH v2 7/7] scsi: libsas: fix issue of swapping two sas disks Jason Yan
2019-01-30  8:24   ` Jason Yan
2019-01-30 17:53   ` John Garry
2019-01-30 17:53     ` John Garry
2019-01-31  2:55     ` Jason Yan
2019-01-31  2:55       ` Jason Yan
2019-01-31 16:34       ` John Garry
2019-01-31 16:34         ` John Garry
2019-02-01  2:04         ` Jason Yan
2019-02-01  2:04           ` Jason Yan
2019-02-01  9:27           ` John Garry
2019-02-01  9:27             ` John Garry

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=5C524FE2.9070801@huawei.com \
    --to=yanaijie@huawei.com \
    --cc=chenxiang66@hisilicon.com \
    --cc=dan.j.williams@intel.com \
    --cc=emilne@redhat.com \
    --cc=hare@suse.com \
    --cc=hch@lst.de \
    --cc=huangdaode@hisilicon.com \
    --cc=jejb@linux.vnet.ibm.com \
    --cc=john.garry@huawei.com \
    --cc=jthumshirn@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=miaoxie@huawei.com \
    --cc=thenzl@redhat.com \
    --cc=tj@kernel.org \
    --cc=xiexiuqi@huawei.com \
    --cc=zhaohongjiang@huawei.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.