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=-7.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 3C927C43603 for ; Wed, 18 Dec 2019 16:33:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 01B81218AC for ; Wed, 18 Dec 2019 16:33:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="qk9DQjSN" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727330AbfLRQdk (ORCPT ); Wed, 18 Dec 2019 11:33:40 -0500 Received: from mail-qt1-f195.google.com ([209.85.160.195]:44834 "EHLO mail-qt1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726980AbfLRQdj (ORCPT ); Wed, 18 Dec 2019 11:33:39 -0500 Received: by mail-qt1-f195.google.com with SMTP id t3so2396710qtr.11 for ; Wed, 18 Dec 2019 08:33:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=UF3uOrepvg1COtnDxzVbIHDn0DLmcQtda4/tKhDJ/JQ=; b=qk9DQjSN2DYI8cbPdZrSD8bBJ9g39BXhsRzjKR3TwQcff1terCO31xJfkoSwI4uHG9 kv5/OERhcWfqCWEiEIRoY8t1MijWlDs95/NA6cwDgqaPzVaMR0zuCfznJwc+rgJ3h2wY d9LP0c0w4/M86wiALQZAOP057SbJyly/gVa6wJL88LV0I/GMSJM7iEOn4wfGW0sUwenr bwIO9N4qxmGqIA38dVJuQgZFYc9nj1B/oy1ddpkWTuqicaInqESFnD9xyl0yjQd8SAIT 6Vlb94vt4Tq8xaLJ65XqthO8x9FXdZjkGzhCF2l9xJj/iwrvpo7uVW6NkZD39ahsjwnO PimQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=UF3uOrepvg1COtnDxzVbIHDn0DLmcQtda4/tKhDJ/JQ=; b=jEPp4B8o0t7sgtyMoYODIdVa+fAEN/I8ve0RwKxmA07kYwMZwUcLc8jPTNOQhf7Pzh rJkJ0VMydwAwlpU/KAzo3KBIjSnVmjpbDsbo/5ghRg/irq2G/nBLJrtbif6mo4YdkaqH GcNIutWG2kZOaBKW+xNrBRc8eJERmEDAmo5AuaimJpUooVpSsMaDD14olkiEvOAezxa3 vUQ/jDGUnx6CRfWH0SkoVzLF1EJm+KWU1of5BMQEWosMW6CgHnrcE9Z+hIQkRcQruptt DZvy8/M4KW+cKfN36nS4MwMu/RUEcrLCzqcYOT08a456zFv7ET8YjaoihkV6dA27IHlk Gf8Q== X-Gm-Message-State: APjAAAXJ79125qrciOd3MtZ3pXKnAJaTVd3oKtQugTjYCVSGOyLYRmXB Xh3R62+XtRb5CWJUvRxO9uk= X-Google-Smtp-Source: APXvYqwYGGUBA83FyO67DWuIiASPVF6+dDRMScsXS32vuX3l+2RrVxnWs2oAIXUm4v4Lb9pfMnh5Lg== X-Received: by 2002:aed:24c7:: with SMTP id u7mr2902368qtc.335.1576686818452; Wed, 18 Dec 2019 08:33:38 -0800 (PST) Received: from ?IPv6:2601:282:800:fd80:500:94:a756:23cc? ([2601:282:800:fd80:500:94:a756:23cc]) by smtp.googlemail.com with ESMTPSA id b35sm915405qtc.9.2019.12.18.08.33.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 18 Dec 2019 08:33:37 -0800 (PST) Subject: Re: [RFC net-next 11/14] tun: run XDP program in tx path To: =?UTF-8?Q?Toke_H=c3=b8iland-J=c3=b8rgensen?= , Jesper Dangaard Brouer , Prashant Bhole Cc: "David S . Miller" , "Michael S . Tsirkin" , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , Jason Wang , Jakub Kicinski , John Fastabend , Toshiaki Makita , Martin KaFai Lau , Song Liu , Yonghong Song , Andrii Nakryiko , netdev@vger.kernel.org, Ilias Apalodimas References: <20191218081050.10170-1-prashantbhole.linux@gmail.com> <20191218081050.10170-12-prashantbhole.linux@gmail.com> <20191218110732.33494957@carbon> <87fthh6ehg.fsf@toke.dk> From: David Ahern Message-ID: <65eb61c0-61a6-02d1-6c7c-f950d1d037be@gmail.com> Date: Wed, 18 Dec 2019 09:33:35 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 MIME-Version: 1.0 In-Reply-To: <87fthh6ehg.fsf@toke.dk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 12/18/19 4:48 AM, Toke Høiland-Jørgensen wrote: > Jesper Dangaard Brouer writes: > >> On Wed, 18 Dec 2019 17:10:47 +0900 >> Prashant Bhole wrote: >> >>> +static u32 tun_do_xdp_tx(struct tun_struct *tun, struct tun_file *tfile, >>> + struct xdp_frame *frame) >>> +{ >>> + struct bpf_prog *xdp_prog; >>> + struct tun_page tpage; >>> + struct xdp_buff xdp; >>> + u32 act = XDP_PASS; >>> + int flush = 0; >>> + >>> + xdp_prog = rcu_dereference(tun->xdp_tx_prog); >>> + if (xdp_prog) { >>> + xdp.data_hard_start = frame->data - frame->headroom; >>> + xdp.data = frame->data; >>> + xdp.data_end = xdp.data + frame->len; >>> + xdp.data_meta = xdp.data - frame->metasize; >> >> You have not configured xdp.rxq, thus a BPF-prog accessing this will crash. >> >> For an XDP TX hook, I want us to provide/give BPF-prog access to some >> more information about e.g. the current tx-queue length, or TC-q number. >> >> Question to Daniel or Alexei, can we do this and still keep BPF_PROG_TYPE_XDP? >> Or is it better to introduce a new BPF prog type (enum bpf_prog_type) >> for XDP TX-hook ? > > I think a new program type would make the most sense. If/when we > introduce an XDP TX hook[0], it should have different semantics than the > regular XDP hook. I view the XDP TX hook as a hook that executes as the > very last thing before packets leave the interface. It should have > access to different context data as you say, but also I don't think it > makes sense to have XDP_TX and XDP_REDIRECT in an XDP_TX hook. And we > may also want to have a "throttle" return code; or maybe that could be > done via a helper? XDP_TX does not make sense in the Tx path. Jason questioned whether XDP_RX makes sense. There is not a clear use case just yet. REDIRECT is another one that would be useful as you point out below. A new program type would allow support for these to be added over time and not hold up the ability to do XDP_DROP in the Tx path. > > In any case, I don't think this "emulated RX hook on the other end of a > virtual device" model that this series introduces is the right semantics > for an XDP TX hook. I can see what you're trying to do, and for virtual > point-to-point links I think it may make sense to emulate the RX hook of > the "other end" on TX. However, form a UAPI perspective, I don't think > we should be calling this a TX hook; logically, it's still an RX hook > on the receive end. > > If you guys are up for evolving this design into a "proper" TX hook (as > outlined above an in [0]), that would be awesome, of course. But not > sure what constraints you have on your original problem? Do you > specifically need the "emulated RX hook for unmodified XDP programs" > semantics, or could your problem be solved with a TX hook with different > semantics? > > -Toke > > > [0] We've suggested this in the past, see > https://github.com/xdp-project/xdp-project/blob/master/xdp-project.org#xdp-hook-at-tx >