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 22CA4246BBB; Thu, 19 Jun 2025 19:19:21 +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=1750360762; cv=none; b=U/qT9li04/oOrryDXTfcaSCZaLow0VDzlM5FWOqSlzi9ocYHBg09cR4lsIgKL161aO2wVY7t6Tf9FTbjlZc6P+h4R5N1RYSthpeC4jYvIiA2nZvIVj+9F0GWPpFn+Yij7JDyo0KMpvft3JKgNNQkDvXWmRAMr11a5s2rmXcFLvo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1750360762; c=relaxed/simple; bh=LDMXTkVlQDnupG+UBA2IQttq9RHsgsS5cAxbc+ksyEU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=jq36VpartB0eTcKqveMqitTB9YAukzqcftr8vV3t0x4F8+DWABWLZLf8wRnQzLQG31O0y5mtN4NFpjYkISyko6yzra32Vt4caa0BbAw4+t8N/9Jpnb2oTkCTPPwgunUywf4FpstGzp68Ec9e+VUzJ+VtBeAtW7p7dx5pDDFdd+8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MET21Rqy; 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="MET21Rqy" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 93C78C4CEEA; Thu, 19 Jun 2025 19:19:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1750360761; bh=LDMXTkVlQDnupG+UBA2IQttq9RHsgsS5cAxbc+ksyEU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=MET21RqyYxksarZ9F9PT2gpDE69XYycjW9Ai26NHx2xjofzlYsdIJWBnPSUsTIte4 KZ3qAg55yExnPpei/HOwZr9eWGR3RMsqHe5AZW+ea9bUyWsR+6Fmi8WVK0S4xyo5u4 plOfsrR8zwhfbWtehabdm98sa2xjzxvc86txr5T1uB4tK3BTw8D/8RPsef806/+NvX WEOvkzpul7y/KcV3kqsYz9qvmEIUdNHCqfHWeFmFjpfU9DNPiJGuRKEm6SUdvDQrRF 7yzXNJUDN+hPRxQOueAaVy47CEI6gnIdiUa2u949Plx0G64msh3cJhRWVEzdCFC0re qWiaJNBXPpIwQ== Date: Thu, 19 Jun 2025 12:19:20 -0700 From: Saeed Mahameed To: Mark Bloch Cc: Jakub Kicinski , "David S. Miller" , Paolo Abeni , Eric Dumazet , Andrew Lunn , Simon Horman , saeedm@nvidia.com, gal@nvidia.com, leonro@nvidia.com, tariqt@nvidia.com, Leon Romanovsky , Jonathan Corbet , netdev@vger.kernel.org, linux-rdma@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net-next 0/5] net/mlx5e: Add support for PCIe congestion events Message-ID: References: <20250619113721.60201-1-mbloch@nvidia.com> <20250619075543.1d31f937@kernel.org> Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On 19 Jun 19:00, Mark Bloch wrote: > > >On 19/06/2025 17:55, Jakub Kicinski wrote: >> On Thu, 19 Jun 2025 14:37:16 +0300 Mark Bloch wrote: >>> PCIe congestion events are events generated by the firmware when the >>> device side has sustained PCIe inbound or outbound traffic above >>> certain thresholds. The high and low threshold are hysteresis thresholds >>> to prevent flapping: once the high threshold has been reached, a low >>> threshold event will be triggered only after the bandwidth usage went >>> below the low threshold. >> >> What are we supposed to do with a series half of which is tagged for >> one tree and half for another? If you want for some of the patches to >> go via the shared tree - you have to post them separately. >> Ideally you'd post them to the list in a combined "pull request + >> patches" format (see for example how Marc posts CAN patches, or Pablo >> posts netfilter). Once we pull that you can sent the net-next stuff >> separately as patches. > >Miscommunication about the proper process, thanks for the explanation. >PR + patches seems cleaner and provides more context, >so I’ll go with that. > >> >> I feel like I just had the same exact conversation with Tariq recently. >> Really not great when same process explainer has to be given to >> multiple people from the same company :( I'd like to remind y'all that >> reading the mailing list is not optional: > >I do follow the mailing list and double checked what should be done in >this scenario. In the end it's my responsibility so it's my fault. > I think what Mark did here is fine, Yes I understand this is not applicable to net-next yet, but the point is review and we can do the following, when review is done: I can Apply the mlx5-next portion to mlx5-next and Mark on V2 can send the net-next stuff + A PR request to the mlx5-next branch, this is how we used to do it all the time, but this time review happens all at once for both trees. Jakub is this acceptable ?