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 83E6AC48BD6 for ; Wed, 26 Jun 2019 08:39:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 61A8220663 for ; Wed, 26 Jun 2019 08:39:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726839AbfFZIjV convert rfc822-to-8bit (ORCPT ); Wed, 26 Jun 2019 04:39:21 -0400 Received: from mx1.redhat.com ([209.132.183.28]:21720 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725379AbfFZIjV (ORCPT ); Wed, 26 Jun 2019 04:39:21 -0400 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id EB7C559464; Wed, 26 Jun 2019 08:38:45 +0000 (UTC) Received: from carbon (ovpn-200-49.brq.redhat.com [10.40.200.49]) by smtp.corp.redhat.com (Postfix) with ESMTP id B2CF46013D; Wed, 26 Jun 2019 08:38:31 +0000 (UTC) Date: Wed, 26 Jun 2019 10:38:29 +0200 From: Jesper Dangaard Brouer To: "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, Toke =?UTF-8?B?SMO4aWxhbmQtSsO4cmdlbnNlbg==?= , Ilias Apalodimas , Alexei Starovoitov , Jakub Kicinski , "xdp-newbies@vger.kernel.org" Subject: XDP multi-buffer incl. jumbo-frames (Was: [RFC V1 net-next 1/1] net: ena: implement XDP drop support) Message-ID: <20190626103829.5360ef2d@carbon> In-Reply-To: References: <20190623070649.18447-1-sameehj@amazon.com> <20190623070649.18447-2-sameehj@amazon.com> <20190623162133.6b7f24e1@carbon> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Wed, 26 Jun 2019 08:39:20 +0000 (UTC) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 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. > [1] http://vger.kernel.org/netconf2019.html -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer