From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3B83CEB64DD for ; Wed, 21 Jun 2023 15:07:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232990AbjFUPHx (ORCPT ); Wed, 21 Jun 2023 11:07:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46446 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232978AbjFUPHc (ORCPT ); Wed, 21 Jun 2023 11:07:32 -0400 Received: from smtp-fw-52004.amazon.com (smtp-fw-52004.amazon.com [52.119.213.154]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 673934239; Wed, 21 Jun 2023 08:02:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1687359745; x=1718895745; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=zbPAeOGrUEIOV+JujOL9INmhyma6JwFI+vqDZGWGqOk=; b=fop1sEkk90qtxm8OZfTFpmBI5Q6kymfZtycgyCraGKaaWw9K/9hyrbgo 2dd2Zr5+kIjW+fiVrNDuF48N/eztk0PKMT8Ucj7qseujBHBP7jI5lFKWM ulpXD9rnjwKELepcnj/AN1kzf451o37NV+N/YQXPVTtoWbAycsf6VlC/3 Y=; X-IronPort-AV: E=Sophos;i="6.00,260,1681171200"; d="scan'208";a="138321779" Received: from iad12-co-svc-p1-lb1-vlan2.amazon.com (HELO email-inbound-relay-pdx-2a-m6i4x-d40ec5a9.us-west-2.amazon.com) ([10.43.8.2]) by smtp-border-fw-52004.iad7.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Jun 2023 15:01:15 +0000 Received: from EX19MTAUWC001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan3.pdx.amazon.com [10.236.137.198]) by email-inbound-relay-pdx-2a-m6i4x-d40ec5a9.us-west-2.amazon.com (Postfix) with ESMTPS id EC7B840D4E; Wed, 21 Jun 2023 15:01:12 +0000 (UTC) Received: from EX19D004ANA001.ant.amazon.com (10.37.240.138) by EX19MTAUWC001.ant.amazon.com (10.250.64.174) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.26; Wed, 21 Jun 2023 15:01:12 +0000 Received: from 88665a182662.ant.amazon.com.com (10.119.169.70) by EX19D004ANA001.ant.amazon.com (10.37.240.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.26; Wed, 21 Jun 2023 15:01:07 +0000 From: Kuniyuki Iwashima To: CC: , , , , , , , , , , , , , , , , , , , , , , , , , Subject: Re: [PATCH bpf-next v2 3/6] net: remove duplicate reuseport_lookup functions Date: Wed, 21 Jun 2023 08:00:58 -0700 Message-ID: <20230621150058.59250-1-kuniyu@amazon.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.119.169.70] X-ClientProxiedBy: EX19D044UWB003.ant.amazon.com (10.13.139.168) To EX19D004ANA001.ant.amazon.com (10.37.240.138) Precedence: bulk List-ID: X-Mailing-List: linux-kselftest@vger.kernel.org From: Lorenz Bauer Date: Wed, 21 Jun 2023 09:01:15 +0100 > On Tue, Jun 20, 2023 at 7:31 PM Kuniyuki Iwashima wrote: > > > > Good point. This is based on an assumption that all SO_REUSEPORT > > sockets have the same score, which is wrong for two corner cases > > if reuseport_has_conns() == true : > > > > 1) SO_INCOMING_CPU is set > > -> selected sk might have +1 score > > > > 2) BPF prog returns ESTABLISHED and/or SO_INCOMING_CPU sk > > -> selected sk will have more than 8 > > > > Using the old score could trigger more lookups depending on the > > order that sockets are created. > > So the result will still be correct, but it's less performant? Happy > to fix a perf regression, but if the result is incorrect this might > need a separate fix? Right, the result is always correct. If BPF prog selects a different socket per lookup, there is no consistency, but it _is_ corret. > I did some more digging. I think this was introduced by commit > efc6b6f6c311 ("udp: Improve load balancing for SO_REUSEPORT.") which > unfortunately ran into a merge conflict. That resulted in Dave Miller > moving the bug around in commit a57066b1a019 ("Merge > git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net"). Can you > take a look and let me know if you think that is correct? Yes, I should have updated the score too in efc6b6f6c311 to save unneeded lookups. The conflict itself was resolved properly.