From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) by mail.toke.dk (Postfix) with ESMTPS id 4B52387CE93 for ; Wed, 18 Aug 2021 14:50:13 +0200 (CEST) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=ZgDLIDbe Received: by mail-pj1-x102b.google.com with SMTP id nt11so2554865pjb.2 for ; Wed, 18 Aug 2021 05:50:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=b4fBx089jmasN56gf48RyD+HPwaSHlVArEZB5msBo4s=; b=ZgDLIDbeclN1MOme9DLoncA8qq9x7NWNvw2kl4PI2J0YHTslHSHaO6n2wJVsO0bvVy pDBS8LLBHSg9HKTZz8Sue0iihIQiZ7gPJkj/qakiZjcLjt999xErbg91p6S3vXC9fHw5 ZiXgXOUntzXWvLES0BRDiGRZG7mnP8vGCL8zAfiVQnAMqbUaVtVV7ITITrVs7CfuvpVD WaJ4uF0XCBruwRKuywtipLpczZjW+JaFJfTfadl+Jf1+b/Kd93Uh0GfoJBzBkZjaCWX2 NQu2FwDxCxpPBx3mdwgXxY252L6OyxQuXjLHip7OaOQ7S6SamJt55m2tjImS/btWtENP GJ1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=b4fBx089jmasN56gf48RyD+HPwaSHlVArEZB5msBo4s=; b=I+FFKnl+a37lGTX0UWIkV82fQD9or7vVaKYQmuJu6qTZAJL2p1aRAMWtGNeu48oFZG d6i+ARJs2/KOkRiSolunSOXRLW/5tujdN3YJb965d1RM0ZcPqixTKK/GelIEJWufzGhv uakxXlsxUn5kgt9uCsNqEW/U0dv3cYPJuDh/U8ZEQF3lhc7W6G4TP8iXzA9CdTVoUo0O NoTS+FvTp+UkiCRhBgLJRDD4pijL9pIKJ0YuJElnWL6ICslkWmVjMAIPs2RlkqpzT2nG uagHeAGS0VdxiFZtnRByhdOBu1O13vQ0TBdyk5LtLG7VX0c2QK572DoDYLz2YmmhtLh6 Yetw== X-Gm-Message-State: AOAM5313bLdXNlXuJG+eAwjUjOF8JiqWxlbnLwKLT+4g1daRQNl22Ao/ 9XJRaTD5kmO06VYfSsRVqbMPPDBRb1VJLnRqwP0= X-Google-Smtp-Source: ABdhPJxkdIJ0iRwF9xc5GGrBTMubhYP1oHfzQVcq0cEZ6MeNafiAKlWegTX+RRrtcM3jkvvaT2H5PprG6U7KeFLdH0g= X-Received: by 2002:a17:90b:370d:: with SMTP id mg13mr7896373pjb.117.1629291011631; Wed, 18 Aug 2021 05:50:11 -0700 (PDT) MIME-Version: 1.0 References: <811eb35f-5c8b-1591-1e68-8856420b4578@redhat.com> In-Reply-To: <811eb35f-5c8b-1591-1e68-8856420b4578@redhat.com> From: Magnus Karlsson Date: Wed, 18 Aug 2021 14:50:01 +0200 Message-ID: Subject: Re: AF_XDP finding descriptor room for XDP-hints metadata size To: Jesper Dangaard Brouer Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: RHFRIWNOOIDFCOEYG3UQKDZBDRCWI4QA X-Message-ID-Hash: RHFRIWNOOIDFCOEYG3UQKDZBDRCWI4QA X-MailFrom: magnus.karlsson@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "Karlsson, Magnus" , =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= , Kishen Maloor , "Desouza, Ederson" , Alexander Lobakin , Jesper Dangaard Brouer , "xdp-hints@xdp-project.net" , bpf , Netdev X-Mailman-Version: 3.3.4 Precedence: list List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Wed, Aug 18, 2021 at 1:55 PM Jesper Dangaard Brouer wrote: > > > In previous discussions with AF_XDP maintainers (Magnus+Bj=C3=B8rn), I > understood we have two challenges with metadata and BTF id. > > (1) AF_XDP doesn't know size of metadata area. > (2) No room in xdp_desc to store the BTF-id. > > Below I propose new idea to solve (1) metadata size. > > To follow the discussion this is struct xdp_desc: > > /* Rx/Tx descriptor */ > struct xdp_desc { > __u64 addr; > __u32 len; > __u32 options; > }; > > One option (that was rejected) was to store the BTF-id in 'options' and > deduct the metadata size from BTF-id, but it was rejected as it blocks > future usages of 'options'. > > The proposal by Magnus was to use a single bit in 'options' to say this > descriptor contains metadata described via BTF info. And Bj=C3=B8rn propo= sed > to store the BTF-id as the last member in metadata, as it would be > accessible via minus-4 byte offset from packet start 'addr'. And again > via BTF-id code can know the size of metadata area. This is basically what Kishen had in his RFC. > My idea is that we could store the metadata size in top-bits of 'len' > member when we have set the 'options' bit for BTF-metadata. What are the main advantages with this proposal compared to the former one when we can get the length of the metadata section from the BTF-id? When do we actually want to use the length of the metadata section for something in user-space instead of just accessing the members directly? Just trying to understand. Thanks: Magnus > -Jesper >