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=-6.0 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_PASS,URIBL_BLOCKED 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 45AB6C282DA for ; Fri, 1 Feb 2019 18:47:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 13BC4218A6 for ; Fri, 1 Feb 2019 18:47:48 +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="jpM3zRwU" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730777AbfBASrq (ORCPT ); Fri, 1 Feb 2019 13:47:46 -0500 Received: from mail-pl1-f196.google.com ([209.85.214.196]:33013 "EHLO mail-pl1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728681AbfBASrq (ORCPT ); Fri, 1 Feb 2019 13:47:46 -0500 Received: by mail-pl1-f196.google.com with SMTP id z23so3658648plo.0 for ; Fri, 01 Feb 2019 10:47:46 -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=+rjE3bCMXuS3T/n4p89kb1jipzCfnf5NeRZSMlKJPfo=; b=jpM3zRwUI420bkxOgj5J1n50fKhKhJtPFZcTaYeoxJqDrBqdBgRMr9baYb11AsJImW GsGl6jjdTzjrPvb6d9/DDKhxuH56wnqhHnKjNYMtL/t3UfkZmOjF/BTRgTJ/4C3HGTsk ShNY5nexEtElNu5VwO2WzkijGZTGbB04H/PReov0tXzJE8WEXWXEpWSJQ+kNrrcvWsNs fQpFmWK0p441J7bxjMIhsFaZ6x9Mt4ag+ccD8zy+4Sq4Tr7K41sV/apCl0Kjojvcy+8U OH3Y0XvJCRBCmJL0dEOYuKgUtTYT1kqXCON4I9V1zude97KmEzuB0Ec3+J8OXyDoRONm HM6w== 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=+rjE3bCMXuS3T/n4p89kb1jipzCfnf5NeRZSMlKJPfo=; b=WEvan1Tme/MBRv4g6sBvKEamcd+kJv65w7b/DYIWlLx6NXkJdKfZs5NeTVf3+xBSTB CYba1gs8UbkZL7Jz2R7bLHThGyRHB8m5DGkS8jaGJYJqLDI2VTg0dk3nV/vjRsY9dQ8D soF6054rGU+0MJmjjBERJIYXuV+vtK09Jz/ICbVWvHcFcJ3G0jbrqY4zbqJvpPAYqxyB WQrppu94XYdUOgNQB1Yje8wGL1FMLhCfzlxRtxX/Hk6d9XLlkF7Oo41sucea5uGKeIvG +skBTIP4yY2nRvYuU6E3+dT4aZ/M64tEaZJNycdPM4vB15tH6905T93YFVDb5TyzynSx rWFA== X-Gm-Message-State: AJcUukdua720fFgX/b9QCv5PtepgvhfxqeD++B6bBsdaYPA+HlOrGPuj Z5rH9AyXxYk9d8BIAW25P06L/g== X-Google-Smtp-Source: ALg8bN7CJl4vzWfXA95BWHASjcfkQzPkvjgHrrcGj/d7DRqI+/g4swQFKP1lcEzw3L/q1Ro7bWnPzg== X-Received: by 2002:a17:902:7588:: with SMTP id j8mr41303455pll.215.1549046865763; Fri, 01 Feb 2019 10:47:45 -0800 (PST) Received: from cakuba.hsd1.ca.comcast.net ([66.60.152.14]) by smtp.gmail.com with ESMTPSA id c13sm19932124pfe.93.2019.02.01.10.47.44 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 01 Feb 2019 10:47:45 -0800 (PST) Date: Fri, 1 Feb 2019 10:47:38 -0800 From: Jakub Kicinski To: Jesper Dangaard Brouer Cc: daniel@iogearbox.net, ast@kernel.org, David Miller , Maciej Fijalkowski , netdev@vger.kernel.org, john.fastabend@gmail.com, David Ahern , Saeed Mahameed Subject: Re: Co-existing XDP generic and native mode? (Re: [PATCH bpf-next v5 5/8] xdp: Provide extack messages when prog attachment failed) Message-ID: <20190201104738.7a3b33d6@cakuba.hsd1.ca.comcast.net> In-Reply-To: <20190201080236.446d84d4@redhat.com> References: <20190201001954.4130-1-maciej.fijalkowski@intel.com> <20190201001954.4130-6-maciej.fijalkowski@intel.com> <20190131191101.2e9dc9f6@cakuba.hsd1.ca.comcast.net> <20190201080236.446d84d4@redhat.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 Fri, 1 Feb 2019 08:02:36 +0100, Jesper Dangaard Brouer wrote: > On Thu, 31 Jan 2019 19:11:01 -0800 > Jakub Kicinski wrote: > > > On Fri, 1 Feb 2019 01:19:51 +0100, Maciej Fijalkowski wrote: > > > if (__dev_xdp_query(dev, bpf_chk, XDP_QUERY_PROG) || > > > - __dev_xdp_query(dev, bpf_chk, XDP_QUERY_PROG_HW)) > > > + __dev_xdp_query(dev, bpf_chk, XDP_QUERY_PROG_HW)) { > > > + NL_SET_ERR_MSG(extack, "native and generic XDP can't be active at the same time"); > > > return -EEXIST; > > > + } > > > > This reminds me, since we allowed native/driver and offloaded XDP > > programs to coexist in a25717d2b604 ("xdp: support simultaneous > > driver and hw XDP attachment") I got an internal feature request > > to also allow generic and native mode. Would anyone object to that? > > Well, I will object ;-) > > I have two refactor ideas [1] and [2], that depend on not allowing > XDP-native and XDP-generic to co-exist. The general idea is to let > XDP-native use the same fields in net_device->rx[] as XDP-generic given > they (currently) cannot co-exist. > The goal is (1) to move stuff out of driver code, and (2) hopefully > make it easier to implement per RXq XDP progs. You mean you'd use one pointer to keep the prog in the RXQ structure? Then some from from of an extra flag will be necessary to distinguish? I.e.: if (rxq->prog && rxq->is_native) /* got_prog */ rather than: if (rxq->native_prog) /* got_prog */ The cost of this reuse would be a read-only cache line per-q when XDP is not enabled. Right now drivers have the ability to pack the XDP prog into a structure which is in cache already, and don't need to bring the entire RXQ structure out (which is cache line aligned so driver authors can't do anything to place it cleverly). No doubt, thought, that if we allow both to be enabled we will have to bloat the data structures. > These are only refactor ideas, so if you can argue why your internal > feature request for simultaneous generic and native make more sense, > then I'm open for allowing this ? The request was actually to enable xdpoffload and xdpgeneric at the same time. I'm happy to have that as another HW offload exclusive for now :) > [1] https://github.com/xdp-project/xdp-project/blob/master/areas/core/xdp_per_rxq01.org#refactor-idea-move-xdp_rxq_info-to-net_devicenetdev_rx_queue > > [2] https://github.com/xdp-project/xdp-project/blob/master/areas/core/xdp_per_rxq01.org#refactor-idea-xdpbpf_prog-into-netdev_rx_queuenet_device > > > Apart from a touch up to test_offload.py I don't think anything > > would care. netlink can already carry multiple IDs, iproute2 > > understands it, too.. > > And we did notice you added support for HW+native: > [3] https://github.com/xdp-project/xdp-project/blob/master/areas/core/xdp_per_rxq01.org