From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) by mail.toke.dk (Postfix) with ESMTPS id 89D099B1129 for ; Tue, 1 Nov 2022 02:59:57 +0100 (CET) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20210112 header.b=T7WFWydh Received: by mail-io1-xd2b.google.com with SMTP id z3so11275909iof.3 for ; Mon, 31 Oct 2022 18:59:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=tz2IvL4GW+A3brfA0AhzvjM7rEyd8FHY7/DmEU+TeH0=; b=T7WFWydh0LD3vChB+GqXb24P/X7ei44KzKvR+TqHO0dBFvi1ARAMzt/YdIkeyK5D0B 6SpyKlYkdBkTL+ptY4jMEbHc8Z2nBKaFn2Kkny8zJ6VG3WVZeE8EIkTGPP+Y+/dAJiN9 B5d9kgTK45V9q7DumxvznM0dMrK9k7b/YNdzR0kCpNl1NcSA1uIJ2PFskkhzdfcriAC7 cTysy9ebws1XNyQluguVdoeKSDhL+Ll6HPXVJa0d0kIgMVNSGdioRezPNB+Dgzpez9DP 1cgJIpCoSa9DrLsvVlRsKc96vLaNdva8AHLt2u18+xRBNSH38thtssS/YYKp98VGAdm9 IdBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=tz2IvL4GW+A3brfA0AhzvjM7rEyd8FHY7/DmEU+TeH0=; b=0WfLQJJIf3HOZNo+KYsDeU2gsqobx5kdv8nhUFBpDidz6336018WqXAecO1ui09PFo ssnbsf/33I9wuzdBBvEZ9FsRZKocGnC+gfTG9VXkfhY6KjXUAg58T6u3lr07LDyzqeHi 6equ9rhRG8YmYbvT6lN/2zuvB1UI7F6bflq+kzVSRLIg2C2QcOtqQwxLfV88kPv1JF0j IgMPXaG7+temmm+5t8X93qAceA9Hry9i6qUzZNQvBJUHryeb7PGgdHoU3V+N4QNcvLuI KKB2Wb4kK0dZV/d88sI67vbpPNrut9hzXkZrBGM1abxRb6NYmq/vh/VOtXs1NM/ddeVm Jx1w== X-Gm-Message-State: ACrzQf2XySRrPHZod3HlpBRAdhC9K9+ICb6uaZX+RuHfm2wfKOaJd/wN zLfRyYfpY/kwjTCIXvMYlQD9j+OPQBhvC/290JpaeA== X-Google-Smtp-Source: AMsMyM50fMCh4OLS6CKka+IBqOHJTMPLVNjRYGU0Vk4PSoQ7dXSO1vU905rE0hcc/k1KpEbbppvxgUw01IoBR3QG3LY= X-Received: by 2002:a02:ad18:0:b0:372:e2a5:3a54 with SMTP id s24-20020a02ad18000000b00372e2a53a54mr40880jan.106.1667267995551; Mon, 31 Oct 2022 18:59:55 -0700 (PDT) MIME-Version: 1.0 References: <20221027200019.4106375-1-sdf@google.com> <635bfc1a7c351_256e2082f@john.notmuch> <20221028110457.0ba53d8b@kernel.org> <635c62c12652d_b1ba208d0@john.notmuch> <20221028181431.05173968@kernel.org> <5aeda7f6bb26b20cb74ef21ae9c28ac91d57fae6.camel@siemens.com> <875yg057x1.fsf@toke.dk> <77b115a0-bbba-48eb-89bd-3078b5fb7eeb@linux.dev> In-Reply-To: <77b115a0-bbba-48eb-89bd-3078b5fb7eeb@linux.dev> From: Stanislav Fomichev Date: Mon, 31 Oct 2022 18:59:44 -0700 Message-ID: To: Martin KaFai Lau Content-Type: text/plain; charset="UTF-8" Message-ID-Hash: IKN63WTDHPD2LNYTKRQITMURBBGJEFOV X-Message-ID-Hash: IKN63WTDHPD2LNYTKRQITMURBBGJEFOV X-MailFrom: sdf@google.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: "Bezdeka, Florian" , "kuba@kernel.org" , "john.fastabend@gmail.com" , "alexandr.lobakin@intel.com" , "anatoly.burakov@intel.com" , "song@kernel.org" , "Deric, Nemanja" , "andrii@kernel.org" , "Kiszka, Jan" , "magnus.karlsson@gmail.com" , "willemb@google.com" , "ast@kernel.org" , "brouer@redhat.com" , "yhs@fb.com" , "kpsingh@kernel.org" , "daniel@iogearbox.net" , "bpf@vger.kernel.org" , "mtahhan@redhat.com" , "xdp-hints@xdp-project.net" , "netdev@vger.kernel.org" , "jolsa@kernel.org" , "haoluo@google.com" , =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= X-Mailman-Version: 3.3.5 Precedence: list Subject: [xdp-hints] Re: [RFC bpf-next 0/5] xdp: hints via kfuncs List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Mon, Oct 31, 2022 at 3:57 PM Martin KaFai Lau wrote: > > On 10/31/22 10:00 AM, Stanislav Fomichev wrote: > >> 2. AF_XDP programs won't be able to access the metadata without using a > >> custom XDP program that calls the kfuncs and puts the data into the > >> metadata area. We could solve this with some code in libxdp, though; if > >> this code can be made generic enough (so it just dumps the available > >> metadata functions from the running kernel at load time), it may be > >> possible to make it generic enough that it will be forward-compatible > >> with new versions of the kernel that add new fields, which should > >> alleviate Florian's concern about keeping things in sync. > > > > Good point. I had to convert to a custom program to use the kfuncs :-( > > But your suggestion sounds good; maybe libxdp can accept some extra > > info about at which offset the user would like to place the metadata > > and the library can generate the required bytecode? > > > >> 3. It will make it harder to consume the metadata when building SKBs. I > >> think the CPUMAP and veth use cases are also quite important, and that > >> we want metadata to be available for building SKBs in this path. Maybe > >> this can be resolved by having a convenient kfunc for this that can be > >> used for programs doing such redirects. E.g., you could just call > >> xdp_copy_metadata_for_skb() before doing the bpf_redirect, and that > >> would recursively expand into all the kfunc calls needed to extract the > >> metadata supported by the SKB path? > > > > So this xdp_copy_metadata_for_skb will create a metadata layout that > > Can the xdp_copy_metadata_for_skb be written as a bpf prog itself? > Not sure where is the best point to specify this prog though. Somehow during > bpf_xdp_redirect_map? > or this prog belongs to the target cpumap and the xdp prog redirecting to this > cpumap has to write the meta layout in a way that the cpumap is expecting? We're probably interested in triggering it from the places where xdp frames can eventually be converted into skbs? So for plain 'return XDP_PASS' and things like bpf_redirect/etc? (IOW, anything that's not XDP_DROP / AF_XDP redirect). We can probably make it magically work, and can generate kernel-digestible metadata whenever data == data_meta, but the question - should we? (need to make sure we won't regress any existing cases that are not relying on the metadata) > > the kernel will be able to understand when converting back to skb? > > IIUC, the xdp program will look something like the following: > > > > if (xdp packet is to be consumed by af_xdp) { > > // do a bunch of bpf_xdp_metadata_ calls and assemble your > > own metadata layout > > return bpf_redirect_map(xsk, ...); > > } else { > > // if the packet is to be consumed by the kernel > > xdp_copy_metadata_for_skb(ctx); > > return bpf_redirect(...); > > } > > > > Sounds like a great suggestion! xdp_copy_metadata_for_skb can maybe > > put some magic number in the first byte(s) of the metadata so the > > kernel can check whether xdp_copy_metadata_for_skb has been called > > previously (or maybe xdp_frame can carry this extra signal, idk).