Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp619323pxu; Tue, 1 Dec 2020 21:56:46 -0800 (PST) X-Google-Smtp-Source: ABdhPJzEblRLM1CgfHTEHvGU5vYeN1EyxL84Xu/EIyly7F8FzhNXZyIoyijVS6YM/R3StRNySkwD X-Received: by 2002:a17:906:4058:: with SMTP id y24mr769139ejj.245.1606888606021; Tue, 01 Dec 2020 21:56:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606888606; cv=none; d=google.com; s=arc-20160816; b=AH/rk0BNwZZcYdqLE86zRRY4j2lphU//YcqW7R/sQjmMiviNMC/2KhWoHipmtNUJJc z5ks/2jWl81rcP+BPAnyNRXWYqkwUMH/bifNDKt7V1dK6khGf8h56Ay4eubk5Rnt87yK 5YoJ7UQygJDnW/uUBDhPodVLKmYMUZZYPkPyALMgaqMsdvTbR+aUmFhPD9uHyr3SOPrE pD4qv12xPiLcMnsPcxq9SZjyDWJjBjSy/s/ymMr5nrnRHB7gkRsvZEjxT3z9a50vMM2N Im5eg4/3DtgKQf/WdmVZGh5IiciSSz3/LHCyzPy9YuieeTHwqJokbn2C271WkaDyQcf0 tQsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version:subject :references:in-reply-to:message-id:cc:to:from:date:dkim-signature; bh=Myk/BHn+AdgLfa4SnUnxoiBLM1PbY9Aoe0sfjdufMOE=; b=iorVITZYkLJzsPoCP84lrRub2d4CaY+gHkebRj91BFdsbtfQ0f6IXfzpHamqsl+E3Z gl8diD+jkP7A/MdhL7lMMKa9Tsf+1AxbBxwsvk/oO2GS05ogU1vq//LWC54hmCcYFFck GOOr/hQNMKhsmTvOlGRwAvU177NbbLUSssoVLjRIRKV6uErlFKt2atPJYk0bGcug281z V5hW51bKjQYjVKGNnlMm+A4Z7Kmy6OAh1uwRRsbizZWjgXcNHwICkEk5YfFY2PinirIT FSUXWglE5zJdmj1sfQ5J2UNlG8NGrC3rzPvq6uMdjDTvwNAP3/AyVOk97uazsk8H6hxY Zf2Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=mRve+Hxv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id zm13si256180ejb.351.2020.12.01.21.56.22; Tue, 01 Dec 2020 21:56:46 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=mRve+Hxv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726935AbgLBFyk (ORCPT + 99 others); Wed, 2 Dec 2020 00:54:40 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47826 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725984AbgLBFyj (ORCPT ); Wed, 2 Dec 2020 00:54:39 -0500 Received: from mail-io1-xd42.google.com (mail-io1-xd42.google.com [IPv6:2607:f8b0:4864:20::d42]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 35F44C0613CF; Tue, 1 Dec 2020 21:53:59 -0800 (PST) Received: by mail-io1-xd42.google.com with SMTP id t8so707174iov.8; Tue, 01 Dec 2020 21:53:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-transfer-encoding; bh=Myk/BHn+AdgLfa4SnUnxoiBLM1PbY9Aoe0sfjdufMOE=; b=mRve+Hxvr/+mtvbF6XnweP1Rb4cOKr6QIH+KPCVK+GwC6jsZI1eYtt+IGBMDIKHsXM 8AefwSSl9BgrYBYnkxsDgdCR6vv4tegeOsLVQhjzyvVPmdlvvaQYEpXHjUwFUpltp/DA cj8n3Yjq77JsC5/RrV5kLshQsWt9V6vrj3fm/P/nrwMymUvH8cCgmhHayNRAq84MxwEC Sod7ozBuarzF3JSK1Dkb9Y2TTiuzHSgTBB3lVJ36YDW3G63t4DfCH7rXvvnf928ldRr2 OuZIqdSSHNkCP3fmRN6ci8Ur1/vzsAshoHAXt3HZv64M8r+VM3dTcx7jRs2IFu2+DMBv LRnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:content-transfer-encoding; bh=Myk/BHn+AdgLfa4SnUnxoiBLM1PbY9Aoe0sfjdufMOE=; b=AWT0YE9p1J8SS5hpDSXUGW/DOkVyCkAhPJBaIfRD6c+0t8b09nq+kOmuHbzdtKrWLb eIga9x/9KjFZvh6ZUMztGd0QhS42N6SDn6yx2vK214UpkMr8K9NLX+ly1vZ+N4eIZtbR fPXe5Z9K5Gy/sglavhm/lRX6L2sH9lWGgJVjC4KdsdWB+Et8tRD2WqxMdMs/V03SxKgG HLesVcnqFIBb0WwgmhczITLOwOwQ82Q2S7qL4GwWjOONvSHgD1z/wu9NHH5oSUw4az+a npGu79qwYQrqAO4dpRXUdGmM9iP6IiN13+JrForEOwGNCRIXfvcRQr0OSmNVGvR5Ergr v9xg== X-Gm-Message-State: AOAM5327WbtPrqodZC9pTDMx9FTsxZrpf+YHiGInWIkfPAfweWM27pVC wU4XYU3qCdZJ5qVpqCT/JaQ= X-Received: by 2002:a02:834b:: with SMTP id w11mr783851jag.5.1606888438506; Tue, 01 Dec 2020 21:53:58 -0800 (PST) Received: from localhost ([184.63.162.180]) by smtp.gmail.com with ESMTPSA id y6sm360312ilm.23.2020.12.01.21.53.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Dec 2020 21:53:57 -0800 (PST) Date: Tue, 01 Dec 2020 21:53:50 -0800 From: John Fastabend To: Yonghong Song , Andrii Nakryiko Cc: Alexei Starovoitov , Brendan Jackman , bpf , Alexei Starovoitov , Daniel Borkmann , KP Singh , Florent Revest , open list , Jann Horn Message-ID: <5fc72beede900_15eb720850@john-XPS-13-9370.notmuch> In-Reply-To: <31a67edd-4837-cfd3-c9fe-a6942ebd87bb@fb.com> References: <20201127175738.1085417-1-jackmanb@google.com> <829353e6-d90a-a91a-418b-3c2556061cda@fb.com> <20201129014000.3z6eua5pcz3jxmtk@ast-mbp> <4fa9f8cf-aaf8-a63c-e0ca-7d4c83b01578@fb.com> <31a67edd-4837-cfd3-c9fe-a6942ebd87bb@fb.com> Subject: Re: [PATCH v2 bpf-next 00/13] Atomics for eBPF Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Yonghong Song wrote: > > [...] > > Great, this means that all existing valid uses of > > __sync_fetch_and_add() will generate BPF_XADD instructions and will > > work on old kernels, right? > > That is correct. > > > > > If that's the case, do we still need cpu=v4? The new instructions are > > *only* going to be generated if the user uses previously unsupported > > __sync_fetch_xxx() intrinsics. So, in effect, the user consciously > > opts into using new BPF instructions. cpu=v4 seems like an unnecessary > > tautology then? > > This is a very good question. Essentially this boils to when users can > use the new functionality including meaningful return value of > __sync_fetch_and_add(). > (1). user can write a small bpf program to test the feature. If user > gets a failed compilation (fatal error), it won't be supported. > Otherwise, it is supported. > (2). compiler provides some way to tell user it is safe to use, e.g., > -mcpu=v4, or some clang macro suggested by Brendan earlier. > > I guess since kernel already did a lot of feature discovery. Option (1) > is probably fine. For option (2) we can use BTF with kernel version check. If kernel is greater than kernel this lands in we use the the new instructions if not we use a slower locked version. That should work for all cases unless someone backports patches into an older case. At least thats what I'll probably end up wrapping in a helper function.