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]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 521BA38C2DE for ; Fri, 29 May 2026 10:53:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780052005; cv=none; b=uAUIw+HTcQpFEFwMwv3C7h+hVzAKCSxY6WbYPfPHWj2lEOMPfGmALFJs2c00Y32bz3QqPyo3N2lxDdVRT/igTSN+sEbyePAJ5yQJUvC3yKD+PuU/zb5tiQdbyy/saHP/M5kogPC2ksDwoVaQZIcstBSU+Ncy7MRmefrGNUJoW8w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780052005; c=relaxed/simple; bh=AmilyMgVPk0GQtdVfeFcAOQZf56kW1xFZHZVcCQ/9E4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=kkpun1f7fM3i+dOFcWnUUkj+8gcT9ujXeT1mLgNpnD80BAloHcsZGX/m37Wl33BRqDXHGwmC6syIj921baOO1zmxtCPbaufuBwq0eR9Gjh8Digw/Rr5TIcl/NbU4aSmxi8lb918Jy9s4VVaQsdD7IIuGtG/BXnn7jMkffWIRvJE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=XWACDx0+; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=n7SUpnhW; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="XWACDx0+"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="n7SUpnhW" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1780052003; 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=8zb2QZTiLloyzysLbsnjtkqxvYXQnQ641Q4cnR6a8OI=; b=XWACDx0+tNF6Iif8GSILz2ig+Wtbj7vrqaB/8ImBg98uKbyZu8sOAT0E1xcpamUodwCdH2 EPhewQ9NySYTlJ/6JLOFqT3mQEx0vB4ZyA/FTRd7iKVIfHKWAZuxcZ6dwAtnc7iodQbBdB mgtfRDaBD/4K+5kWUtspgXSihjC9Vwg= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-624-vXI---h7NdaXk0QXoHeTZQ-1; Fri, 29 May 2026 06:53:22 -0400 X-MC-Unique: vXI---h7NdaXk0QXoHeTZQ-1 X-Mimecast-MFC-AGG-ID: vXI---h7NdaXk0QXoHeTZQ_1780052001 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-4909ea0ffbeso3136705e9.1 for ; Fri, 29 May 2026 03:53:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1780052001; x=1780656801; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=8zb2QZTiLloyzysLbsnjtkqxvYXQnQ641Q4cnR6a8OI=; b=n7SUpnhWY40YQptbUSL6Jz9eLQuphYbUIQv6Y/A9WZNiLRXnbWdZLOye/sKgtIEBbQ L1C/bAhDtGPPhc0sa+9Qqjs3b3qlEFAZTgi4mD9zbs9RJN/rT1iuudrSDW7m24tneu8N U1drG+J+aEAJDtyLty+88rmqnln6GK/q5XQZ3SwqyKHwPKTuyPXXLLeFIbzF8FGvdVQP +7VtY1JgMr3iwhlIyxKEy0jp5i04/nBTsVnxsRamUUjgWgjypnxR23w/+Wo6VsQfqfaE N3Dhn4eWGLy+cQX5GIxcI24+5PYkef7VNfCrkaX6w4lIwQwboxH7/ThF+TIC1D9YvCZv Bjfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780052001; x=1780656801; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=8zb2QZTiLloyzysLbsnjtkqxvYXQnQ641Q4cnR6a8OI=; b=IrW2HK9O8/hhvv+54fhIOMDuqFkY/G6ExgKOPdZkxfN8KfJKiqisz8V7GAjwd4aCoy QAgVfNcpG9a51ES91rjMDu9B1Q9HndGfNuKbBoBewiXGWPOU+ZFXMTLd6E4uAcG8+8u6 yn/6RSBSRKNnTePMmYlMNQTWdo9XvbYsJIDd5GC0y5fvWFh6tEcrdTzXuCy5saVYdTbh Ka3CfKmSNC03N86gTLQ8MtIfIgp1sGlrnC7yoMT180i9fjFqPx/EbbAU7UUmenFomP21 d35dPMaMCE+bXcmncY8rnlctYjKqDWYFzIlPPF+CBMUv1FmXpTzuPeuFut97aMtxSwQx tTVg== X-Forwarded-Encrypted: i=1; AFNElJ+kjBxOcQPdLGRym+lHKwqF2nQlRZWmjE6hfXt12SMc9M5W/NVD1F3x0OGwerzIOg5mGRR1LTteqGUNjw0=@vger.kernel.org X-Gm-Message-State: AOJu0Yw5iEsBW4vmEL03FnxjeYsWuvV8KBACf/837EV++XUOPa3LyBOs XAD0zhRw0H+KhupAd92LB7fZuwSvL+H9Z8W30YdX7TbtylLU7V7dqI/ndMyGdM4wOuQXVNmXTzh xjNrU/zdUQazTWx5RxD1IswztkXJD6YX+03q7ZbZ8socsDVzDHZOz/KdfvBWIaICtJQ== X-Gm-Gg: Acq92OEMLF+PYFzu9h0BbdyKfKBa9zUvR/sVuFiDrsZPx9WWCUKQxgMvKdLYqWGPNIG pJmQJ19CaqAXH5sN27eyj8ufczJUkRDesM/Dt7AIU8NXzObP2iLq+8h50XqZJ+5AxQkFbiowZP0 wBOeVQj6NQFS+I97GIJOr1EkaCI8AR6WrdQhutHdsJVmeXZXt+y88LnCirboIptZwT++9CiRxzF e4s+HnpKq+cLVvATAiiVGlIscoBVbHib33yzQrUHIZ069NQgZYDvKUwtfsPdKUp79cppAHSIUyy 0vD+yUpWbEMcws9ceKoYBYvXdDcPM9t8SPs/tt/yx+rJHXc9bSF4be7juDjOFFylJKg5vFbz4cJ vV5m74OPHPUCXIZH2iVUsEu6fDemdXD/Y5cpDvEcFtEkjmx9NvVthILEA488mJXyVuVs= X-Received: by 2002:a05:600c:3542:b0:48a:5c23:cab with SMTP id 5b1f17b1804b1-4909c0a7df8mr41205335e9.19.1780052000819; Fri, 29 May 2026 03:53:20 -0700 (PDT) X-Received: by 2002:a05:600c:3542:b0:48a:5c23:cab with SMTP id 5b1f17b1804b1-4909c0a7df8mr41204955e9.19.1780052000422; Fri, 29 May 2026 03:53:20 -0700 (PDT) Received: from [192.168.88.32] ([150.228.93.150]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4909c0498e0sm16548075e9.0.2026.05.29.03.53.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 May 2026 03:53:19 -0700 (PDT) Message-ID: Date: Fri, 29 May 2026 12:53:18 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH V2 net-next 0/6] net: hns3: enhance tc flow offload support To: Jijie Shao , Simon Horman Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org, andrew+netdev@lunn.ch, shenjian15@huawei.com, liuyonglong@huawei.com, chenhao418@huawei.com, huangdonghua3@h-partners.com, yangshuaisong@h-partners.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org References: <20260523105449.661848-1-shaojijie@huawei.com> <20260527095930.GI2256768@horms.kernel.org> <83f34836-c848-469a-9c1c-7f28bf3035fc@huawei.com> From: Paolo Abeni Content-Language: en-US In-Reply-To: <83f34836-c848-469a-9c1c-7f28bf3035fc@huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 5/28/26 1:24 PM, Jijie Shao wrote: > on 2026/5/28 17:06, Paolo Abeni wrote: >> This one: >> >> --- >>> + if (is_zero_ether_addr(match.key->dst)) >>> + rule->unused_tuple |= BIT(INNER_DST_MAC); >>> + if (is_zero_ether_addr(match.key->src)) >>> + rule->unused_tuple |= BIT(INNER_SRC_MAC); >> Should the "is this tuple unused" decision be driven by the mask >> rather than the key? >> A tc-flower rule that explicitly matches an all-zero address, for >> example: >> tc filter add ... flower dst_mac 00:00:00:00:00:00 ... >> tc filter add ... flower src_ip 0.0.0.0 ... >> tc filter add ... flower src_ip :: ... >> produces match.key->{src,dst} == 0 with match.mask->{src,dst} set to >> all-ones. With the new checks above, those rules now have >> INNER_{SRC,DST}_MAC / INNER_{SRC,DST}_IP added to rule->unused_tuple >> even though the user asked to match exactly that address. >> Downstream, hclge_fd_convert_tuple() short-circuits on unused_tuple: >> if (rule->unused_tuple & BIT(tuple_bit)) >> return true; >> so the tuple is not programmed into the TCAM key and the field is >> effectively wildcarded in hardware, with no -EINVAL or extack returned >> to the user. >> Real-world patterns that rely on all-zero addresses include DHCPv4 >> DISCOVER (src 0.0.0.0), IPv6 DAD/NUD probes and DHCPv6 (src ::), and >> deliberate matches on the all-zero MAC. >> --- >> >> and similar later ones look real/relevant to me, and IMHO should be >> addressed. > > Yes, I saw this issue. There is similar logic in the existing function hclge_fd_check_ether_tuple(): > > static int hclge_fd_check_ether_tuple(struct ethhdr *spec, u32 *unused_tuple) > { > if (!spec || !unused_tuple) > return -EINVAL; > > *unused_tuple |= BIT(INNER_SRC_IP) | BIT(INNER_DST_IP) | > BIT(INNER_SRC_PORT) | BIT(INNER_DST_PORT) | > BIT(INNER_IP_TOS) | BIT(INNER_IP_PROTO); > > if (is_zero_ether_addr(spec->h_source)) > *unused_tuple |= BIT(INNER_SRC_MAC); > > if (is_zero_ether_addr(spec->h_dest)) > *unused_tuple |= BIT(INNER_DST_MAC); > > if (!spec->h_proto) > *unused_tuple |= BIT(INNER_ETH_TYPE); > > return 0; > } > > This looks like a common problem for hns3. My original idea was to send > a separate bugfix later to fix all the all-zero MAC or IP addresses.> The current tc flow implementation logic is consistent with ethtool -U. > > Alternatively, I can first fix the tc flow issue in v4, and then submit > a bugfix later to fix the potential issues in ethtool -U. I think the latter option (v4 using `mask` and follow-up patch for existing code) is the better one (to avoid introducing new code with a known issues). Thanks, Paolo