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=-4.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS 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 4A5FCC43381 for ; Thu, 21 Feb 2019 23:02:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 109B620838 for ; Thu, 21 Feb 2019 23:02:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726220AbfBUXC0 convert rfc822-to-8bit (ORCPT ); Thu, 21 Feb 2019 18:02:26 -0500 Received: from mail-ed1-f68.google.com ([209.85.208.68]:33945 "EHLO mail-ed1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725961AbfBUXC0 (ORCPT ); Thu, 21 Feb 2019 18:02:26 -0500 Received: by mail-ed1-f68.google.com with SMTP id a16so269071edn.1 for ; Thu, 21 Feb 2019 15:02:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version:content-transfer-encoding; bh=rKsI6lQfqgFoMn887F1E9tsQVLWXPAGAxnswcsVJDpA=; b=kXr24um01eQOp9TjlJLxO4dTeg/BIkqkacpKMKZt5FqzcDAJ4CfnkWHNpIH+QQQJZC krSRON6o/ZAlrUm4bpwIknp/r95alNAKXeVPOqIYmCwx1oRYPywhdCZrg3Kg2NT5WTbF cCpty1qd4Ym+A2OMKRFvnMHhYn6ZkYL0Dx5zo6MBZ0ofKcjNZrEQ42lIuPMkCJ57wjUT jPoEeTWAyCw64vhTfO3gGuQzBnQpRDOGtFcaztRbtr8QfZJmNGQDyn2K8PFTOTw86PS2 GTcrst58dh5YlH9WVmL78bFqVXW+SBRGnt9Zy62w6WvwuGHsK2/bmhYpXC+WOeX2h2O9 E1Lw== X-Gm-Message-State: AHQUAublIFdPOEV1q9s4aJ55gEzOa7A6DLklV5Uk/GABYO2JKoQKLbqm ojdA1TSBuOYk3M8yT3VhqqX/Iw== X-Google-Smtp-Source: AHgI3IadmU+sPAkwLkp/KcUl9r1edW2CXj8RBpVISM634byH/+FtXPln7BlKd5Rpu/7MRJ2FiQ1Qpg== X-Received: by 2002:a17:906:28c4:: with SMTP id p4mr650034ejd.63.1550790144814; Thu, 21 Feb 2019 15:02:24 -0800 (PST) Received: from alrua-x1.borgediget.toke.dk (borgediget.toke.dk. [85.204.121.218]) by smtp.gmail.com with ESMTPSA id f1sm19072ejl.65.2019.02.21.15.02.24 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 21 Feb 2019 15:02:24 -0800 (PST) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id CB15C1803B8; Fri, 22 Feb 2019 00:02:23 +0100 (CET) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Jakub Kicinski Cc: David Miller , netdev@vger.kernel.org, Jesper Dangaard Brouer , Daniel Borkmann , Alexei Starovoitov Subject: Re: [PATCH net-next 2/2] xdp: Add devmap_idx map type for looking up devices by ifindex In-Reply-To: <20190221134923.53c40b11@cakuba.netronome.com> References: <155075021399.13610.12521373406832889226.stgit@alrua-x1> <155075021407.13610.6656977312753058829.stgit@alrua-x1> <20190221134923.53c40b11@cakuba.netronome.com> X-Clacks-Overhead: GNU Terry Pratchett Date: Fri, 22 Feb 2019 00:02:23 +0100 Message-ID: <874l8wiw3k.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Jakub Kicinski writes: > On Thu, 21 Feb 2019 12:56:54 +0100, Toke Høiland-Jørgensen wrote: >> A common pattern when using xdp_redirect_map() is to create a device map >> where the lookup key is simply ifindex. Because device maps are arrays, >> this leaves holes in the map, and the map has to be sized to fit the >> largest ifindex, regardless of how many devices actually are actually >> needed in the map. >> >> This patch adds a second type of device map where the key is interpreted as >> an ifindex and looked up using a hashmap, instead of being used as an array >> index. This leads to maps being densely packed, so they can be smaller. >> >> The default maps used by xdp_redirect() are changed to use the new map >> type, which means that xdp_redirect() is no longer limited to ifindex < 64, >> but instead to 64 total simultaneous interfaces per network namespace. This >> also provides an easy way to compare the performance of devmap and >> devmap_idx: >> >> xdp_redirect_map (devmap): 8394560 pkt/s >> xdp_redirect (devmap_idx): 8179480 pkt/s >> >> Difference: 215080 pkt/s or 3.1 nanoseconds per packet. > > Could you share what the ifindex mix was here, to arrive at these > numbers? How does it compare to using an array but not keying with > ifindex? Just the standard set on my test machine; ifindex 1 through 9, except 8 in this case. So certainly no more than 1 ifindex in each hash bucket for those numbers. >> Signed-off-by: Toke Høiland-Jørgensen > >> +static int dev_map_idx_update_elem(struct bpf_map *map, void *key, void *value, >> + u64 map_flags) >> +{ >> + struct bpf_dtab *dtab = container_of(map, struct bpf_dtab, map); >> + struct bpf_dtab_netdev *dev, *old_dev; >> + u32 idx = *(u32 *)key; >> + u32 val = *(u32 *)value; >> + u32 bit; >> + >> + if (unlikely(map_flags > BPF_EXIST)) >> + return -EINVAL; >> + if (unlikely(map_flags == BPF_NOEXIST)) >> + return -EEXIST; >> + >> + old_dev = __dev_map_idx_lookup_elem(map, idx); >> + if (!val) { >> + if (!old_dev) >> + return 0; > > IMHO this is a fairly strange mix of array and hashmap semantics. I > think you should stick to hashmap behaviour AFA flags and > update/delete goes. Yeah, the double book-keeping is a bit strange, but it allows the actual forwarding and flush code to be reused between both types of maps. I think this is worth the slight semantic confusion :) -Toke