netdev - Re: [net-next V3 15/15] Documentation: networking: Add description for multi-pf netdev

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] [day] [month] [year] [list]

Message-ID: <ZeLV2s_nU8DZ-4WG@x130>
Date: Fri, 1 Mar 2024 23:31:38 -0800
From: Saeed Mahameed <saeed@...nel.org>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Jiri Pirko <jiri@...nulli.us>,
	"Samudrala, Sridhar" <sridhar.samudrala@...el.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Tariq Toukan <ttoukan.linux@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	Paolo Abeni <pabeni@...hat.com>, Eric Dumazet <edumazet@...gle.com>,
	Saeed Mahameed <saeedm@...dia.com>, netdev@...r.kernel.org,
	Tariq Toukan <tariqt@...dia.com>, Gal Pressman <gal@...dia.com>,
	Leon Romanovsky <leonro@...dia.com>, jay.vosburgh@...onical.com
Subject: Re: [net-next V3 15/15] Documentation: networking: Add description
 for multi-pf netdev

On 28 Feb 09:43, Jakub Kicinski wrote:
>On Wed, 28 Feb 2024 09:06:04 -0800 Jakub Kicinski wrote:
>> > >Yes, looks RDMA-centric. RDMA being infamously bonding-challenged.
>> >
>> > Not really. It's just needed to consider all usecases, not only netdev.
>>
>> All use cases or lowest common denominator, depends on priorities.
>
>To be clear, I'm not trying to shut down this proposal, I think both
>have disadvantages. This one is better for RDMA and iperf, the explicit
>netdevs are better for more advanced TCP apps. All I want is clear docs
>so users are not confused, and vendors don't diverge pointlessly.

Just posted v4 with updated documentation that should cover the basic
feature which we believe is the most basic that all vendors should
implement, mlx5 implementation won't change much if we decide later to move
to some sort of a "generic netdev" interface, we don't agree it should be a
new kind of bond, as bond was meant for actual link aggregation of
multi-port devices, but again the mlx5 implementation will remain the same
regardless of any future extension of the feature, the defaults are well
documented and carefully selected for best user expectations.