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 9C5B99854BF for ; Mon, 4 Jul 2022 19:14:00 +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=PArGwWa2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1656954838; 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=dNFZBk2MReDVOF2gT6UYM02hb0KdZvS6at3FbBoI3pM=; b=PArGwWa2AIQ6Ws1O5kEobm8vkhA56MI4clSOkzrGxO95KE2Gq1cwLIstvzQBcdcLp5J0gv gOvoUeytuZne1cFZtZVvRzkMet/xX64+OEELCNHWKn+ET7JdnoEp9yx3pQwdI7eW1buQGq 4D3EiAop7tfEcvq85JflVW/9YC2DXMU= Received: from mail-lj1-f199.google.com (mail-lj1-f199.google.com [209.85.208.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-121-8ePU_iGQNnWakBkB8y-u0w-1; Mon, 04 Jul 2022 13:13:57 -0400 X-MC-Unique: 8ePU_iGQNnWakBkB8y-u0w-1 Received: by mail-lj1-f199.google.com with SMTP id c13-20020a05651c014d00b0025bb794a55eso2874771ljd.10 for ; Mon, 04 Jul 2022 10:13:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:date:mime-version:user-agent:cc :subject:content-language:to:references:in-reply-to :content-transfer-encoding; bh=dNFZBk2MReDVOF2gT6UYM02hb0KdZvS6at3FbBoI3pM=; b=7r/7pzm6rjXJp95Hq9uPnHvxXdxanMDBUq9+3AljTMyakRfSoS75ljKpdvIR7qOvhR mPbnlh90tHt8yGLSiCLjd38DtvntPBVm3SxqBLdHrq9LcbbvDYLzRHCQL1C+27jfKZQh trNSlJX7giGbvIH8jSTphI+1dBAJz9vHAsxSH7GNr2zXHsLRwLtkoW0WUDtbFzLc5kK0 bXFE+FUqWuBAIXOAs4oyt5vAPb8cVyfpCQoEs9syfAR0PJM0UCWv5cfh0PkOHW+o0lPe 9gk8IkldaZn2n0k5kIMiHLcoOm7BvnZZVhAuuXHbsJAsFH9yL7is6eXctU40AI2n1DYD hHnA== X-Gm-Message-State: AJIora8QS/K3KTCN5qYfiXthSyi6UR1ymFSyGkByMbn9F+7DjJxS+m3d JXyliICDN4+diSERk5oL9tXmnP0MiWcWuSt3LgIQYdv2b9JiPnEDS76RpupmyTV72kICmyDGnq2 9/K98HGbwWm6/vGcy+hU5 X-Received: by 2002:a2e:b751:0:b0:25b:da59:96b9 with SMTP id k17-20020a2eb751000000b0025bda5996b9mr16564756ljo.176.1656954835692; Mon, 04 Jul 2022 10:13:55 -0700 (PDT) X-Google-Smtp-Source: AGRyM1tHu1DJfF7/r9dEXd50aOLye631DC1z4l08yWjIoREL+G9uEz5rjyOO5svoU/MfRlDuSC4GRQ== X-Received: by 2002:a2e:b751:0:b0:25b:da59:96b9 with SMTP id k17-20020a2eb751000000b0025bda5996b9mr16564722ljo.176.1656954835371; Mon, 04 Jul 2022 10:13:55 -0700 (PDT) Received: from [192.168.0.50] (87-59-106-155-cable.dk.customer.tdc.net. [87.59.106.155]) by smtp.gmail.com with ESMTPSA id j13-20020ac253ad000000b0047f7f4cb583sm5200739lfh.288.2022.07.04.10.13.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Jul 2022 10:13:54 -0700 (PDT) From: Jesper Dangaard Brouer X-Google-Original-From: Jesper Dangaard Brouer Message-ID: <0cd3fd67-e179-7c27-a74f-255a05359941@redhat.com> Date: Mon, 4 Jul 2022 19:13:53 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 To: Alexander Lobakin , =?UTF-8?Q?Toke_H=c3=b8iland-J=c3=b8rgensen?= References: <20220628194812.1453059-1-alexandr.lobakin@intel.com> <62bbedf07f44a_2181420830@john.notmuch> <87iloja8ly.fsf@toke.dk> <20220704154440.7567-1-alexandr.lobakin@intel.com> In-Reply-To: <20220704154440.7567-1-alexandr.lobakin@intel.com> Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=jbrouer@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: QZUI5Z6K3KFN46PG572DUWNGBXJPI3VW X-Message-ID-Hash: QZUI5Z6K3KFN46PG572DUWNGBXJPI3VW 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, John Fastabend , Alexei Starovoitov , Daniel Borkmann , 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 04/07/2022 17.44, Alexander Lobakin wrote: >> Agreed. This incremental approach is basically what Jesper's >> simultaneous series makes a start on, AFAICT? Would be nice if y'all >> could converge the efforts :) > > I don't know why at some point Jesper decided to go on his own as he > for sure was using our tree as a base for some time, dunno what > happened then. Regarding these two particular submissions, I didn't > see Jesper's RFC when sending mine, only after when I went to read > some stuff. > Well, I have written to you (offlist) that the git tree didn't compile, so I had a hard time getting it into a working state. We had a ping-pong of stuff to fix, but it wasn't and you basically told me to switch to using LLVM to compile your kernel tree, I was not interested in doing that. 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. To get the ball rolling, I have implemented the base XDP-hints support here[1] with only 9 patches (including support for two drivers). IMHO we need to start out small and not intermix these huge refactoring patches. E.g. I'm not convinced renaming net/{core/xdp.c => bpf/core.c} is an improvement. -Jesper [1] https://lore.kernel.org/bpf/165643378969.449467.13237011812569188299.stgit@firesoul/