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.129.124]) by mail.toke.dk (Postfix) with ESMTPS id 2E84F98BF73 for ; Mon, 18 Jul 2022 11:38:33 +0200 (CEST) Authentication-Results: mail.toke.dk; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=CtjvTniy DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1658137111; 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=6S7vWV6CH/Jlwkpy/Zv9SGCaVUBqz0UpDbTFe7FRECs=; b=CtjvTniyPzmOqXekB4oJse75dz9P7N02RVWJQ2hl+qx/1OkHWdGGchy8iX5zwGsMVbrAgQ ATFduy2wgWCRuK74BtVUsFA1myUXvGE2VpkoIDV21R8TYd4mOaWWzaisxKaljxoO4LEYNg XeLClKNGXTB9c6VNIBiogRx7HFba1zQ= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-329-K9RdjI0UNfCvl1Z8jI9XMQ-1; Mon, 18 Jul 2022 05:38:29 -0400 X-MC-Unique: K9RdjI0UNfCvl1Z8jI9XMQ-1 Received: by mail-wm1-f69.google.com with SMTP id v123-20020a1cac81000000b003a02a3f0beeso8432686wme.3 for ; Mon, 18 Jul 2022 02:38:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :to:cc:references:content-language:from:in-reply-to :content-transfer-encoding; bh=6S7vWV6CH/Jlwkpy/Zv9SGCaVUBqz0UpDbTFe7FRECs=; b=is+W7R/qVGDXrDokgM2jLvsdP2OeDMWoGZ3ELPNsASF5Fi9RnvdzwswcJllM10JikD vH8VlXJVzcw0hfx8OYUQOqhJyu1p1XdKpvdTfpJxAJn1Zv/L3aZEv+XIpaADHDx6RkeJ sefZXyec3DYLo+ww8CnqM/N0v7MCBW6v6Tym1DFtOag+ySt56vltxs+ZGa7HmZ2Qx6zl XL7Bw/T5xfFNbfubGJtKKYA1vass6qwk/8iUcuirIVqfnSgOetiQjRWltMaJvTZT2LEy IJFCthL9kIMjYEvU480iAuZYJMPAb6pNwQ9czulwVQjDtrwfdKAhVijt3+NynQcsxjFe M+yg== X-Gm-Message-State: AJIora9ZgCL1ih9PsitoXizSM+0zjV5OpDcLLk3kGzG5cK7hHsGTdF4s Ujhu7h/5JxAJyq2nBupIovB+CaGy1+cso0bTGth7zeRVkMpLWkARZLBPGg8yY855ic34D/VjUpi p+r93MBQavltLkZA0rjyu X-Received: by 2002:a05:600c:34c4:b0:3a2:e259:925b with SMTP id d4-20020a05600c34c400b003a2e259925bmr24821445wmq.99.1658137108853; Mon, 18 Jul 2022 02:38:28 -0700 (PDT) X-Google-Smtp-Source: AGRyM1tTzXBv0PCOwa5kAfrHYd/xKUB7mxTcRK1rTRJ6HJ7dabb9Iv+6xfkRIOEPF2jqCUJqe1lkRw== X-Received: by 2002:a05:600c:34c4:b0:3a2:e259:925b with SMTP id d4-20020a05600c34c400b003a2e259925bmr24821439wmq.99.1658137108673; Mon, 18 Jul 2022 02:38:28 -0700 (PDT) Received: from ?IPV6:2a01:b340:64:d3ca:188c:3c48:3209:7784? ([2a01:b340:64:d3ca:188c:3c48:3209:7784]) by smtp.gmail.com with ESMTPSA id q5-20020a1c4305000000b003a2d6c623f3sm17795654wma.19.2022.07.18.02.38.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 Jul 2022 02:38:28 -0700 (PDT) Message-ID: <431a0822-5aa7-b5e0-2389-bb8c66f42e8f@redhat.com> Date: Mon, 18 Jul 2022 10:38:27 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.0.2 To: Jesper Dangaard Brouer , bpf@vger.kernel.org References: <165643378969.449467.13237011812569188299.stgit@firesoul> <165643386896.449467.16847946958931423319.stgit@firesoul> From: Maryam Tahhan In-Reply-To: <165643386896.449467.16847946958931423319.stgit@firesoul> Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=mtahhan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Message-ID-Hash: 3YEVGV3RDVCCRKM3NZ67FQRJXZ2WJRGZ X-Message-ID-Hash: 3YEVGV3RDVCCRKM3NZ67FQRJXZ2WJRGZ X-MailFrom: mtahhan@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: xdp-hints@xdp-project.net X-Mailman-Version: 3.3.5 Precedence: list Subject: [xdp-hints] Re: [PATCH RFC bpf-next 7/9] i40e: add XDP-hints handling List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 28/06/2022 17:31, Jesper Dangaard Brouer wrote: > + > +static inline void i40e_process_xdp_hints(struct i40e_ring *rx_ring, > + union i40e_rx_desc *rx_desc, > + struct xdp_buff *xdp, > + u64 qword) > +{ > + u32 rx_status = (qword & I40E_RXD_QW1_STATUS_MASK) >> > + I40E_RXD_QW1_STATUS_SHIFT; > + u32 tsynvalid = rx_status & I40E_RXD_QW1_STATUS_TSYNVALID_MASK; > + u32 tsyn = (rx_status & I40E_RXD_QW1_STATUS_TSYNINDX_MASK) >> > + I40E_RXD_QW1_STATUS_TSYNINDX_SHIFT; > + u64 tsyn_ts; > + > + struct i40e_rx_ptype_decoded ptype; > + struct xdp_hints_i40e *xdp_hints; > + struct xdp_hints_common *common; > + u32 btf_id = btf_id_xdp_hints_i40e; > + u32 btf_sz = sizeof(*xdp_hints); > + u32 f1 = 0, f2, f3, f4, f5 = 0; > + u8 rx_ptype; > + > + if (!(rx_ring->netdev->features & NETIF_F_XDP_HINTS)) > + return; > + > + /* Driver have xdp headroom when using build_skb */ > + if (unlikely(!ring_uses_build_skb(rx_ring))) > + return; > + > + xdp_hints = xdp->data - btf_sz; > + common = &xdp_hints->common; > + > + if (unlikely(tsynvalid)) { > + struct xdp_hints_i40e_timestamp *hints; > + > + tsyn_ts = i40e_ptp_rx_hwtstamp_raw(rx_ring->vsi->back, tsyn); > + btf_id = btf_id_xdp_hints_i40e_timestamp; > + btf_sz = sizeof(*hints); > + hints = xdp->data - btf_sz; > + hints->rx_timestamp = ns_to_ktime(tsyn_ts); > + f1 = HINT_FLAG_RX_TIMESTAMP; > + } > + > + /* ptype needed by both hash and checksum code */ > + rx_ptype = (qword & I40E_RXD_QW1_PTYPE_MASK) >> I40E_RXD_QW1_PTYPE_SHIFT; > + ptype = decode_rx_desc_ptype(rx_ptype); > + > + f2 = i40e_rx_hash_xdp(rx_ring, rx_desc, xdp, qword, xdp_hints, ptype); > + f3 = i40e_rx_checksum_xdp(rx_ring->vsi, qword, xdp_hints, ptype); > + f4 = xdp_hints_set_rxq(common, rx_ring->queue_index); > + > + if (unlikely(qword & BIT(I40E_RX_DESC_STATUS_L2TAG1P_SHIFT))) { > + __le16 vlan_tag = rx_desc->wb.qword0.lo_dword.l2tag1; > + > + f5 = xdp_hints_set_vlan(common, le16_to_cpu(vlan_tag), > + htons(ETH_P_8021Q)); > + } > + > + xdp_hints_set_flags(common, (f1 | f2 | f3 | f4 | f5)); > + common->btf_id = btf_id; > + xdp->data_meta = xdp->data - btf_sz; I think it might be worth considering leaving a predefined size space in the headroom before the data (but after the metadata) for encapsulation headers that may be applied to the packet as it transitions to it's final destination through a host. In other words starting the metadata further up so that the BTF id resides at a known offset from data. Say for example a bpf program that inserts vlan/vxlan tags/headers on received packets on a host should have enough space to apply that vlan tag without having to copy the metadata and shift it before it does that. Or maybe there was something that was already accounting for this in the design and I missed it. Would really appreciate a pointer in that case.