From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) by sourceware.org (Postfix) with ESMTPS id 33AF13883024 for ; Thu, 30 Mar 2023 18:43:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 33AF13883024 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivosinc.com Received: by mail-lf1-x12a.google.com with SMTP id bi9so25719186lfb.12 for ; Thu, 30 Mar 2023 11:43:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20210112.gappssmtp.com; s=20210112; t=1680201818; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=cqvJaOVFpYchakfr9PoQFry/sSaglvhGoN+8yS0l3Q8=; b=bqEhgW2rTaXPPygf5sqhxbBLxarWAFsnJVbCYNFkSeZDVjdEA9JexOZ8wxheZM8Hx8 ycTy8XAzB0ck8DxXlBNuM7kSWAMhAyKBJDHj7Ig8gcdVG1nOCFdmSR0n+PnlVRpZRrd2 lQtSnfJtkcc5qkUeGllBv47kUkjp6daKtMa5ljCpPwqdbtlGXLn1yp7QaCjt69qDSFJn 9yofQdCItCHdAxF3PmaCl2D9YhbIZUzvR463NFnl1GB4Lhn3nXOT5DpmpAPC2WQhy5Ob lwZ0H/YiSdP7lrVxrWUiqBzKKK+VQl8djSzjmjxfW0UJPNaWNiTA8jL3WgnaSAbhk/QN BTQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680201818; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=cqvJaOVFpYchakfr9PoQFry/sSaglvhGoN+8yS0l3Q8=; b=aZFcELVti9GAPbNa0rfyUIWPdqlZfDznmq3i7S8VUekDszk7VnWMos+HM1OJHSXHgl bIB+9+e/Ptx2FtApyieq4m35WW0prlgA528qEaC8sgWS/OuvcYEOyS6Gfsb9us7vbmFI HQGxMGuIRw9JF2zerfYLoD66JQiWn61c5g73FCx21vWE7ugdsQXxRF4AxhIdJSG1TfM/ AszNM2EwJyyA+L1yIiofOJsNskYqAjFuSZAzngwP8R8YatpxJFpjyZDKWtAsq2thKulP PlQtvuhyrgVM/4ZtC6jlSMVHPBX0jXEP1BBHbgX3pQA8iogwHG78qTpdyOoK3xFJGl28 AMHQ== X-Gm-Message-State: AAQBX9etdPXlnm9NU+F1XIeLAWTXcyjZvT+4rmclu4BWEMvjwohOmvWG xrJFXJ8wyLd2cyL6r4Z6TYgWeKXG2oBakoIZ0ZwBug== X-Google-Smtp-Source: AKy350YvapKAHbaQjS/obS094g0Hma8Mu2vwhFUk23xrEE+iSV/Bk/oiJxlii3Sb75VWfkKvBbMde0z/2SqV5Nr58nU= X-Received: by 2002:ac2:519c:0:b0:4db:f4b:a552 with SMTP id u28-20020ac2519c000000b004db0f4ba552mr7096853lfi.13.1680201817792; Thu, 30 Mar 2023 11:43:37 -0700 (PDT) MIME-Version: 1.0 References: <9290df69-8946-3b67-63ea-3d386a3c30a6@gmail.com> In-Reply-To: <9290df69-8946-3b67-63ea-3d386a3c30a6@gmail.com> From: Evan Green Date: Thu, 30 Mar 2023 11:43:02 -0700 Message-ID: Subject: Re: [PATCH v2 0/3] RISC-V: ifunced memcpy using new kernel hwprobe interface To: Jeff Law Cc: Palmer Dabbelt , adhemerval.zanella@linaro.org, libc-alpha@sourceware.org, slewis@rivosinc.com, Vineet Gupta Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Wed, Mar 29, 2023 at 11:20=E2=80=AFPM Jeff Law w= rote: > > > > On 3/29/23 13:45, Palmer Dabbelt wrote: > > > It's not in for-next yet, but various patch sets / proposals have been > > on the lists for a few months and it seems like discussion on the kerne= l > > side has pretty much died down. That's why I was pinging the glibc sid= e > > of things, if anyone here has comments on the interface then it's time > > to chime in. If there's no comments then we're likely to end up with > > this in the next release (so queue into for-next soon, Linus' master in > > a month or so). > Right. And I've suggested that we at least try to settle on the various > mem* and str* implementations independently of the kernel->glibc > interface question. This works for me. As we talked about off-list, this series cleaves pretty cleanly. One option would be to take this series now(ish, whenever the kernel series lands), then cleave off my memcpy and replace it with Vrull's when it's ready. The hope being that two incremental improvements go faster than waiting to try and land everything perfectly all at once. -Evan > > I don't much care how we break down the problem of selecting > implementations, just that we get started. That can and probably > should be happening in parallel with the kernel->glibc API work. > > I've got some performance testing to do in this space (primarily of the > VRULL implementations). It's just going to take a long time to get the > data. And that implementation probably needs some revamping after all > the work on the mem* and str* infrastructure that landed earlier this yea= r. > > jeff