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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 62E42C77B61 for ; Thu, 13 Apr 2023 22:07:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229982AbjDMWHQ (ORCPT ); Thu, 13 Apr 2023 18:07:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37538 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229493AbjDMWHN (ORCPT ); Thu, 13 Apr 2023 18:07:13 -0400 Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 78A364EFD for ; Thu, 13 Apr 2023 15:07:09 -0700 (PDT) Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-502739add9dso6921039a12.0 for ; Thu, 13 Apr 2023 15:07:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dectris.com; s=google; t=1681423628; x=1684015628; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=friaFVRW2nEkWI8GqaRgUP4OaK4hMpGVYJNwq+6sPzI=; b=DsyluJJo6Gom9PRhwdltwR+7/pQj6HC8Ru3crTjYVpnCuwwCzmB5W4uIThpX0PvJfH RQXx5BE/yFZKNZQEhsf0jjVUYf0wRWFp88Djf3hiZqURIlau4PmuAm6FjjXhc/Ylocze kDOWE27v2wmPAQ1I8Kk1AviCLLFoPzwF8JpVA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681423628; x=1684015628; h=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=friaFVRW2nEkWI8GqaRgUP4OaK4hMpGVYJNwq+6sPzI=; b=iq3LejfZmkVcC28h7RnqusAK/LkMDsvAZ78bsquHKi9ifJlwjvdUSBE+R6P3qmNgEQ C7q9mMTMsTQAfOxC99rDuU5wHevF9yTbSJUxe61zVVbURIKh1kwO5Dz3cDyPD7M6orQ4 AOzka4xMfcUANu9nU4RJ4KxNi/dyhSx3ZBkEGJ6gEBnFcf7+O9ls832raB6CI3Ywi/Ro eRy01MPu0KXgkMSdMu1nq6fznYBNxLBYw8hI3/es11vvTryg1S0b8TLjq3IkmwGtUX3F LdzQB2viLPIE9jxpzt4mFJYIbN8yailD9utmxVQruZxzGG4LmcIXnCibEqCjVvJLOibM bauw== X-Gm-Message-State: AAQBX9c3/gdKxzL6U3wedqX23HxQCzOR/pLc5kExtD3uq0qK/rDttm0t erSsPqcv8qE0umS1ghZLP2HPJnt82a80hbba5IseCA== X-Google-Smtp-Source: AKy350bJvy2LkZU3ndK85yZddnes7jQSqL1w1K7DgMkkBqnQ05cq07nfQuXtaKhm9XsnkRGGmCcytGw90/9Hwy+wtLk= X-Received: by 2002:a50:a40a:0:b0:505:4fb:4430 with SMTP id u10-20020a50a40a000000b0050504fb4430mr2047782edb.6.1681423628016; Thu, 13 Apr 2023 15:07:08 -0700 (PDT) MIME-Version: 1.0 References: <20230406130205.49996-1-kal.conley@dectris.com> <20230406130205.49996-2-kal.conley@dectris.com> <87sfdckgaa.fsf@toke.dk> <875ya12phx.fsf@toke.dk> <87ile011kz.fsf@toke.dk> <87o7nrzeww.fsf@toke.dk> In-Reply-To: <87o7nrzeww.fsf@toke.dk> From: Kal Cutter Conley Date: Fri, 14 Apr 2023 00:06:56 +0200 Message-ID: Subject: Re: [PATCH bpf-next v3 1/3] xsk: Support UMEM chunk_size > PAGE_SIZE To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: Maciej Fijalkowski , =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= , Magnus Karlsson , Jonathan Lemon , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Jonathan Corbet , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , John Fastabend , netdev@vger.kernel.org, bpf@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org > "More annoying" is not a great argument, though. You're basically saying > "please complicate your code so I don't have to complicate mine". And > since kernel API is essentially frozen forever, adding more of them > carries a pretty high cost, which is why kernel developers tend not to > be easily swayed by convenience arguments (if all you want is a more > convenient API, just build one on top of the kernel primitives and wrap > it into a library). I was trying to make a fair comparison from the user's perspective between having to allocate huge pages and deal with discontiguous buffers. That was all. I think the "your code" distinction is a bit harsh. The kernel is a community project. Why isn't it "our" code? I am trying to add a feature that I think is generally useful to people. The kernel only exists to serve its users. I believe I am doing more good than harm sending these patches.