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=-5.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,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 DE44CC48BD3 for ; Wed, 26 Jun 2019 11:52:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id AEFA820663 for ; Wed, 26 Jun 2019 11:52:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727318AbfFZLwU convert rfc822-to-8bit (ORCPT ); Wed, 26 Jun 2019 07:52:20 -0400 Received: from mail-ed1-f68.google.com ([209.85.208.68]:35341 "EHLO mail-ed1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726157AbfFZLwU (ORCPT ); Wed, 26 Jun 2019 07:52:20 -0400 Received: by mail-ed1-f68.google.com with SMTP id w20so2963816edd.2 for ; Wed, 26 Jun 2019 04:52:19 -0700 (PDT) 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:content-transfer-encoding; bh=8G561BLNQLGaDTYbHCNH2H2OpaNjhGWxCsDpZi5dL3U=; b=XmSYyv8K4NgiZocU+kDktCu8Zew6NGnhpfcFjN53o6L1Rjf3WzVjFbjNsIhn9g2GSN k6QMcekOG40A0b7kH+LT3hV0d9qOz2YnuEjp75F5ZFnneq3YS3Fwu9IazDjeBZLz2ke8 1WwcYgjkOOjnsccqDNhLMnY7u1GmAYzrGxlqxDtGioj+yEpPzaQ2mbohW3GnMRRdJ2jJ RA5+3xaxCzA+/v6QNLZ/ciYRMJwgQyg1NIfQBw8fdsAiVxvfzRzgty4NYod4GIzdZFe6 D2o+mjNiUZac4zJBtuysht/+w+mEZvcJJGNZ4mQ5QZEWSr5PPtR1lNOCqpKJmZSuP6ES kJ2w== X-Gm-Message-State: APjAAAXNMBsw5gEX0pbyAAkTFihcWp0KpvPaSjLE3Zmyif9p1VbHekfh ydOT5hbqnj43YC4huJjixXvOVQ== X-Google-Smtp-Source: APXvYqwKIr+l07YlcItaF1u709UX90xK2Tc7WXRIYF/W13Pw1h+FWXdppcXjDpU3LyQa5Pkme2ZV9Q== X-Received: by 2002:a17:906:e282:: with SMTP id gg2mr3759266ejb.38.1561549938709; Wed, 26 Jun 2019 04:52:18 -0700 (PDT) Received: from alrua-x1.borgediget.toke.dk ([2a00:7660:6da:443::2]) by smtp.gmail.com with ESMTPSA id q56sm5689322eda.28.2019.06.26.04.52.17 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Wed, 26 Jun 2019 04:52:18 -0700 (PDT) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id C9CB2181CA7; Wed, 26 Jun 2019 13:52:16 +0200 (CEST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Jesper Dangaard Brouer , "Machulsky\, Zorik" Cc: "Jubran\, Samih" , "davem\@davemloft.net" , "netdev\@vger.kernel.org" , "Woodhouse\, David" , "Matushevsky\, Alexander" , "Bshara\, Saeed" , "Wilson\, Matt" , "Liguori\, Anthony" , "Bshara\, Nafea" , "Tzalik\, Guy" , "Belgazal\, Netanel" , "Saidi\, Ali" , "Herrenschmidt\, Benjamin" , "Kiyanovski\, Arthur" , Daniel Borkmann , brouer@redhat.com, Ilias Apalodimas , Alexei Starovoitov , Jakub Kicinski , "xdp-newbies\@vger.kernel.org" Subject: Re: XDP multi-buffer incl. jumbo-frames (Was: [RFC V1 net-next 1/1] net: ena: implement XDP drop support) In-Reply-To: <20190626103829.5360ef2d@carbon> References: <20190623070649.18447-1-sameehj@amazon.com> <20190623070649.18447-2-sameehj@amazon.com> <20190623162133.6b7f24e1@carbon> <20190626103829.5360ef2d@carbon> X-Clacks-Overhead: GNU Terry Pratchett Date: Wed, 26 Jun 2019 13:52:16 +0200 Message-ID: <87a7e4d0nj.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Jesper Dangaard Brouer writes: > On Tue, 25 Jun 2019 03:19:22 +0000 > "Machulsky, Zorik" wrote: > >> On 6/23/19, 7:21 AM, "Jesper Dangaard Brouer" wrote: >> >> On Sun, 23 Jun 2019 10:06:49 +0300 wrote: >> >> > This commit implements the basic functionality of drop/pass logic in the >> > ena driver. >> >> Usually we require a driver to implement all the XDP return codes, >> before we accept it. But as Daniel and I discussed with Zorik during >> NetConf[1], we are going to make an exception and accept the driver >> if you also implement XDP_TX. >> >> As we trust that Zorik/Amazon will follow and implement XDP_REDIRECT >> later, given he/you wants AF_XDP support which requires XDP_REDIRECT. >> >> Jesper, thanks for your comments and very helpful discussion during >> NetConf! That's the plan, as we agreed. From our side I would like to >> reiterate again the importance of multi-buffer support by xdp frame. >> We would really prefer not to see our MTU shrinking because of xdp >> support. > > Okay we really need to make a serious attempt to find a way to support > multi-buffer packets with XDP. With the important criteria of not > hurting performance of the single-buffer per packet design. > > I've created a design document[2], that I will update based on our > discussions: [2] https://github.com/xdp-project/xdp-project/blob/master/areas/core/xdp-multi-buffer01-design.org > > The use-case that really convinced me was Eric's packet header-split. > > > Lets refresh: Why XDP don't have multi-buffer support: > > XDP is designed for maximum performance, which is why certain driver-level > use-cases were not supported, like multi-buffer packets (like jumbo-frames). > As it e.g. complicated the driver RX-loop and memory model handling. > > The single buffer per packet design, is also tied into eBPF Direct-Access > (DA) to packet data, which can only be allowed if the packet memory is in > contiguous memory. This DA feature is essential for XDP performance. > > > One way forward is to define that XDP only get access to the first > packet buffer, and it cannot see subsequent buffers. For XDP_TX and > XDP_REDIRECT to work then XDP still need to carry pointers (plus > len+offset) to the other buffers, which is 16 bytes per extra buffer. Yeah, I think this would be reasonable. As long as we can have a metadata field with the full length + still give XDP programs the ability to truncate the packet (i.e., discard the subsequent pages) I think many (most?) use cases will work fine without having access to the full packet data... -Toke