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]
Date:   Thu, 23 Dec 2021 08:23:59 -0700
From:   David Mosberger-Tang <davidm@...uge.net>
To:     Ajay.Kathat@...rochip.com
Cc:     Claudiu.Beznea@...rochip.com, kvalo@...nel.org,
        davem@...emloft.net, kuba@...nel.org,
        linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 00/50] wilc1000: rework tx path to use sk_buffs
 throughout

On Thu, 2021-12-23 at 06:16 +0000, Ajay.Kathat@...rochip.com wrote:
> On 23/12/21 06:44, David Mosberger-Tang wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> > 
> > OK, so I'm nervous about such a large patch series, but it took a lot
> > of work to break things down into atomic changes.  This should be it
> > for the transmit path as far as I'm concerned.
> 
> Thanks David for the efforts to break down the changes. I am still 
> reviewing and testing the previous series and found some inconsistent 
> results. I am not sure about the cause of the difference. For some 
> tests, the throughput is improved(~1Mbps) but for some CI tests, the 
> throughput is less compared(~1Mbps in same range) to the previous. 
> Though not observed much difference.

There shouldn't be any significant performance regressions.  From my
observations, +/-1Mbps in throughput is quite possible due to cache-
effects.

> Now the new patches are added to the same series so it is difficult to 
> review them in one go.

Ah, OK, sorry about that.  After the automated error reports, I waited
for a day or two and after not seeing any further feedback, I figured
it'd be fine to add to the series.

I take it that as long as a patch shows up in patchworks with a
state==Action required, I should assume the patch is being worked on
(or will be worked on).

> I have a request, incase there are new patches please include them in 
> separate series.

I'm not planning on adding more patches.

  --david


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ