netdev - Re: [PATCH] r8169: Add values missing in @get

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150819142416.GA26271@calimero.vinschen.de>
Date:	Wed, 19 Aug 2015 16:24:16 +0200
From:	Corinna Vinschen <vinschen@...hat.com>
To:	Hayes Wang <hayeswang@...ltek.com>,
	Francois Romieu <romieu@...zoreil.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	nic_swsd <nic_swsd@...ltek.com>, Ivan Vecera <ivecera@...hat.com>
Subject: Re: [PATCH] r8169: Add values missing in @get_stats64 from HW
 counters

On Aug 19 15:07, Corinna Vinschen wrote:
> On Aug 19 09:31, Hayes Wang wrote:
> > Corinna Vinschen [mailto:vinschen@...hat.com]
> > > Sent: Wednesday, August 19, 2015 5:13 PM
> > [...]
> > > > It could be cleared by setting bit 0, such as rtl_tally_reset() of r8152.
> > > 
> > > Is it safe to assume that this is implemented in all NICs covered by r8169? 
> > 
> > It is supported from RTL8111C. That is, RTL_GIGA_MAC_VER_19 and later.
> 
> Thanks.  In that case I would prefer the same generic method for all
> chip versions, so I'd opt for storing the offset values at rtl_open
> time as my patch is doing right now.  Is that acceptable?
> 
> If so, wouldn't it make even more sense to use the hardware collected
> information in @get_stats64 throughout, except for the numbers collected
> *only* in software?  
> 
> I would be willing to propose a matching patch.

It just occured to me that the combination of resetting the counters on
post-RTL_GIGA_MAC_VER_19 chips plus offset handling would be quite
nice, because it would reset also the small 16 and 32 bit counters.

So I'd like to propose a patch which combines both techniques, if that's
an acceptable way to go forward.

Btw., does setting the reset bit in CounterAddrLow work the same way as
setting the CounterDump flag?  I.e, does the driver have to wait for the
hardware to set the bit to 0 again to be sure the reset is finished?


Thanks in advance,
Corinna

Content of type "application/pgp-signature" skipped