Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35;
Date:   Wed, 25 Oct 2023 14:07:18 -0400
From:   Daniel Jordan <daniel.m.jordan@oracle.com>
To:     Wang Jinchao <wangjinchao@xfusion.com>
Cc:     Steffen Klassert <steffen.klassert@secunet.com>,
        linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
        stone.xulei@xfusion.com
Subject: Re: [RFC/REFACT] Refactoring and significantly reducing code
 complexity
Message-ID: <pn2lkox4qj7ylx44jnqjf4kfpenaexbnw33xsebekeg4yz6yw4@y464o5qyj4f2>
References: <ZRU/EjubEH/5QLlG@fedora>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZRU/EjubEH/5QLlG@fedora>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?TehdrWMutZm1Rj0Zu+v7EvvfGh9xV4NerMVKbR55BlxRG7+xZ33DzUkpHdFA?=
 =?us-ascii?Q?DLXzZJku+TnhmVzJOIsjwfjuCvDg3rRREo4XlbjwTRibspCZg/ylX3b19rme?=
 =?us-ascii?Q?WZJ/OBe8zk0KHz7Quh/owyPN8IicmVydlR8CTWShf7QTYzidN7y2xaBm3mFa?=
 =?us-ascii?Q?lmGxqFE5AHr5kE2G+FJaecI2nxc0879CVA0pPoDSNltE1iGWevP2cia/Sdtu?=
 =?us-ascii?Q?jTDb5l25hKXdxRcKkIvoFDWaJjVbJ8kFTHIz5e2npBE8O3Ob4UQdjdK+EvXB?=
 =?us-ascii?Q?Z7xflddfxj+5lmXwdpBN9h1u5E+Iag8zTIsYVCPrtEng3z8OHguO5AQGDmqO?=
 =?us-ascii?Q?DDFx0q4OW3yANRjSR/gk1i2iTJLDTJPHUKmp9c6td2EEn7lD0W0e1NHo8Nyi?=
 =?us-ascii?Q?LTIe08FLKIkHbHAle2+zczVpg1fQz9bEGs9xG9NP1KRedix+9cu6IcKPJ06I?=
 =?us-ascii?Q?bWUHXV1AY20Bj4EXx18rEeqspGOTSg/+ON5H1I1jpmJJOpUgiVCvOViqX9/P?=
 =?us-ascii?Q?tGYfhlrRlAxBWVAid1kV58Q052jIRKfmOCb9UtNdQhjwtog46fqh86V/JSY1?=
 =?us-ascii?Q?gQksoIuUBhbhiL2yg6ryCvSZJcV0on7CEJHA/MCCOYOZ/ZFJ15IK7MX7t05k?=
 =?us-ascii?Q?x9zv/dJvQN8T9Cm6PhLXMlDx0phCSYL1fkav1rrQzvf4pGj4k9R1TPNzBPJL?=
 =?us-ascii?Q?Oui4usRm592ugllSn58oerNlQ391hEkIGbSuHmkwt27WTapU4Z8rOqIeUU95?=
 =?us-ascii?Q?PEtJAX6Z4GSCxgmr+sRSI7BkMiPpyEJG1NjEcRiVd0zPfELS93m7hCzFTY4P?=
 =?us-ascii?Q?iM5HBENH+nvlcrmVu1M/IFqjvrRGUu7EKSWgg5eW4VHrTwNbL2FHrTTfws88?=
 =?us-ascii?Q?LnZW7kMAoKTg3T0Rg+T8fwNjX75ABtjkrXOapSN4ycpYT7IHjibi0G6yun51?=
 =?us-ascii?Q?dU1zM6rwhfwy26wDbIV8gkooSj9xHJDhCJF8xYwHSIgk/pfQ2CkB1EBbpt+b?=
 =?us-ascii?Q?4U5vv9xj2Fxf7QTwkYBo+J4+SzrPBPxQcIfnmcYSQUmkodf77VNQwQbTox7r?=
 =?us-ascii?Q?liYlr9+/gpK9+DwGrhMWvOWc2ph/xHaCD5gAfBQ7yfpnhCxnAX+sX8ni0oTy?=
 =?us-ascii?Q?/4sFINaf8rFeaMUJY9xGqT1mXEMDWgB6I5oZDE3BzD6xPUUc+EpFMLkXFe5b?=
 =?us-ascii?Q?vzoCpl3eEk2o6RZUrgs265bR3xS48KNSUKqbbgelPvCOTl/FQqWfM/55Blft?=
 =?us-ascii?Q?nnPNXikZemQQR/KCbEo+JbOp0fa/VotLjX+bPu2p1+m6ke+NqQ4Hcw5jS7C6?=
 =?us-ascii?Q?39CulAUy2rka2J/Kncp9KHWW73TuYc500DARX5HYzs5iKNSEnEd4J2n2RRi/?=
 =?us-ascii?Q?HF2EKnVH7JgOP0LAnSwgVAK4hDG6rqa7PwyVP2mRVaDFozbCqOiszk5AbOg0?=
 =?us-ascii?Q?F3SL4sB2M/E83d6Oy/wuWz8MnXPz4uPWihltzbX4T+5okr/uNxmdcLN8dafG?=
 =?us-ascii?Q?Zrc+TsFPhcNjQjUwX8pWhguQKvNul2mhQb3qNfL/8cWy4OQaWhEPzmsoH++9?=
 =?us-ascii?Q?tU9ckmovjw34roJZ6RiHVEhRtaGZKBUafZXz7KKbgoTbQwTFlvHkTy/3k0ZO?=
 =?us-ascii?Q?9A=3D=3D?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: kyIKZbEabjy2ukT10LP6dNL2F9ckMN0jqPEXGdqoBMmaE8wEqASRva5+rqFMFGbrj578Ty7Mh2WzNm0PXqQHpn8zXPvF7raZ7Ytb2hrHOmXMEl3aLeovyiOnQWz2Yu0LZ7dahB2koTnJNmePC+SbCLZD72jI9NC/UPrVZH+5BK9NChuDD5SOd2D1uICN5nTWYMWP9zWGSQsrwS4BbWLkXuFAcYiMRH+AArARVBlpVlDP7DvgMvHZH7cP8RpDYs2GIlHPzImMitVG2hS5z7zPjIQp7DG9HZ/L2Ht98y/tGCwx53YYLMR3zgQTHlOt0ttcabHTHwFzfiPFKYzC0lWIBLylMztXScuiM2dhT8oerJTBZgwPi/Z5XwCH6JzIcB88vhk+hGk98jNRQJ2tTtH/PP4SkAGH8plD9GQJmO2sygHWmaYGT/LZVnMnrBdVNh1eWrQKl2BfFQE4w5Ve4ktW1m+5v8rh4RYK3JuFznOVBuX23vWJ3WQaixqnNw2DCOu/ytQkJEuWAq5Af1e7qIqv+aZFKFYYfDoTZ+DAMWdhx8OPEUWx3t+ScxP7LivsAW9oVN1LYHWRSZ+ciVD7aa89WdQaFu70c01MICMoUg+5SD/zOu/ZaSvHZgZOoLiugM8W67O7oM+j2nqeLaoXbU9+8/onQpRdL2xsxq1gCYS58aQF3dWdhoIgL0Mda3V5uTE8HXX7sWrxR/bT5hIlzGCmkxiK6m+JT/wOMe/zmhUU3F62bVERfWW9rNRU9JKAK3PHrmO9kthWQCuQqH8jcGOA68F0T+r2vL4y55dN3OHeoPCEHu4wc4415KU9tHJ1UD+tEmTNmQ/ORY3DD93hHFHkog==
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d5fa1129-74b3-4b59-1505-08dbd5853b5e
X-MS-Exchange-CrossTenant-AuthSource: SA1PR10MB5711.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Oct 2023 18:07:20.9666
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 96vIwcLlBw26DL53YP8uc9a8iKnVcPp9n7MBezebI13P2FhDucIBdpENstkInV58Hn92sPhkamnboz97GH2XtKGwqT4oo464rZedh1juFfA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR10MB5086
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.272,Aquarius:18.0.980,Hydra:6.0.619,FMLib:17.11.176.26
 definitions=2023-10-25_07,2023-10-25_01,2023-05-22_02
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 mlxlogscore=999
 bulkscore=0 mlxscore=0 spamscore=0 malwarescore=0 suspectscore=0
 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2310170001 definitions=main-2310250157
X-Proofpoint-GUID: Pw9MjCEE6PqEW-VcEwWYzSq5TJYtwSXz
X-Proofpoint-ORIG-GUID: Pw9MjCEE6PqEW-VcEwWYzSq5TJYtwSXz
X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
	SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no
	version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email
Precedence: bulk
List-ID: <linux-crypto.vger.kernel.org>
X-Mailing-List: linux-crypto@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Wed, 25 Oct 2023 11:08:49 -0700 (PDT)

Hello,

On Thu, Sep 28, 2023 at 04:53:38PM +0800, Wang Jinchao wrote:
> This is a refactored version with the following main changes:

The RFC overall is a nice simplification, and the basic approach of using an
ordered workqueue seems to work.

> - The parallel workqueue no longer uses the WQ_UNBOUND attribute

What's the justification here?  If it improves performance, please show
numbers.  Earlier tests[0] showed a large improvement when adding this
flag.

[0] https://lore.kernel.org/linux-crypto/20190906014029.3345-1-daniel.m.jordan@oracle.com/

> - Removal of CPU-related logic, sysfs-related interfaces

I agree with Steffen that we should continue to honor the cpumasks that the
user sets.

The simplest way I see to make the parallel mask work with your refactor is to
just make the parallel workqueue unbound again, since setting workqueue
attributes is only allowed for unbound, and bring back some of the plumbing
that leads to the apply_workqueue_attrs call.

The serial mask is trickier.  Changing attributes of an ordered workqueue (the
cpumask in this case) makes the kernel throw a warning...

static int apply_workqueue_attrs_locked
        ...
        /* creating multiple pwqs breaks ordering guarantee */                   
        if (!list_empty(&wq->pwqs)) {                                            
                if (WARN_ON(wq->flags & __WQ_ORDERED_EXPLICIT))                  
                        return -EINVAL;                                          
                                                                                 
                wq->flags &= ~__WQ_ORDERED;                                      
        }

...but I'm not sure this is a fundamental limitation.  The changelog of
0a94efb5acbb ("workqueue: implicit ordered attribute should be overridable")
says changes to "max_active and some attribute changes" are rejected, but it
might be possible to relax the warning to allow setting a cpumask while still
rejecting other changes.

> Testing was conducted using ltp's pcrypt_aead01, and the execution time
> comparison between the old and new versions is as follows:
> 
> Old Version:
> real 0m27.451s
> user 0m0.031s
> sys 0m0.260s
> 
> New Version:
> real 0m21.351s
> user 0m0.023s
> sys 0m0.260s

Great speedup.  A test that runs many requests for a long time in parallel is
also good to run, such as [0].

> @@ -986,57 +281,27 @@ struct padata_instance *padata_alloc(const char *name)
...
> +	pinst->serial_wq = alloc_ordered_workqueue ("%s_serial",
> +									WQ_MEM_RECLAIM | WQ_FREEZABLE,
> +									name);

Why add these two WQ_ flags?  Also, whitespace is kinda funky.