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=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,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 146EAC282C4 for ; Sat, 9 Feb 2019 16:56:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id DBBDC218D2 for ; Sat, 9 Feb 2019 16:56:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727118AbfBIQ4N (ORCPT ); Sat, 9 Feb 2019 11:56:13 -0500 Received: from mail-ed1-f67.google.com ([209.85.208.67]:45265 "EHLO mail-ed1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726977AbfBIQ4N (ORCPT ); Sat, 9 Feb 2019 11:56:13 -0500 Received: by mail-ed1-f67.google.com with SMTP id d9so475679edh.12 for ; Sat, 09 Feb 2019 08:56:12 -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; bh=DUx9G/mwwvw4WYQjsCj+wUoSMi5+h6hXoJrjKKkJFkE=; b=P2p8OlbkCbE+cQgEafpkAewd3CAEs42gbyEZmiXbkrsdHmowv08e8436WkXCRhJCm9 2qbQk8kfInVentkJkcM7wxk4vkt46XppM7LO3pXxYpDk7OWIj1yoxdoBx6uLwBDgKYkJ DaB4yaOzqC8b/QWmfY16IFEiia01SNs3MoRfQOIJsy0Pd3tslEw2Lt2Nh8K2f+KD7VLm UAMSdmVlge7l7T7xxTv8+XKNFENKjEKujr/CY+huZV8aPsbLvPnlYUZdaLkGP3ysq1Vp LC9q89Qe7FKmcYjh+/kf2VXfWOVODqPjswsWG43RlyTKfHkmxKp0T0BKFOAxUJiEmnbM hnsA== X-Gm-Message-State: AHQUAuYw7aTX1vaQ+VGXvsMGtLv0I7q1TflqIh16syQlHAjpPpGGP84U SEyF4p5pPwwiiG/W7VXkEpVNlA== X-Google-Smtp-Source: AHgI3IZVE3IDawn7F7ryYF3wYc3OFgMxFWPmNggryD9MROSTY5WPo2E25o42/szxipKU2xRMO89BwQ== X-Received: by 2002:a17:906:b2cc:: with SMTP id cf12mr4340527ejb.36.1549731371462; Sat, 09 Feb 2019 08:56:11 -0800 (PST) Received: from alrua-x1.borgediget.toke.dk (borgediget.toke.dk. [85.204.121.218]) by smtp.gmail.com with ESMTPSA id r1sm1463182eds.1.2019.02.09.08.56.10 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 09 Feb 2019 08:56:10 -0800 (PST) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 2E3251825D3; Sat, 9 Feb 2019 17:56:10 +0100 (CET) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Saeed Mahameed , "brouer\@redhat.com" Cc: "hawk\@kernel.org" , "virtualization\@lists.linux-foundation.org" , "borkmann\@iogearbox.net" , Tariq Toukan , "john.fastabend\@gmail.com" , "mst\@redhat.com" , "jakub.kicinski\@netronome.com" , "dsahern\@gmail.com" , "netdev\@vger.kernel.org" , "jasowang\@redhat.com" , "davem\@davemloft.net" , "makita.toshiaki\@lab.ntt.co.jp" Subject: Re: Resource management for ndo_xdp_xmit (Was: [PATCH net] virtio_net: Account for tx bytes and packets on sending xdp_frames) In-Reply-To: References: <1548934830-2389-1-git-send-email-makita.toshiaki@lab.ntt.co.jp> <20190131101516-mutt-send-email-mst@kernel.org> <20190131.094523.2248120325911339180.davem@davemloft.net> <20190131211555.3b15c81f@carbon> <20190204125307.08492005@redhat.com> <140ecbe1e25f54f90d859cc696c4119aa96bc6eb.camel@mellanox.com> <20190207084815.1e8bd817@carbon> <9e5e6882566ac67276209b35ec112a824b256bff.camel@mellanox.com> <71c687209afb1268fdb5dc4aabbab9ecf6c2aa37.camel@mellanox.com> X-Clacks-Overhead: GNU Terry Pratchett Date: Sat, 09 Feb 2019 17:56:10 +0100 Message-ID: <87d0o0q4t1.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Saeed Mahameed writes: > On Fri, 2019-02-08 at 15:17 -0800, Saeed Mahameed wrote: >> On Thu, 2019-02-07 at 19:08 +0000, Saeed Mahameed wrote: >> > >> > So >> > 1) on dev_map_update_elem() we will call >> > dev->dev->ndo_bpf() to notify the device on the intention to >> > start/stop >> > redirect, and wait for it to create/destroy the HW resources >> > before/after actually updating the map >> > >> >> silly me, dev_map_update_elem must be atomic, we can't hook driver >> resource allocation to it, it must come as a separate request >> (syscall) >> from user space to request to create XDP redirect resources. >> > > Well, it is possible to render dev_map_update_elem non-atomic and fail > BPF programs who try to update it in the verifier > check_map_func_compatibility. > > if you know of any case where devmap needs to be updated from the BPF > program please let me know. Well, maybe? My plan for dealing with the non-map redirect variant is essentially to have a hidden map that does just-in-time insertion of ifindexes if they are not already there; and rework XDP_REDIRECT to use that. However, this would essentially be an insert from eBPF; but I guess maybe it could be deferred until the RX-side driver exits its NAPI loop (as we're buffering frames in the map anyway)? -Toke