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 X-Spam-Level: X-Spam-Status: No, score=-3.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_NEOMUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BD898C282D7 for ; Wed, 30 Jan 2019 19:50:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8E9FE20869 for ; Wed, 30 Jan 2019 19:50:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ITQCuOyE" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732338AbfA3TuG (ORCPT ); Wed, 30 Jan 2019 14:50:06 -0500 Received: from mail-pl1-f194.google.com ([209.85.214.194]:36737 "EHLO mail-pl1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727046AbfA3TuG (ORCPT ); Wed, 30 Jan 2019 14:50:06 -0500 Received: by mail-pl1-f194.google.com with SMTP id g9so305933plo.3 for ; Wed, 30 Jan 2019 11:50:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=QzlhsiIrRR/91CkODwDBdIj74DTqtVWCJukMpW5yk1c=; b=ITQCuOyESuw9a7xci/QkfbI/gbPEL2cUktxqf1aUJY/hekqMVx/3QdgPhgSjGH1aj2 T2nhxMFvccYrjtpr1q30KBvIkK0iip2YAYeWGQoYaGDPxEEe64IFqNyl0tzlbgUL29Yn TlUhn/aCPjG+Nuys1m7c5HlLKGAyDOquocB/N3oPSD5dgI990LlEdsQrt1YxeMMaIT2v MlgdbtjARR905xxvnt5LfUKxBu55O+75bh28Rjo7FKOlOEao2M3Gr5KgXXFk2Jkn2Ok5 MvSR0sOVokvfqN42Zdguo1PiKVaLtdZam4Co6LOWEt4+8TzVmv+ho+t63TlVJinVeauT 5n+w== 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:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=QzlhsiIrRR/91CkODwDBdIj74DTqtVWCJukMpW5yk1c=; b=EGM7fFze4YC83bgE5ul7EzKjpeRFoMF6Eo5O4p7Xpi193t2WFz4Yah0FN7y4eX1Ok4 OzHsGa92qT1+/fvljfy+31xd2fnVr9GjvLdoVdW6Zv0BbRc7/+5+QIYl5G55dRhontkI 4gWxdbWED6GjYIsX5Cd2h76irpBhNtdc02oKd9JlBxhPjgTY97qj0bcXgYpjpFhoD8j4 zR47QLNqBMwXAd+c3rGReBFFEoQrtrPHY8KLg9vCcHVaJM5rPZj1eHteXARwmyo7G7LL na6y0RP6uHmasSAZd4lYIwVmZHa96UrMaDkT5xJw4gMTUjbFCpCrEkEyic3wA5z1wtvy SaZg== X-Gm-Message-State: AJcUukdBFuoSB1cWD2TfiSaBeVzD09NqktcBGpwcwnLjwNBnuLE19ik/ Qie5UYeGrJsvSESoAyMnPj4= X-Google-Smtp-Source: ALg8bN5k0w6yrtMLfllMz6Bq27RIZNFaNioVxrAKhhukTKXMRlF/JT9LgXjNs9M/xe4dbr7QWSvweg== X-Received: by 2002:a17:902:708b:: with SMTP id z11mr31739611plk.203.1548877805139; Wed, 30 Jan 2019 11:50:05 -0800 (PST) Received: from ast-mbp.dhcp.thefacebook.com ([2620:10d:c090:180::1:9e50]) by smtp.gmail.com with ESMTPSA id t185sm3100569pgd.90.2019.01.30.11.50.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Jan 2019 11:50:04 -0800 (PST) Date: Wed, 30 Jan 2019 11:50:02 -0800 From: Alexei Starovoitov To: Will Deacon Cc: Peter Zijlstra , Alexei Starovoitov , davem@davemloft.net, daniel@iogearbox.net, jakub.kicinski@netronome.com, netdev@vger.kernel.org, kernel-team@fb.com, mingo@redhat.com, Paul McKenney , jannh@google.com Subject: Re: bpf memory model. Was: [PATCH v4 bpf-next 1/9] bpf: introduce bpf_spin_lock Message-ID: <20190130195000.aswpdngpvtfyylng@ast-mbp.dhcp.thefacebook.com> References: <20190124041403.2100609-1-ast@kernel.org> <20190124041403.2100609-2-ast@kernel.org> <20190124180109.GA27771@hirez.programming.kicks-ass.net> <20190124235857.xyb5xx2ufr6x5mbt@ast-mbp.dhcp.thefacebook.com> <20190125102312.GC4500@hirez.programming.kicks-ass.net> <20190126001725.roqqfrpysyljqiqx@ast-mbp.dhcp.thefacebook.com> <20190128092408.GD28467@hirez.programming.kicks-ass.net> <20190128215623.6eqskzhklydhympa@ast-mbp> <20190130181100.GA18558@fuggles.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190130181100.GA18558@fuggles.cambridge.arm.com> User-Agent: NeoMutt/20180223 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Wed, Jan 30, 2019 at 06:11:00PM +0000, Will Deacon wrote: > Assuming that a desirable property of an eBPF program is portability between > CPU architectures, then you're effectively forcing the programmer to "assume that is fundamental misunderstanding that being thrown in this thread. bpf is not fixated on portability. All projects that tried to come up with universal byte code miserably failed. bpf program compiled for big endian won't load on little. bpf program designed to be used on x86 will work horribly slow on nfp. It will work, but will be innefficient. Hence we have alu32 mode in llvm. More so maps don't map one to one to all archs either. per-cpu map doesn't exist on nfp. we're still figuring out an equivalent for it for nfp. So, no, programs are not portable across architectures. The programmer cannot assume that. They could be portable in some cases and we're trying to keep portability as much as possible, but it's not a "desirable property" that we're going to sacrifice performance and usability for it. If it helps look at bpf as a safe kernel module. Does given kernel module work on all archs? No. Sometimes users only need to recompile it and sometimes do heavy changes. smp_mb and load acquire are the list things to worry about when folks trying to make such 'safe kernel module' work on different archs.