From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mail.toke.dk (Postfix) with ESMTPS id 1797A85EE08 for ; Wed, 7 Jul 2021 18:38:20 +0200 (CEST) Authentication-Results: mail.toke.dk; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=dD0laxGs DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1625675898; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DBW1CRiM/N3so8fZaqeN8+dxCKVMvKUaeu+cUDDm810=; b=dD0laxGsyPC5X0U9DM/06ajgdZNzOuLZQIh6MMMCLtwi5GbmCwJ6/eLzjMAt1KO9wQXNXI +8ZX48JivFi0Z6Eu+RPcGeXVxHgZNUHY4ByDiY8HF+j3lq4RckeO7P8i3wTBwVXx736+Rw Xx78go7KglfJTdKAIapCm3WC3rG9OiY= Received: from mail-ed1-f69.google.com (mail-ed1-f69.google.com [209.85.208.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-414-n3jWD58sP2uYj_CRCcsLjQ-1; Wed, 07 Jul 2021 12:38:17 -0400 X-MC-Unique: n3jWD58sP2uYj_CRCcsLjQ-1 Received: by mail-ed1-f69.google.com with SMTP id p13-20020a05640210cdb029039560ff6f46so1688970edu.17 for ; Wed, 07 Jul 2021 09:38:16 -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:cc:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=DBW1CRiM/N3so8fZaqeN8+dxCKVMvKUaeu+cUDDm810=; b=CgQC8Yut0SRVKDX68abwBnDMo/6ekmQDX1sh4SmEguRt6W0tqdSjtSuY7gtbbbJBSN 3z/xYU9GFbkewfl4Ne18cSSjG4FVl0M2+n7YVyzDAonelXbRwWeTYzA8/jHgsNdFTZie 2+zsXAAMrQ/RjHARy/QyOTiZInUNtp5QV5rQmVcL86ywH7OSwmI0eW818XdAjHnd840c rHKyg+tAyBOgAWYXSpLsHRPwfEPzqLYchhHPqh96BKE4uyapJhgsKBp0z6xW81lZm8YS OIwkYQoVtdAwZfNfsqSZfVy46zvvA6UvtVbPBSJWlsCeujY9qGoWbNBr998Cz2GIpEs6 9B2Q== X-Gm-Message-State: AOAM533toScFGtH9EicKdFL8VoJeJ6Y0JIsdAPj2v0wjkhGEo/pept2X A7O43D3C+1DWy0LztO68ZAszU8fBYkXiYjVx0mgSIyvoatYXO0KGyTOcuhu03bCRiKO16esagvX YQ3h4/nDCb63NNkoMHhih X-Received: by 2002:a17:906:2b0c:: with SMTP id a12mr17557664ejg.429.1625675895788; Wed, 07 Jul 2021 09:38:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyge9/mUDkZz73CJs0xxkPc0yDh08pMoNf3q9j71TnM8YePtaeEEZtGPsb8hnThkB/gOtKWHw== X-Received: by 2002:a17:906:2b0c:: with SMTP id a12mr17557634ejg.429.1625675895601; Wed, 07 Jul 2021 09:38:15 -0700 (PDT) Received: from [192.168.42.238] (3-14-107-185.static.kviknet.dk. [185.107.14.3]) by smtp.gmail.com with ESMTPSA id t27sm7136628eje.86.2021.07.07.09.38.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Jul 2021 09:38:14 -0700 (PDT) From: Jesper Dangaard Brouer X-Google-Original-From: Jesper Dangaard Brouer Subject: Re: A look into XDP hints for AF_XDP To: Alexei Starovoitov , "Desouza, Ederson" References: <20210624215411.79324c9d@carbon> <22999687621ecba7281a905a3dbbc148fee12581.camel@intel.com> Message-ID: Date: Wed, 7 Jul 2021 18:38:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=jbrouer@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Message-ID-Hash: 4WOOJ4OF776HTOBPJEEUUXAHUMZUQLWH X-Message-ID-Hash: 4WOOJ4OF776HTOBPJEEUUXAHUMZUQLWH X-MailFrom: jbrouer@redhat.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: brouer@redhat.com, "Swiatkowski, Michal" , "xdp-hints@xdp-project.net" , "Lobakin, Alexandr" , "Karlsson, Magnus" , "saeed@kernel.org" , "bpf@vger.kernel.org" , "andrii.nakryiko@gmail.com" 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 25/06/2021 00.39, Alexei Starovoitov wrote: > On Thu, Jun 24, 2021 at 3:18 PM Desouza, Ederson > wrote: >> Wait - it may be done in user space by libbpf, but it needs the >> instrumented object code. It won't work for pure user space >> applications, like those which use AF_XDP. Unless we're going to build >> them in a special way, like we do for the kernel side of BPF >> applications. > It can be made to work. See my reply to Magnus. > It's not a lot of code to make that happen. I agree with Alexei, it will not be a lot of code to interpret the BTF info in userspace. In userspace AF_XDP code, we could simply decode the offset of e.g. member named "rxhash32" and validate that the expected size is 32 bit (4 bytes). Then we store the offset associated with rxhash32 for a given BTF-ID. When AF_XDP program see BTF-ID it can lookup the offset of rxhash32 and move those 4-bytes into a variable for rxhash32. Implementation details (sorry to complicate this slightly): Because metadata area grows with a negative offset seen from ctx->data, and AF_XDP descriptor don't know the size of metadata area (like XDP does). Then the offset we store (e.g. associated with rxhash32) need to be converted to a negative offset from packet ctx->data start. --Jesper