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 AC3A2C282C4 for ; Sat, 9 Feb 2019 16:56:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8691C218D2 for ; Sat, 9 Feb 2019 16:56:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727138AbfBIQ4z (ORCPT ); Sat, 9 Feb 2019 11:56:55 -0500 Received: from mail-ed1-f67.google.com ([209.85.208.67]:43037 "EHLO mail-ed1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726977AbfBIQ4z (ORCPT ); Sat, 9 Feb 2019 11:56:55 -0500 Received: by mail-ed1-f67.google.com with SMTP id f9so5345965eds.10 for ; Sat, 09 Feb 2019 08:56:53 -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=THcfNP92j7kEkzwuu3uAuiI68mLUamlZjlMxEPN9BcE=; b=MN/yJabKvIot0679XiaPy3YMLwEYAnH2fTpmMy/VqABZp7xVjqw3KSRluxLBhbz4oc SU0ax18quFyktqETFOyjQyL6jGpq9G77gDTanYyHzu+gt3q7csekA2kbfC0+CcSfiz/q tMYio5mQba7RM7JUn10hAIHMV6dW8EBZvWNvqAxflz4ynX/s7Ys00PFtEHrtr7wK6CNv q00uta/gXGrLQPA4OwuJpppTZZvU2WSg/1CrCgJbw8kkXDYKSpuEXYBNHDr9Kk7c0R1s 30kvZBl/2pvaOWQe6G8Y9qiil2Vkc3sW/E9OwdFZeD5IkYxYfsM/rY+uk4jL3a/sr7YQ tOiA== X-Gm-Message-State: AHQUAuZjkjbzpBq4Oi+3Mr4SAaiMDhY9q+UckFXCRN1dU3bDNXx3deH+ WnyapGrdFP3cdWJK7nyeLeVOXQ== X-Google-Smtp-Source: AHgI3IYAbNFGPrRCARPwYOy7sEVxFW26vFiGsm6gPK5Hy0MHzc5GNmTsT90Tueb74ReD/qzrqFe/BA== X-Received: by 2002:a17:906:8cf:: with SMTP id o15mr8244543eje.124.1549731413249; Sat, 09 Feb 2019 08:56:53 -0800 (PST) Received: from alrua-x1.borgediget.toke.dk (alrua-x1.vpn.toke.dk. [2a00:7660:6da:10::2]) by smtp.gmail.com with ESMTPSA id m21sm1181798ejr.0.2019.02.09.08.56.52 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 09 Feb 2019 08:56:52 -0800 (PST) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id EE2801825D3; Sat, 9 Feb 2019 17:56:51 +0100 (CET) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Jakub Kicinski , Saeed Mahameed Cc: "brouer\@redhat.com" , "hawk\@kernel.org" , "virtualization\@lists.linux-foundation.org" , "borkmann\@iogearbox.net" , Tariq Toukan , "john.fastabend\@gmail.com" , "mst\@redhat.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: <20190208180516.287f6ddc@cakuba.netronome.com> 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> <20190208180516.287f6ddc@cakuba.netronome.com> X-Clacks-Overhead: GNU Terry Pratchett Date: Sat, 09 Feb 2019 17:56:51 +0100 Message-ID: <87a7j4q4rw.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 Jakub Kicinski writes: > On Sat, 9 Feb 2019 00:18:31 +0000, Saeed Mahameed wrote: >> 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. > > Did we find a solution to non-map redirect? See my other reply to Saeed :) -Toke