Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp1639098imw; Tue, 5 Jul 2022 12:53:11 -0700 (PDT) X-Google-Smtp-Source: AGRyM1uhqe52eGrWxu9Dx6SGO/u5pHi+2wvn1ngwasf17sN2L3dAxKwEp+MnsNfDlPTSatXnOVaJ X-Received: by 2002:a17:902:ab1b:b0:16b:e155:f32c with SMTP id ik27-20020a170902ab1b00b0016be155f32cmr13912066plb.104.1657050791332; Tue, 05 Jul 2022 12:53:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657050791; cv=none; d=google.com; s=arc-20160816; b=h+K+lRPXYm3jsSjF536y/NUdL4E9qR6pQDrBRbkqh0+UFcotLBZwATj6y1IKQFDD3y aGgGTB05mqJ/6kOQ3uzyf7o0XiWjFd6pbDaw1e9EauxxB4X/aXlowf/oESSxX4Fd+8YT +Y+59+AHQqvGhFibEhAQ2oRfCPZrU+cg3Ae6W6ipuVQsu4SSBsAJyVDkXX5PUqkevW8v NOrhuwoSk48E2GiSAQFkitsvN3s+rSuvtVIa97SB7auSPTZh0JInRYb8EiAvNvd/0s7E 241GjugBoSRPgT6an4Jr7Cj2F8Xmt9jzsO7uAMOke+Awwcx9YnNpRcLIqoxfRITRWiBT JOqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=p9+vCZQajVY+ar2L6TpAH0S/wS85wKZoc3k+5WoTZvU=; b=BchjtB7WrSB+Fj9rU8WFqm2iwaywGAQll06WjJrmdK9JbSl78nPJt0Aqsvndf+3mZa m6vdttYp5Y/UqtuHBt+PX1gTVuS1MiD1+NsVJ+8Dc1zydV8rENT2/3jAp9zrPOMEiD0Z vvV5R0lk7IUMOmGugamJlu1mDZkSOnH74D5phKT6YxQC6erPEFQeCUkVhRucXDo44MKS RkRDSvxwTh73q9/X9RW6cW9RDPrWP7Wya+wCn1iuIDT3ZJuhAknP2aXVA6ZGZ6UpGO3r 0zC7iwzVsTtD8/o5y3GO1M6HfVTPbP+/gYolpqVZc6vuVU+q18gVeAyGA2sG6obF4e+u sCGg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e4-20020a636904000000b00411c33f55a7si18955588pgc.463.2022.07.05.12.52.59; Tue, 05 Jul 2022 12:53:11 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231365AbiGETJJ (ORCPT + 99 others); Tue, 5 Jul 2022 15:09:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43228 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229872AbiGETJI (ORCPT ); Tue, 5 Jul 2022 15:09:08 -0400 Received: from www62.your-server.de (www62.your-server.de [213.133.104.62]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 403C515FE8; Tue, 5 Jul 2022 12:09:07 -0700 (PDT) Received: from sslproxy02.your-server.de ([78.47.166.47]) by www62.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1o8nuc-000GK3-BY; Tue, 05 Jul 2022 21:08:42 +0200 Received: from [85.1.206.226] (helo=linux.home) by sslproxy02.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1o8nub-000Vkd-MV; Tue, 05 Jul 2022 21:08:41 +0200 Subject: Re: [xdp-hints] Re: [PATCH RFC bpf-next 00/52] bpf, xdp: introduce and use Generic Hints/metadata To: Alexander Lobakin , Jesper Dangaard Brouer Cc: =?UTF-8?Q?Toke_H=c3=b8iland-J=c3=b8rgensen?= , brouer@redhat.com, John Fastabend , Alexei Starovoitov , Andrii Nakryiko , Larysa Zaremba , Michal Swiatkowski , Jesper Dangaard Brouer , =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= , Magnus Karlsson , Maciej Fijalkowski , Jonathan Lemon , Lorenzo Bianconi , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Jesse Brandeburg , Yajun Deng , Willem de Bruijn , bpf@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, xdp-hints@xdp-project.net References: <20220628194812.1453059-1-alexandr.lobakin@intel.com> <62bbedf07f44a_2181420830@john.notmuch> <87iloja8ly.fsf@toke.dk> <20220704154440.7567-1-alexandr.lobakin@intel.com> <0cd3fd67-e179-7c27-a74f-255a05359941@redhat.com> <20220705143838.19500-1-alexandr.lobakin@intel.com> From: Daniel Borkmann Message-ID: Date: Tue, 5 Jul 2022 21:08:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <20220705143838.19500-1-alexandr.lobakin@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Authenticated-Sender: daniel@iogearbox.net X-Virus-Scanned: Clear (ClamAV 0.103.6/26594/Tue Jul 5 09:24:14 2022) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 7/5/22 4:38 PM, Alexander Lobakin wrote: > From: Jesper Dangaard Brouer > Date: Mon, 4 Jul 2022 19:13:53 +0200 [...] >> I have looked at the code in your GitHub tree, and decided that it was >> an over-engineered approach IMHO. Also simply being 52 commits deep >> without having posted this incrementally upstream were also a >> non-starter for me, as this isn't the way-to-work upstream. > > So Ingo announced recently that he has a series of 2300+ patches > to try to fix include hell. Now he's preparing to submit them by > batches/series. Look at this RFC as at an announce. "Hey folks, > I have a bunch of stuff and will be submitting it soon, but I'm > posting the whole changeset here, so you could take a look or > give it a try before it's actually started being posted". > All this is mentioned in the cover letter as well. What is the > problem? Ok, next time I can not do any announces and just start > posting series if it made such misunderstandings. I would suggest to please calm down first. No offense, but above example with the 2300+ patches is not a great one. There is no way any mortal would be able to review them, not even thinking about the cycles spent around rebasing, merge conflict resolution or bugs they may contain. Anyway, that aside.. Your series essentially starts out with ... The series adds ability to pass different frame details/parameters/parameters used by most of NICs and the kernel stack (in skbs), not essential, but highly wanted, such as: * checksum value, status (Rx) or command (Tx); * hash value and type/level (Rx); * queue number (Rx); * timestamps; * and so on. ... so my initial question would be whether in this context there has been done research / analysis of how this can speed up /real world/ production applications such as Katran L4LB [0], for example? What is the speedup you observed with it by utilizing the fields from meta data? Thanks, Daniel [0] https://github.com/facebookincubator/katran