All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luis Henriques <luis@igalia.com>
To: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
Cc: "409411716@gms.tku.edu.tw" <409411716@gms.tku.edu.tw>,
	"visitorckw@gmail.com" <visitorckw@gmail.com>,
	Xiubo Li <xiubli@redhat.com>,
	"idryomov@gmail.com" <idryomov@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"ceph-devel@vger.kernel.org" <ceph-devel@vger.kernel.org>
Subject: Re: [PATCH] ceph: optimize ceph_base64_encode() with block processing
Date: Wed, 3 Sep 2025 08:55:36 +0100	[thread overview]
Message-ID: <aLf0eJcvCj9zcn-g@igalia.com> (raw)
In-Reply-To: <f4f33ae461e0f1cf2f28d1c22546bd67cd9c4da3.camel@ibm.com>

On Tue, Sep 02, 2025 at 09:21:14PM +0000, Viacheslav Dubeyko wrote:
> On Wed, 2025-09-03 at 05:05 +0800, Kuan-Wei Chiu wrote:
> > On Tue, Sep 02, 2025 at 07:37:22PM +0000, Viacheslav Dubeyko wrote:
> > > On Sat, 2025-08-30 at 21:28 +0800, Guan-Chun Wu wrote:
> > > > Previously, ceph_base64_encode() used a bitstream approach, handling one
> > > > input byte at a time and performing extra bit operations. While correct,
> > > > this method was suboptimal.
> > > > 
> > > 
> > > Sounds interesting!
> > > 
> > > Is ceph_base64_decode() efficient then?
> > > Do we have something in crypto library of Linux kernel? Maybe we can use
> > > something efficient enough from there?
> > > 
> > Hi Viacheslav,
> > 
> > FYI, we already have base64 encode/decode implementations in
> > lib/base64.c. As discussed in another thread [1], I think we can put
> > the optimized version there and have users switch to call the library
> > functions.
> > 
> > [1]: https://lore.kernel.org/lkml/38753d95-8503-4b72-9590-cb129aa49a41@t-8ch.de/  
> > 
> > 
> 
> Sounds great! Generalized version of this algorithm is much better than
> supporting some implementation in Ceph code.

Please note that ceph can not use the default base64 implementation because
it uses the '_' character in the encoding, as explained in commit

  64e86f632bf1 ("ceph: add base64 endcoding routines for encrypted names")

That's why it implements it's own version according to an IMAP RFC, which
uses '+' and ',' instead of '-' and '_'.

Cheers,
--
Luis

  reply	other threads:[~2025-09-03  7:55 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-30 13:28 [PATCH] ceph: optimize ceph_base64_encode() with block processing Guan-Chun Wu
2025-09-02 19:37 ` Viacheslav Dubeyko
2025-09-02 21:05   ` Kuan-Wei Chiu
2025-09-02 21:21     ` Viacheslav Dubeyko
2025-09-03  7:55       ` Luis Henriques [this message]
2025-09-03  8:10         ` Kuan-Wei Chiu
2025-09-03  8:42           ` Luis Henriques

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=aLf0eJcvCj9zcn-g@igalia.com \
    --to=luis@igalia.com \
    --cc=409411716@gms.tku.edu.tw \
    --cc=Slava.Dubeyko@ibm.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=idryomov@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=visitorckw@gmail.com \
    --cc=xiubli@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.