netdev - Re: [net-next v1] net: wwan: t7xx: Parameterize data plane RX BAT and FAG count

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20250520122141.025616c9@kernel.org>
Date: Wed,  4 Jun 2025 17:17:22 +0800
From: Jinjian Song <jinjian.song@...ocom.com>
To: kuba@...nel.org
Cc: andrew+netdev@...n.ch,
	angelogioacchino.delregno@...labora.com,
	chandrashekar.devegowda@...el.com,
	chiranjeevi.rapolu@...ux.intel.com,
	corbet@....net,
	danielwinkler@...gle.com,
	davem@...emloft.net,
	edumazet@...gle.com,
	haijun.liu@...iatek.com,
	helgaas@...nel.org,
	horms@...nel.org,
	jinjian.song@...ocom.com,
	johannes@...solutions.net,
	korneld@...gle.com,
	linux-arm-kernel@...ts.infradead.org,
	linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	linux-mediatek@...ts.infradead.org,
	loic.poulain@...aro.org,
	m.chetan.kumar@...ux.intel.com,
	matthias.bgg@...il.com,
	netdev@...r.kernel.org,
	pabeni@...hat.com,
	rafael.wang@...ocom.com,
	ricardo.martinez@...ux.intel.com,
	ryazanov.s.a@...il.com
Subject: Re: [net-next v1] net: wwan: t7xx: Parameterize data plane RX BAT and FAG count

>On Tue, 20 May 2025 10:59:34 +0800 Jinjian Song wrote:
>>   If it's not feasible to directly add parameters for configuring this RX buffer(BAT/FAG) to 
>> the mtk_t7xx driver, would it be allowed to add aparameter for a default configuration 
>> ratio (1/2, 1/4)? Or is it not recommended to use driver parameters for mtk_t7xx driver.
>
>Looks into devlink params then
>

Hi Jakub,

The parameters are used by data plane to request RX DMA buffers for the entrire lifetime of
the driver, so it's best to determine them at the driver load time. Adjusting them after the
driver has been probed could introduce complex issues (e.g., the DMA buffers may already be
in use for communication when the parameters are changed. While devlink appears to support
parameter configuration via driver reload and runtime adjustment, both of these occur after
the driver has been probed, which doesn't seem very friendly to the overall logic.

Thanks.

Jinjian,
Best Regards.