Netdev List
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
	netdev@vger.kernel.org, David Howells <dhowells@redhat.com>,
	Akinobu Mita <akinobu.mita@gmail.com>,
	Tejun Heo <htejun@gmail.com>
Subject: Re: [PATCH v3 04/19] crypto: scatterwalk - add new functions for copying data
Date: Sun, 2 Mar 2025 13:37:42 -0800	[thread overview]
Message-ID: <20250302213742.GB2079@quark.localdomain> (raw)
In-Reply-To: <Z8P9eIGDlT3fs1gS@gondor.apana.org.au>

On Sun, Mar 02, 2025 at 02:40:56PM +0800, Herbert Xu wrote:
> Eric Biggers <ebiggers@kernel.org> wrote:
> >
> > +void memcpy_from_sglist(void *buf, struct scatterlist *sg,
> > +                       unsigned int start, unsigned int nbytes)
> > {
> >        struct scatter_walk walk;
> > -       struct scatterlist tmp[2];
> > 
> > -       if (!nbytes)
> > +       if (unlikely(nbytes == 0)) /* in case sg == NULL */
> >                return;
> > 
> > -       sg = scatterwalk_ffwd(tmp, sg, start);
> > +       scatterwalk_start_at_pos(&walk, sg, start);
> > +       memcpy_from_scatterwalk(buf, &walk, nbytes);
> > +}
> > +EXPORT_SYMBOL_GPL(memcpy_from_sglist);
> > +
> > +void memcpy_to_sglist(struct scatterlist *sg, unsigned int start,
> > +                     const void *buf, unsigned int nbytes)
> 
> These functions duplicate sg_copy_buffer.  Of course scatterwalk
> in general duplicates SG miter which came later IIRC.
> 
> What's your plan for eliminating this duplication?
> 
> Thanks,

The new functions are much better than the lib/scatterlist.c ones: they have a
much better implementation that is faster and doesn't use atomic kmaps, and
(like scatterwalk_map_and_copy() which they are replacing first) they don't
require the unhelpful 'nents' parameter.  My tentative plan is to move them into
lib/scatterlist.c, reimplement sg_copy_buffer() et al on top of them, then
eventually update the callers to use the new functions directly.

However, the 'nents' parameter that sg_copy_buffer() et al take will make the
unification a bit difficult.  Currently those functions copy the minimum of
'buflen' bytes and the first 'nents' scatterlist elements.  I'd like to remove
the 'nents' parameter and just have 'buflen' (or rather 'nbytes'), like the
crypto/scatterwalk.c functions.  I suspect that nearly all callers are passing
in enough 'nents' to cover their 'buflen'.  But there may be some exceptions,
which we'll need to check for.

- Eric

  reply	other threads:[~2025-03-02 21:37 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-19 18:23 [PATCH v3 00/19] crypto: scatterlist handling improvements Eric Biggers
2025-02-19 18:23 ` [PATCH v3 01/19] crypto: scatterwalk - move to next sg entry just in time Eric Biggers
2025-02-19 18:23 ` [PATCH v3 02/19] crypto: scatterwalk - add new functions for skipping data Eric Biggers
2025-02-19 18:23 ` [PATCH v3 03/19] crypto: scatterwalk - add new functions for iterating through data Eric Biggers
2025-03-02  6:28   ` Herbert Xu
2025-03-02 20:21     ` Eric Biggers
2025-03-03  2:35       ` Herbert Xu
2025-02-19 18:23 ` [PATCH v3 04/19] crypto: scatterwalk - add new functions for copying data Eric Biggers
2025-03-02  6:40   ` Herbert Xu
2025-03-02 21:37     ` Eric Biggers [this message]
2025-03-03  2:39       ` Herbert Xu
2025-02-19 18:23 ` [PATCH v3 05/19] crypto: scatterwalk - add scatterwalk_get_sglist() Eric Biggers
2025-02-19 18:23 ` [PATCH v3 06/19] crypto: skcipher - use scatterwalk_start_at_pos() Eric Biggers
2025-02-19 18:23 ` [PATCH v3 07/19] crypto: aegis - use the new scatterwalk functions Eric Biggers
2025-02-19 18:23 ` [PATCH v3 08/19] crypto: arm/ghash " Eric Biggers
2025-02-19 18:23 ` [PATCH v3 09/19] crypto: arm64 " Eric Biggers
2025-02-19 18:23 ` [PATCH v3 10/19] crypto: nx " Eric Biggers
2025-02-19 18:23 ` [PATCH v3 11/19] crypto: s390/aes-gcm " Eric Biggers
2025-02-19 18:23 ` [PATCH v3 12/19] crypto: s5p-sss " Eric Biggers
2025-02-19 18:23 ` [PATCH v3 13/19] crypto: stm32 " Eric Biggers
2025-02-19 18:23 ` [PATCH v3 14/19] crypto: x86/aes-gcm " Eric Biggers
2025-02-19 18:23 ` [PATCH v3 15/19] crypto: x86/aegis " Eric Biggers
2025-02-19 18:23 ` [PATCH v3 16/19] net/tls: " Eric Biggers
2025-02-19 18:23 ` [PATCH v3 17/19] crypto: skcipher - " Eric Biggers
2025-02-19 18:23 ` [PATCH v3 18/19] crypto: scatterwalk - remove obsolete functions Eric Biggers
2025-02-19 18:23 ` [PATCH v3 19/19] crypto: scatterwalk - don't split at page boundaries when !HIGHMEM Eric Biggers
2025-03-02  8:11 ` [PATCH v3 00/19] crypto: scatterlist handling improvements Herbert Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250302213742.GB2079@quark.localdomain \
    --to=ebiggers@kernel.org \
    --cc=akinobu.mita@gmail.com \
    --cc=dhowells@redhat.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=htejun@gmail.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox