linux-kernel - Re: [PATCH v2 00/50] wilc1000: rework tx path to use sk

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: <87a6grx1ph.fsf@kernel.org>
Date:   Thu, 23 Dec 2021 08:41:30 +0200
From:   Kalle Valo <kvalo@...nel.org>
To:     <Ajay.Kathat@...rochip.com>
Cc:     <davidm@...uge.net>, <Claudiu.Beznea@...rochip.com>,
        <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

<Ajay.Kathat@...rochip.com> writes:

> 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.
>
> Now the new patches are added to the same series so it is difficult to 
> review them in one go.
>
> I have a request, incase there are new patches please include them in 
> separate series. Breaking down the patch helps to identify the non 
> related changes which can go in separate series. The patches(change) may 
> be related to TX path flow but can go in separate series.

Yeah, a thumb of rule is to have around 10-12 patches per patchset. Then
it's still pretty easy to review them and get them accepted. Of course
it's not a hard rule, for smaller patches (like here) having more than
12 is still doable. An also the opposite, with big patches even 10
patches is too much. But 50 patches is just pure pain for the reviewers :)

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches