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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 1B1DAC5B579 for ; Fri, 28 Jun 2019 20:08:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E1E32205F4 for ; Fri, 28 Jun 2019 20:08:09 +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="lAImNVy2" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727139AbfF1UII (ORCPT ); Fri, 28 Jun 2019 16:08:08 -0400 Received: from mail-qk1-f194.google.com ([209.85.222.194]:43659 "EHLO mail-qk1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727122AbfF1UII (ORCPT ); Fri, 28 Jun 2019 16:08:08 -0400 Received: by mail-qk1-f194.google.com with SMTP id m14so5939125qka.10 for ; Fri, 28 Jun 2019 13:08:07 -0700 (PDT) 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=lLlyQ5kaVdrnVnTcB00toGJYu3J4KQ63Sf7wJuxSF38=; b=lAImNVy2wuKqDzk0eT7Y0yCpet+4NuMsmicwG6h5GYWdn/DM1hGMDyXRHePbMaSCFp ZZMOQAYxt+Lw9TuVKgKb58swI2j23U9jmuYEwIGvxAfMEEV1z+OKV3+k9xlB59KjFtBP AoPNT3o2l3v1rFC0i8j+vdzqPtBYoTj4/pzSnQcxo6k7h9EOuwkLvOxPBlqLY2uxZvbp XzO/F3137NVDib6689Vp72u9Xej86GPp4cgsbKKrXZjN8c2UZoQg+kpDcRpDhL1A4fEN zMpyf07IKJyTOhWPleaGZwIC+6gEwVtdS/81cyoNaiE7pdbFiYfnNjoo9CiGpGCGR5Yg 1DUg== 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=lLlyQ5kaVdrnVnTcB00toGJYu3J4KQ63Sf7wJuxSF38=; b=EG2Ptcu9n50nb0yyXga5vwUcReFYFPlfpiZGe0Dfg7jpGB3rNfup07VsFQgx2AzLlY HpLrRteH1Hex6LHWmG1XtYuDVJ33dImMlnhNp8B6RrEhe4AxWzd+bkzS0q6lCsn4gkf6 CY9gDaYXSGPQK+xZFldABDrK+MmQwxbCDdmhPlx+drRQHopbw8dt++KGw3mOfOoxX/bz PvGN4C5tZl/0l2tFpbGEY/bUjoeGYV/z8KkBfFYjgj9PcmYo6/3xr5M0HCB0y7hPUSZz 6XPPS0DVUt/+VQtBQmLEGZj829u5BnR1MCKevtCGf3oz2lzrdpcCYA+mex+ySQyEMA5O XD2A== X-Gm-Message-State: APjAAAU8WX78nGw95odq+tVLcWvx9GzEAddRgDf/zXBHAtaS0rHttL7w xGyHAAcUvgJvJoUuH7geVNycgQ== X-Google-Smtp-Source: APXvYqzPVSl9Mlk2IgUzorxAnmeH0zfdmUjZNznUbKqTU35x+liTQL1dOpc7XAVjQlCoP/VzppdApg== X-Received: by 2002:a37:bc84:: with SMTP id m126mr4150878qkf.303.1561752487472; Fri, 28 Jun 2019 13:08:07 -0700 (PDT) Received: from cakuba.netronome.com ([66.60.152.14]) by smtp.gmail.com with ESMTPSA id a19sm1734793qka.103.2019.06.28.13.08.06 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Fri, 28 Jun 2019 13:08:07 -0700 (PDT) Date: Fri, 28 Jun 2019 13:08:02 -0700 From: Jakub Kicinski To: =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= Cc: "Laatz, Kevin" , Jonathan Lemon , netdev@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net, magnus.karlsson@intel.com, bpf@vger.kernel.org, intel-wired-lan@lists.osuosl.org, bruce.richardson@intel.com, ciara.loftus@intel.com Subject: Re: [PATCH 00/11] XDP unaligned chunk placement support Message-ID: <20190628130802.24a6f22b@cakuba.netronome.com> In-Reply-To: References: <20190620083924.1996-1-kevin.laatz@intel.com> <20190627142534.4f4b8995@cakuba.netronome.com> Organization: Netronome Systems, Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Fri, 28 Jun 2019 18:51:37 +0200, Bj=C3=B6rn T=C3=B6pel wrote: > In your example Jakub, how would this look in XDP? Wouldn't the > timestamp be part of the metadata (xdp_md.data_meta)? Isn't > data-data_meta (if valid) <=3D XDP_PACKET_HEADROOM? That was my assumptio= n. The driver parses the metadata and copies it outside of the prepend before XDP runs. Then XDP runs unaware of the prepend contents. =20 That's the current situation. XDP_PACKET_HEADROOM is before the entire frame. Like this: buffer start / DMA addr given to the device / / v v | XDP_HEADROOM | meta data | packet data | Length of meta data comes in the standard fixed size descriptor. The metadata prepend is in TV form ("TLV with no length field", length's implied by type). > There were some discussion on having meta data length in the struct > xdp_desc, before AF_XDP was merged, but the conclusion was that this was > *not* needed, because AF_XDP and the XDP program had an implicit > contract. If you're running AF_XDP, you also have an XDP program running > and you can determine the meta data length (and also getting back the > original buffer). >=20 > So, today in AF_XDP if XDP metadata is added, the userland application > can look it up before the xdp_desc.addr (just like regular XDP), and how > the XDP/AF_XDP application determines length/layout of the metadata i > out-of-band/not specified. >=20 > This is a bit messy/handwavy TBH, so maybe adding the length to the > descriptor *is* a good idea (extending the options part of the > xdp_desc)? Less clean though. OTOH the layout of the meta data still > need to be determined. Right, the device prepend is not exposed as metadata to XDP. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jakub Kicinski Date: Fri, 28 Jun 2019 13:08:02 -0700 Subject: [Intel-wired-lan] [PATCH 00/11] XDP unaligned chunk placement support In-Reply-To: References: <20190620083924.1996-1-kevin.laatz@intel.com> <20190627142534.4f4b8995@cakuba.netronome.com> Message-ID: <20190628130802.24a6f22b@cakuba.netronome.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: intel-wired-lan@osuosl.org List-ID: On Fri, 28 Jun 2019 18:51:37 +0200, Bj?rn T?pel wrote: > In your example Jakub, how would this look in XDP? Wouldn't the > timestamp be part of the metadata (xdp_md.data_meta)? Isn't > data-data_meta (if valid) <= XDP_PACKET_HEADROOM? That was my assumption. The driver parses the metadata and copies it outside of the prepend before XDP runs. Then XDP runs unaware of the prepend contents. That's the current situation. XDP_PACKET_HEADROOM is before the entire frame. Like this: buffer start / DMA addr given to the device / / v v | XDP_HEADROOM | meta data | packet data | Length of meta data comes in the standard fixed size descriptor. The metadata prepend is in TV form ("TLV with no length field", length's implied by type). > There were some discussion on having meta data length in the struct > xdp_desc, before AF_XDP was merged, but the conclusion was that this was > *not* needed, because AF_XDP and the XDP program had an implicit > contract. If you're running AF_XDP, you also have an XDP program running > and you can determine the meta data length (and also getting back the > original buffer). > > So, today in AF_XDP if XDP metadata is added, the userland application > can look it up before the xdp_desc.addr (just like regular XDP), and how > the XDP/AF_XDP application determines length/layout of the metadata i > out-of-band/not specified. > > This is a bit messy/handwavy TBH, so maybe adding the length to the > descriptor *is* a good idea (extending the options part of the > xdp_desc)? Less clean though. OTOH the layout of the meta data still > need to be determined. Right, the device prepend is not exposed as metadata to XDP.