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 47EA59FF04E for ; Tue, 18 Apr 2023 14:45:59 +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=Bf4zW486 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1681821958; 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=pDXDjF1nYY/KD56jlqYvE6WKgtxK7sp+U3MRycfCfiA=; b=Bf4zW486+q5nBlkq00VGeEG/oTq76xNG/0S37MxG5s7+/E4N6TYgOv/27se/36lLLpj10v DTe9BAZiD3awDGJ5Qy5UR7ahkLBH+qHaUpBU7tCjZpel4WVrBhKcv7QdBZ4PD2yNLXU0/o zqU25f5wjifj1lbKj16SVotjPjW4WP0= Received: from mail-ej1-f72.google.com (mail-ej1-f72.google.com [209.85.218.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-384-FfzIWWISNrikt_RxzJ1pmg-1; Tue, 18 Apr 2023 08:45:56 -0400 X-MC-Unique: FfzIWWISNrikt_RxzJ1pmg-1 Received: by mail-ej1-f72.google.com with SMTP id vt6-20020a170907a60600b009217998c8e3so10087472ejc.14 for ; Tue, 18 Apr 2023 05:45:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681821955; x=1684413955; h=content-transfer-encoding:in-reply-to:references:to :content-language:subject:cc:user-agent:mime-version:date:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=pDXDjF1nYY/KD56jlqYvE6WKgtxK7sp+U3MRycfCfiA=; b=QbJvdRSEaxR8rRP6RCRAwYpZnK3x859bV/VZoVx8vXMH+f/belCOdr0oOYK9dOPDsu /sh+Os+66GXt42m5QNFXa2fnxq9rEgRRY9aND/5uHYM2mIxBMOILE5KnSTnUKzPuSuAd Xs5dGdfaVhK+qRdUDPnNW/lAOctSoezVTpdIZv4eXQoDBj49smIKFlzdKmXGcERCDTLy JAJVQIrK88Mw6wEOtc1uqdWaSS6d2YVxaEvh9gAzzNPJY6XxBXNKhZ3Hlbk9uHlII1iH fcHxnINWRg7fcK3s0q6S1VZY57a7deZilKfdoSZcVh+67kyurudrsgtkEvq1qe/MkYJD CESQ== X-Gm-Message-State: AAQBX9fjSZ/kXB9ADaAxGHCYPiG5rcqIMRcNLGTC9DIDcO02UFSGuAlh HAqrHYcCvcOvN/qM8JtHnA27yD4skHwdodA7CnRMBcdtslrcEe7JvP/32pKJDEKVDc2Hqo6Na/G 6MPuOag2to8Pgaj/7uYyeNlkbD/US X-Received: by 2002:a17:907:20c8:b0:93c:efaf:ba75 with SMTP id qq8-20020a17090720c800b0093cefafba75mr10178449ejb.37.1681821955283; Tue, 18 Apr 2023 05:45:55 -0700 (PDT) X-Google-Smtp-Source: AKy350aiC5zCA5YAs3FTtyCXVLr/PBTq902GZqsOW+OujaYsI0J5kBFLBO9dijp8pa5nkXMHxAU4EA== X-Received: by 2002:a17:907:20c8:b0:93c:efaf:ba75 with SMTP id qq8-20020a17090720c800b0093cefafba75mr10178419ejb.37.1681821954909; Tue, 18 Apr 2023 05:45:54 -0700 (PDT) Received: from [192.168.42.222] (194-45-78-10.static.kviknet.net. [194.45.78.10]) by smtp.gmail.com with ESMTPSA id rx22-20020a1709068e1600b0094f968ecc97sm2304338ejc.13.2023.04.18.05.45.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 18 Apr 2023 05:45:54 -0700 (PDT) From: Jesper Dangaard Brouer X-Google-Original-From: Jesper Dangaard Brouer Message-ID: <6b04def5-a3aa-1f77-b29d-bea4845e2678@redhat.com> Date: Tue, 18 Apr 2023 14:45:52 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 To: "Song, Yoong Siang" , "bpf@vger.kernel.org" , Stanislav Fomichev , =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vu?= =?UTF-8?Q?sen?= References: <168174338054.593471.8312147519616671551.stgit@firesoul> <168174343294.593471.10523474360770220196.stgit@firesoul> In-Reply-To: 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: 2RFUKHFSJMHJNZ6WAOWQTEQGHBFOJB6D X-Message-ID-Hash: 2RFUKHFSJMHJNZ6WAOWQTEQGHBFOJB6D 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, "netdev@vger.kernel.org" , "martin.lau@kernel.org" , "ast@kernel.org" , "daniel@iogearbox.net" , "Lobakin, Aleksander" , "Zaremba, Larysa" , "xdp-hints@xdp-project.net" , "intel-wired-lan@lists.osuosl.org" , "pabeni@redhat.com" , "Brandeburg, Jesse" , "kuba@kernel.org" , "edumazet@google.com" , "john.fastabend@gmail.com" , "hawk@kernel.org" , "davem@davemloft.net" X-Mailman-Version: 3.3.8 Precedence: list Subject: [xdp-hints] Re: [PATCH bpf-next V1 2/5] igc: add igc_xdp_buff wrapper for xdp_buff in driver List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 18/04/2023 06.34, Song, Yoong Siang wrote: > On Monday, April 17, 2023 10:57 PM, Jesper Dangaard Brouer wrote: >> Driver specific metadata data for XDP-hints kfuncs are propagated via tail >> extending the struct xdp_buff with a locally scoped driver struct. >> >> Zero-Copy AF_XDP/XSK does similar tricks via struct xdp_buff_xsk. This >> xdp_buff_xsk struct contains a CB area (24 bytes) that can be used for extending >> the locally scoped driver into. The XSK_CHECK_PRIV_TYPE define catch size >> violations build time. >> > > Since the main purpose of this patch is to introduce igc_xdp_buff, and > you have another two patches for timestamp and hash, > thus, suggest to move timestamp and hash related code into respective patches. > >> Signed-off-by: Jesper Dangaard Brouer >> --- >> drivers/net/ethernet/intel/igc/igc.h | 6 ++++++ >> drivers/net/ethernet/intel/igc/igc_main.c | 30 ++++++++++++++++++++++------- >> 2 files changed, 29 insertions(+), 7 deletions(-) >> >> diff --git a/drivers/net/ethernet/intel/igc/igc.h >> b/drivers/net/ethernet/intel/igc/igc.h >> index f7f9e217e7b4..c609a2e648f8 100644 >> --- a/drivers/net/ethernet/intel/igc/igc.h >> +++ b/drivers/net/ethernet/intel/igc/igc.h >> @@ -499,6 +499,12 @@ struct igc_rx_buffer { >> }; >> }; >> >> +/* context wrapper around xdp_buff to provide access to descriptor >> +metadata */ struct igc_xdp_buff { >> + struct xdp_buff xdp; >> + union igc_adv_rx_desc *rx_desc; > > Move rx_desc to 4th patch (Rx hash patch) > Hmm, rx_desc is also needed by 3rd patch (Rx timestamp), so that would break... I can reorder patches, and have "Rx hash patch" come before "Rx timestamp" patch. >> +}; >> + >> struct igc_q_vector { >> struct igc_adapter *adapter; /* backlink */ >> void __iomem *itr_register; >> diff --git a/drivers/net/ethernet/intel/igc/igc_main.c >> b/drivers/net/ethernet/intel/igc/igc_main.c >> index bfa9768d447f..3a844cf5be3f 100644 >> --- a/drivers/net/ethernet/intel/igc/igc_main.c >> +++ b/drivers/net/ethernet/intel/igc/igc_main.c >> @@ -2236,6 +2236,8 @@ static bool igc_alloc_rx_buffers_zc(struct igc_ring >> *ring, u16 count) >> if (!count) >> return ok; >> >> + XSK_CHECK_PRIV_TYPE(struct igc_xdp_buff); >> + >> desc = IGC_RX_DESC(ring, i); >> bi = &ring->rx_buffer_info[i]; >> i -= ring->count; >> @@ -2520,8 +2522,8 @@ static int igc_clean_rx_irq(struct igc_q_vector >> *q_vector, const int budget) >> union igc_adv_rx_desc *rx_desc; >> struct igc_rx_buffer *rx_buffer; >> unsigned int size, truesize; >> + struct igc_xdp_buff ctx; >> ktime_t timestamp = 0; >> - struct xdp_buff xdp; >> int pkt_offset = 0; >> void *pktbuf; >> >> @@ -2555,13 +2557,14 @@ static int igc_clean_rx_irq(struct igc_q_vector >> *q_vector, const int budget) >> } >> >> if (!skb) { >> - xdp_init_buff(&xdp, truesize, &rx_ring->xdp_rxq); >> - xdp_prepare_buff(&xdp, pktbuf - igc_rx_offset(rx_ring), >> + xdp_init_buff(&ctx.xdp, truesize, &rx_ring->xdp_rxq); >> + xdp_prepare_buff(&ctx.xdp, pktbuf - igc_rx_offset(rx_ring), >> igc_rx_offset(rx_ring) + pkt_offset, >> size, true); >> - xdp_buff_clear_frags_flag(&xdp); >> + xdp_buff_clear_frags_flag(&ctx.xdp); >> + ctx.rx_desc = rx_desc; > > Move rx_desc to 4th patch (Rx hash patch) Again would break 3rd patch. > >> >> - skb = igc_xdp_run_prog(adapter, &xdp); >> + skb = igc_xdp_run_prog(adapter, &ctx.xdp); >> } >> >> if (IS_ERR(skb)) { >> @@ -2583,9 +2586,9 @@ static int igc_clean_rx_irq(struct igc_q_vector >> *q_vector, const int budget) >> } else if (skb) >> igc_add_rx_frag(rx_ring, rx_buffer, skb, size); >> else if (ring_uses_build_skb(rx_ring)) >> - skb = igc_build_skb(rx_ring, rx_buffer, &xdp); >> + skb = igc_build_skb(rx_ring, rx_buffer, &ctx.xdp); >> else >> - skb = igc_construct_skb(rx_ring, rx_buffer, &xdp, >> + skb = igc_construct_skb(rx_ring, rx_buffer, &ctx.xdp, >> timestamp); >> >> /* exit if we failed to retrieve a buffer */ @@ -2686,6 +2689,15 >> @@ static void igc_dispatch_skb_zc(struct igc_q_vector *q_vector, >> napi_gro_receive(&q_vector->napi, skb); } >> >> +static struct igc_xdp_buff *xsk_buff_to_igc_ctx(struct xdp_buff *xdp) { >> + /* xdp_buff pointer used by ZC code path is alloc as xdp_buff_xsk. The >> + * igc_xdp_buff shares its layout with xdp_buff_xsk and private >> + * igc_xdp_buff fields fall into xdp_buff_xsk->cb >> + */ >> + return (struct igc_xdp_buff *)xdp; } >> + > > Move xsk_buff_to_igc_ctx to 3th patch (timestamp patch), which is first patch > adding xdp_metadata_ops support to igc. > Hmm, maybe, but that make the "wrapper" patch incomplete and then it gets "completed" in the first patch that adds a xdp_metadata_ops. >> static int igc_clean_rx_irq_zc(struct igc_q_vector *q_vector, const int budget) { >> struct igc_adapter *adapter = q_vector->adapter; @@ -2704,6 +2716,7 >> @@ static int igc_clean_rx_irq_zc(struct igc_q_vector *q_vector, const int >> budget) >> while (likely(total_packets < budget)) { >> union igc_adv_rx_desc *desc; >> struct igc_rx_buffer *bi; >> + struct igc_xdp_buff *ctx; >> ktime_t timestamp = 0; >> unsigned int size; >> int res; >> @@ -2721,6 +2734,9 @@ static int igc_clean_rx_irq_zc(struct igc_q_vector >> *q_vector, const int budget) >> >> bi = &ring->rx_buffer_info[ntc]; >> >> + ctx = xsk_buff_to_igc_ctx(bi->xdp); > > Move xsk_buff_to_igc_ctx to 3th patch (timestamp patch), which is first patch > adding xdp_metadata_ops support to igc. > Sure, but it feels wrong to no "complete" the wrapper work in the wrapper patch. >> + ctx->rx_desc = desc; > > Move rx_desc to 4th patch (Rx hash patch) > I'll reorder patch 3 and 4, else it doesn't make any sense to gradually introduce the members in wrapper struct igc_xdp_buff. --Jesper