From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 D3BEC15C3 for ; Thu, 15 Aug 2024 00:32:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1723681969; cv=none; b=UKhBVN4MXfbjuEg+QWcCBaoNBc1Da3njA8JvlBfUlyU5TvrM4w/Te2pjzH/EuGSWmEcir34/ORJrsEgfTTTUeaAxeh7lGz+zD9sOrgHjzKNxeA0qPNOvTP82Be1G3Foc2V+du15C458Yvv4KnqMaN18TjTBpzBWML46ugsnHIVg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1723681969; c=relaxed/simple; bh=sqkteINPphqWHaFjtlcfFPQqiDJwS9pT0Z3y5YAaQd0=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=PfwMny7t4kqg7HUckAGjnsZFIiWrwRKavI3UQvYqyMYR0huk7QUxVwAdnQf0SZ2SaxdUH0BHE4bmFCbY7iKI+q6paPqi/5+6uPcBcSK2z/RzKn29fo226gZBmFVOlNe+6NDU4z+dWdrWtBPqMpTA1GIGtdDCqDIrqbawu+SE0Lg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SSZvXPKh; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="SSZvXPKh" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EB092C116B1; Thu, 15 Aug 2024 00:32:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1723681969; bh=sqkteINPphqWHaFjtlcfFPQqiDJwS9pT0Z3y5YAaQd0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=SSZvXPKhkVLLxDKGQoD2JX2HsN9z6Is+/Cs1+GT4XNVUgrQlYMWAwsFkfXrDK9Ukb mg6HN+a5OGuRTuMGYMrRn1zl+gvIHLltJmJ3X4vSFWR4TdA1yMTnw1xz4hH/mmIkHR Bg6RHqAPzkx/rwWh6OTSxMCeWunXPPx65ITEhNcusvZAm/OrY7vNUhBt3N1Gsj+LIH lSlNTLMTHh1nm8GeXssSpoe06gr0kRPI/6zCPTYCh9s58p4ZYMeXH1CSu3Gbnsw72T ZEqt834UtXz5Z+UHKgQ3DDv2uzn1eTNALldhfh67bzyiLeIYhALvcoOyJecaVKWZOt BcJBT588rju1w== Date: Wed, 14 Aug 2024 17:32:48 -0700 From: Jakub Kicinski To: "Maciej =?UTF-8?B?xbtlbmN6eWtvd3NraQ==?=" , Florian Fainelli Cc: "Maciej =?UTF-8?B?xbtlbmN6eWtvd3NraQ==?=" , Linux Network Development Mailing List , "David S . Miller" , Eric Dumazet , Paolo Abeni , "Kory Maincent (Dent Project)" , Ahmed Zaki , Edward Cree , Yuyang Huang , Lorenzo Colitti Subject: Re: [PATCH net-next] ethtool: add tunable api to disable various firmware offloads Message-ID: <20240814173248.685681d7@kernel.org> In-Reply-To: <20240813223325.3522113-1-maze@google.com> References: <20240813223325.3522113-1-maze@google.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, 13 Aug 2024 15:33:25 -0700 Maciej =C5=BBenczykowski wrote: > In order to save power (battery), most network hardware > designed for low power environments (ie. battery powered > devices) supports varying types of hardware/firmware offload > (filtering and/or generating replies) of incoming packets. >=20 > The goal being to prevent device wakeups caused by ingress 'spam'. >=20 > This is particularly true for wifi (especially phones/tablets), > but isn't actually wifi specific. It can also be implemented > in wired nics (TV) or usb ethernet dongles. >=20 > For examples TVs require this to keep power consumption > under (the EU mandated) 2 Watts while idle (display off), > while still being discoverable on the network. Sounds sane, adding Florian, he mentioned MDNS at last netconf. Tho, wasn't there supposed to be a more granular API in Android to control such protocol offloads? You gotta find an upstream driver which implements this for us to merge. If Florian doesn't have any quick uses -- I think Intel ethernet drivers have private flags for enabling/disabling an LLDP agent. That could be another way.. --=20 pw-bot: cr