From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; spf=pass (mailfrom) smtp.mailfrom=iogearbox.net (client-ip=2a01:4f8:d0a:276a::2; helo=www62.your-server.de; envelope-from=daniel@iogearbox.net; receiver=) Received: from www62.your-server.de (www62.your-server.de [IPv6:2a01:4f8:d0a:276a::2]) by mail.toke.dk (Postfix) with ESMTPS id E2E1F9859F8 for ; Tue, 5 Jul 2022 21:09:09 +0200 (CEST) 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 To: Alexander Lobakin , Jesper Dangaard Brouer 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) Message-ID-Hash: D3H2PKM7JWSR3IEWNRIXPWCWI2VRNLR2 X-Message-ID-Hash: D3H2PKM7JWSR3IEWNRIXPWCWI2VRNLR2 X-MailFrom: daniel@iogearbox.net 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: =?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 X-Mailman-Version: 3.3.5 Precedence: list Subject: [xdp-hints] Re: [PATCH RFC bpf-next 00/52] bpf, xdp: introduce and use Generic Hints/metadata List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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