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=-0.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 4FDE3C33CB6 for ; Fri, 17 Jan 2020 04:07:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2621420748 for ; Fri, 17 Jan 2020 04:07:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Y87rRn27" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729195AbgAQEHJ (ORCPT ); Thu, 16 Jan 2020 23:07:09 -0500 Received: from mail-lf1-f68.google.com ([209.85.167.68]:33650 "EHLO mail-lf1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727023AbgAQEHJ (ORCPT ); Thu, 16 Jan 2020 23:07:09 -0500 Received: by mail-lf1-f68.google.com with SMTP id n25so17315711lfl.0; Thu, 16 Jan 2020 20:07:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=lEBxuAjXE4mjedfwAshAydTNhTvcenIHyMzXYSF0Mak=; b=Y87rRn27Bt1zjlsWw9ToQiTj5mu05Qagc1LBhQW6jIs+1FBZPs1VzjUJtXTMDRnr0W U3WnTYFmm3ykFu8hA+COGqHZ6/CC8qL2uu0DE1qOPlycILkdiTH7e/xPzbijKgwnUPfU HuLaFdtP2XKjDfJkDx7Ws85jkl3IBGpxBCKJRE13Tm/gyi7jiB9qLWFfNgep5u0VEyRW temxCHInLHV8AYDUvJ4l1E4WjKkC7r6pEkdFwjX0cUYH8s4EA022N7GwjK8+oI0wSqLt mc7HBziSZ2NPLUdP9+F3mluLtG2ck0XLf340T7nuBek+yG6eGgoREXLBH5p/6lcGap6z 2h8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=lEBxuAjXE4mjedfwAshAydTNhTvcenIHyMzXYSF0Mak=; b=Cl1x+zr3S7btPlEPjXAYLm8ES1eL3iEuKWE7YqjpT6R1mjnq3558K474kOTw9gTcpE IBToboxnb7VqmcXpRHRcvyKyXLsdqqkWH6Uvc/Gmxx9JJZpWzgyogRt6L1n/tws1mAEe a4uLQ8X/n6gfqul8mgdqBeXnlQSe8JQL8nFeuiqmmTEUbS6eOwj95kXVV+VLWnZpW8+7 noygI1ppnGZ69rj8MJANaOolIDSlJMmbrdw2/Ef/3yw1wcaU1NBTaTbmxVfsLNyW0LjZ h7VQOKXKKn0MO1T35w1ZSs5xxXh3NStyizEArGXGDR0AoP06B8w6Y9y2vUkyloivnMVd WZBA== X-Gm-Message-State: APjAAAXCySg1BC5Ejxhe+q1m2dkGT+HxqwVfTsfFm7W1wm+vXG7AlorX 13xb/oCkEjhzaWhhKQWWUlv/IqMiFx+zZAwQ4fiUSQ== X-Google-Smtp-Source: APXvYqxwkxDFgWwaY5qXMgK1JBSs8nUHEyKiJtlx1V0L9RR19lmSzxQPDgRJuwgVeImHV9+x1p+k4+m0nNHsU9vz7GU= X-Received: by 2002:ac2:5f68:: with SMTP id c8mr4173708lfc.196.1579234026920; Thu, 16 Jan 2020 20:07:06 -0800 (PST) MIME-Version: 1.0 References: <157918768284.1458396.8128704597152008763.stgit@toke.dk> In-Reply-To: <157918768284.1458396.8128704597152008763.stgit@toke.dk> From: Alexei Starovoitov Date: Thu, 16 Jan 2020 20:06:55 -0800 Message-ID: Subject: Re: [PATCH bpf-next v3 0/3] xdp: Introduce bulking for non-map XDP_REDIRECT To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: Network Development , bpf , Daniel Borkmann , Alexei Starovoitov , David Miller , Jesper Dangaard Brouer , =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= , John Fastabend , Maciej Fijalkowski Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, Jan 16, 2020 at 7:14 AM Toke H=C3=B8iland-J=C3=B8rgensen wrote: > > Since commit 96360004b862 ("xdp: Make devmap flush_list common for all ma= p > instances"), devmap flushing is a global operation instead of tied to a > particular map. This means that with a bit of refactoring, we can finally= fix > the performance delta between the bpf_redirect_map() and bpf_redirect() h= elper > functions, by introducing bulking for the latter as well. > > This series makes this change by moving the data structure used for the b= ulking > into struct net_device itself, so we can access it even when there is not > devmap. Once this is done, moving the bpf_redirect() helper to use the bu= lking > mechanism becomes quite trivial, and brings bpf_redirect() up to the same= as > bpf_redirect_map(): > > Before: After: > 1 CPU: > bpf_redirect_map: 8.4 Mpps 8.4 Mpps (no change) > bpf_redirect: 5.0 Mpps 8.4 Mpps (+68%) > 2 CPUs: > bpf_redirect_map: 15.9 Mpps 16.1 Mpps (+1% or ~no change) > bpf_redirect: 9.5 Mpps 15.9 Mpps (+67%) > > After this patch series, the only semantics different between the two var= iants > of the bpf() helper (apart from the absence of a map argument, obviously)= is > that the _map() variant will return an error if passed an invalid map ind= ex, > whereas the bpf_redirect() helper will succeed, but drop packets on > xdp_do_redirect(). This is because the helper has no reference to the cal= ling > netdev, so unfortunately we can't do the ifindex lookup directly in the h= elper. > > Changelog: > > v3: > - Switch two more fields to avoid a list_head spanning two cache lines > - Include Jesper's tracepoint patch > - Also rename xdp_do_flush_map() > - Fix a few nits from Maciej Applied. Thanks