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=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,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 0BA82C169C4 for ; Sat, 9 Feb 2019 02:05:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C73452177B for ; Sat, 9 Feb 2019 02:05:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=netronome-com.20150623.gappssmtp.com header.i=@netronome-com.20150623.gappssmtp.com header.b="gmnPzhEY" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726832AbfBICF0 (ORCPT ); Fri, 8 Feb 2019 21:05:26 -0500 Received: from mail-qt1-f194.google.com ([209.85.160.194]:45289 "EHLO mail-qt1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726522AbfBICF0 (ORCPT ); Fri, 8 Feb 2019 21:05:26 -0500 Received: by mail-qt1-f194.google.com with SMTP id e5so6152889qtr.12 for ; Fri, 08 Feb 2019 18:05:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netronome-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=r1coprSgjHlFzQTYPDTH+1ErzIRblL0Th6C0VxElE1g=; b=gmnPzhEYOqNQa92idetOLmVSlEo0BIVYGpuPFk3eXi+K2SBUatZVB+wUpPRB3Um3Mw 9y4N+az0azfEVwQM0yGFJpbk5D6wS9mzkVWmbM2AVy8bJuA8keJ8h3jfWibVMHTj7p9X 5uXtma3kPg1EXmSJBl6wVUjRwFDeFN17l+IM0ZQZBYfCLX5rjAahPxvY6Z1rFv+tnEkv wJXvn1d7pgq5YGmDcCt9+eTBRyCWr7BYVrpZE7cnXIXuB5WpoXrWSeyp41qjAUmZB7hO mQ5fKi0oZWR4CmQaczbPnjiOYJSEO3OS/4qvrZobL0TTP17KuHflSpwlQR6IxLA7ZXrf 9URw== 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:in-reply-to :references:organization:mime-version:content-transfer-encoding; bh=r1coprSgjHlFzQTYPDTH+1ErzIRblL0Th6C0VxElE1g=; b=ebVxKF3y7ukjo0HYnlJatWa4PRyTicH+fp8DuCOU4iUGaVs+8n8m9hxVwa8ePnDpY9 8mL9JRTBhR4vojFQKPjbcIGfcgeKKqGEVxcmdniMCmYlm8Zy39q+dMvUal97sr2wdX/+ rD/4c0M0k3v7RmJQPHip2U1Az0Y6jNL1yjliOv7n91zTIdTPxvx3hiIjd0BrLzd4FUZg jyFl1fYEprGEUExAzI5ObF7gI3qDexpW0xxwoLTZsr7bTFS3XqWW/0EG/xe+vjlHBJ5S iyF1lp2ooSzZgwZKtkOQU62/yqrTfjGr7pnCHtTWaR1dAh3b92+SiIy1XLq7OWDVeWo3 5kSw== X-Gm-Message-State: AHQUAuaEQSUMilwimMgFJzyWdvBxnlY4g0M5I4Nq9H7+zOjFFBg47b+3 uNh2mNPnp9nSvUV79Qo9ja7JNsgq0CY= X-Google-Smtp-Source: AHgI3IYnCeI4OEoJi8DtnpvBac5aF+bjCrauRwfu/tvAv+W72ptb0FDyJrs8qGOkSeCmegLwxJguIQ== X-Received: by 2002:a0c:b994:: with SMTP id v20mr17070404qvf.27.1549677924995; Fri, 08 Feb 2019 18:05:24 -0800 (PST) Received: from cakuba.netronome.com ([66.60.152.14]) by smtp.gmail.com with ESMTPSA id k6sm5833516qtk.41.2019.02.08.18.05.23 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 08 Feb 2019 18:05:24 -0800 (PST) Date: Fri, 8 Feb 2019 18:05:16 -0800 From: Jakub Kicinski To: Saeed Mahameed Cc: "brouer@redhat.com" , "thoiland@redhat.com" , "hawk@kernel.org" , "virtualization@lists.linux-foundation.org" , "borkmann@iogearbox.net" , Tariq Toukan , "toke@toke.dk" , "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) Message-ID: <20190208180516.287f6ddc@cakuba.netronome.com> 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> Organization: Netronome Systems, Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 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? Sorry if I missed the discussion, I couldn't make the iovisor call this week due to travel.