linux-kernel - RE: [PATCH 1/1] target:separate tx/rx cmd

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <000001d3ceed$b0d9c870$128d5950$@cmss.chinamobile.com>
Date:   Sun, 8 Apr 2018 11:57:18 +0800
From:   "Zhang Zhuoyu" <zhangzhuoyu@...s.chinamobile.com>
To:     "'David Disseldorp'" <ddiss@...e.de>
Cc:     <nab@...ux-iscsi.org>, <linux-scsi@...r.kernel.org>,
        <target-devel@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 1/1] target:separate tx/rx cmd_puds



> -----Original Message-----
> From: David Disseldorp [mailto:ddiss@...e.de]
> Sent: Friday, April 6, 2018 8:10 PM
> To: Zhang Zhuoyu <zhangzhuoyu@...s.chinamobile.com>
> Cc: nab@...ux-iscsi.org; linux-scsi@...r.kernel.org; target-
> devel@...r.kernel.org; linux-kernel@...r.kernel.org
> Subject: Re: [PATCH 1/1] target:separate tx/rx cmd_puds
> 
> On Thu, 5 Apr 2018 13:12:12 +0200, David Disseldorp wrote:
> 
> > > -CONFIGFS_ATTR_RO(target_stat_tgt_port_, in_cmds);
> > > +CONFIGFS_ATTR_RO(target_stat_tgt_port_, tx_cmds);
> > > +CONFIGFS_ATTR_RO(target_stat_tgt_port_, rx_cmds);
> >
> > I don't think the in_cmds metric should be deleted here. It could be
> > calculated on the fly via tx_cmds + rx_cmds + nodata_cmds.
> 
> @Zhang Zhuoyu: How about something like the following?
> https://git.samba.org/?p=ddiss/linux.git;a=commitdiff;h=73723ccf433424721
> 830797d70cfb88d4596e0fc
> 

Mmm... This patch is much better. 
Looks good to me.

Zhuoyu

> ...this keeps the in_cmds metric, and renames tx/rx_cmds read/write_cmds
> respectively. read/write_cmds is still a bit ambiguous, as it refers to
the
> command data direction rather than SCSI READ/WRITE CDBs, but IMO it's
> clearer, and more consistent with the read/write_mbytes metrics.
> 
> Cheers, David