From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id ABDC3C432BE for ; Wed, 25 Aug 2021 17:56:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 83B9F6023E for ; Wed, 25 Aug 2021 17:56:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240882AbhHYR4t (ORCPT ); Wed, 25 Aug 2021 13:56:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33622 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235032AbhHYR4r (ORCPT ); Wed, 25 Aug 2021 13:56:47 -0400 Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EDDC2C0613D9 for ; Wed, 25 Aug 2021 10:56:01 -0700 (PDT) Received: by mail-yb1-xb2e.google.com with SMTP id q70so506185ybg.11 for ; Wed, 25 Aug 2021 10:56:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Fx2qkPqDeREwxSopnWcjB1GCzK8MBh8mRC5Q/NQ22aI=; b=O/CUHdrLiJ6O7rxUOG4hBQ7TFTwBLuhTlSrZgBQd5wpnDEAl3/RRINc47fHCxofqDt Gk1K1H+WIWlFbz2x/95RZbZF6zY2T0i0K10hlYkqCy83IiYX0RlWk8FPP860yq5QK/pn AZklAgrLEmCa2VfG+KI9vqFNqhrnccHnKhyXf4jq9OayxTyK9WaPkzlVxRnzzSfoXueo k5CNeeYg3Y4+WhtMXmlXLmzjat1ycxEx2ypsjsku/k9RGzbEk/pQ37JseXFbGiT9hFQz Mx4g7c7OKIoEEzMGooqLVfc0uk/UV0Pp9GTc7fv8CwjlSV4RlZviucdinirrM/SgUwbq qMgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Fx2qkPqDeREwxSopnWcjB1GCzK8MBh8mRC5Q/NQ22aI=; b=uWBXuLijZ+6XZPpSmkF1wHTuDOXVEyQYm5sonw33VM9zbQ2TZJfVJymv95zuKtH2ej 645iNNU442XOGpCaUy+aLM0+xq1A2aPj1L7QQCV9TvmPnl7GIjwcal3B0Vb9Oq//9wH/ P2iKo/MCqCRafpKrgJK+U5FxLfxPqecHQIUSbeK7JjMmcaX1wThu9A3DT17TP6cVkVGS f1hLP3NXjgVtHU9v55Frqu0jkVuwqub9CgpEgOhhzctU3mW811W23JFxPSLc85erICOZ d0pkOok2CF0f0Y3uYpZc4hfU/D1baU2W3j6Yo6BmQMaHUOcUC0LeAPAwCXOUcQMe9I8r 8e4A== X-Gm-Message-State: AOAM532zBHjDjmQzq5lQyvKndgcCeQ2a2W3AWqDLNDbSLOkh8X/vpCLi xu702q+oUcoU9CiqwbM16vFS/Z+Ro5b2eDHRRXiE4g== X-Google-Smtp-Source: ABdhPJwKRB3q/uwwiPtTgdHTJ5OwhyTkhxDgLtYRjV02T0AARc/QuUllh7pJ+IPbZoD3iMH+oFK3DfMIjXn26rlEQ2o= X-Received: by 2002:a25:afcd:: with SMTP id d13mr57803506ybj.504.1629914160647; Wed, 25 Aug 2021 10:56:00 -0700 (PDT) MIME-Version: 1.0 References: <30f73293-ea03-d18f-d923-0cf499d4b208@gmail.com> <27e56f61-3267-de50-0d49-5fcfc59af93c@gmail.com> In-Reply-To: <27e56f61-3267-de50-0d49-5fcfc59af93c@gmail.com> From: Eric Dumazet Date: Wed, 25 Aug 2021 10:55:49 -0700 Message-ID: Subject: Re: [RFCv3 05/15] tcp: authopt: Add crypto initialization To: Leonard Crestez Cc: Eric Dumazet , Dmitry Safonov <0x7f454c46@gmail.com>, David Ahern , "David S. Miller" , Herbert Xu , Kuniyuki Iwashima , Hideaki YOSHIFUJI , Jakub Kicinski , Yuchung Cheng , Francesco Ruggeri , Mat Martineau , Christoph Paasch , Ivan Delalande , Priyaranjan Jha , Menglong Dong , netdev , "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" , "open list:KERNEL SELFTEST FRAMEWORK" , LKML , Shuah Khan Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 25, 2021 at 9:35 AM Leonard Crestez wrote: > > On 25.08.2021 02:34, Eric Dumazet wrote: > > On 8/24/21 2:34 PM, Leonard Crestez wrote: > >> The crypto_shash API is used in order to compute packet signatures. The > >> API comes with several unfortunate limitations: > >> > >> 1) Allocating a crypto_shash can sleep and must be done in user context. > >> 2) Packet signatures must be computed in softirq context > >> 3) Packet signatures use dynamic "traffic keys" which require exclusive > >> access to crypto_shash for crypto_setkey. > >> > >> The solution is to allocate one crypto_shash for each possible cpu for > >> each algorithm at setsockopt time. The per-cpu tfm is then borrowed from > >> softirq context, signatures are computed and the tfm is returned. > >> > > > > I could not see the per-cpu stuff that you mention in the changelog. > > That's a little embarrasing, I forgot to implement the actual per-cpu > stuff. tcp_authopt_alg_imp.tfm is meant to be an array up to NR_CPUS and > tcp_authopt_alg_get_tfm needs no locking other than preempt_disable > (which should already be the case). Well, do not use arrays of NR_CPUS and instead use normal per_cpu accessors (as in __tcp_alloc_md5sig_pool) > > The reference counting would still only happen from very few places: > setsockopt, close and openreq. This would only impact request/response > traffic and relatively little. What I meant is that __tcp_alloc_md5sig_pool() allocates stuff one time, we do not care about tcp_md5sig_pool_populated going back to false. Otherwise, a single user application constantly allocating a socket, enabling MD5 (or authopt), then closing the socket would incur a big cost on hosts with a lot of cpus. > > Performance was not a major focus so far. Preventing impact on non-AO > connections is important but typical AO usecases are long-lived > low-traffic connections. > > -- > Regards, > Leonard