netdev - Re: [PATCH for-next 2/2] net/mlx5: Update mlx5

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]

Date:	Tue, 12 Apr 2016 10:40:16 +0300
From:	Saeed Mahameed <saeedm@....mellanox.co.il>
To:	leon@...n.nu
Cc:	Or Gerlitz <gerlitz.or@...il.com>,
	Saeed Mahameed <saeedm@...lanox.com>,
	Matan Barak <matanb@...lanox.com>,
	Linux Netdev List <netdev@...r.kernel.org>,
	"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
	"David S. Miller" <davem@...emloft.net>,
	Doug Ledford <dledford@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Or Gerlitz <ogerlitz@...lanox.com>,
	Leon Romanovsky <leonro@...lanox.com>,
	Tal Alon <talal@...lanox.com>
Subject: Re: [PATCH for-next 2/2] net/mlx5: Update mlx5_ifc hardware features

On Tue, Apr 12, 2016 at 9:01 AM, Leon Romanovsky <leon@...n.nu> wrote:
> On Tue, Apr 12, 2016 at 08:36:21AM +0300, Or Gerlitz wrote:
>>
>> I understand your desire to get it down to zero, but it's not gonna
>> work, pick another target.
>
> Maybe you are right and the time will show, but now we (Saeed, Matan and me)
> are trying hard to achieve this goal.
>
>>
>> For example, the networking community has a fairly large rc activity
>> (I would say 10-20x
>> vs rdma), so when Dave does his "merge-rebases" for net-next over net
>> and linus tree
>> (4-5 times in a release), he has to this way or another solve
>> conflicts, yes! ditto for
>> Linus during merge windows and to some extent in rc times too.
>
> I don't see any harm in our desire to decrease work overhead from these
> busy people.
>
>>
>> > It won't help to anyone to split this commit to more than one patch.
>>
>> The commit change-log should make it clear what this is about, and it doesn't.
>> If you believe in something, state that clear, be precise.
>
> I agree.
>
>>
>> As Saeed admitted the shared code in the commit spans maybe 2% of it.
>>
>> The 1st commit deals with a field which is not used in the driver,
>> this is a cleanup
>> that you can do in rc (net) patch (remove the field all together) and
>> overall, w.o seeing

Or, I guess everybody here agrees that mlx5_ifc is our Connectx-4 pure
HW spec, written in C, isn't that cool ?
I see no harm updating our HW spec once in a kernel cycle revealing
new cool HW bits and interfaces
for anyone to use mlx5e/mlx5_core/mlx5_ib .. you name it.

Why would you break down this patch to many when no matter what you
do, at the end it would look the same ?
As Leon mentioned we MLNX maintainers prefer to update this file at
once when possible.

>
> I don't agree with your point that cleanup should go to RC.

I am with Leon on this one, the cleanup code is just cleanup for new
features to come,
it has nothing to do with RC (net).

>
>> the down-stream patches that depend on the newly introduced fields,
>> how do you know there aren't such (unused) bits in the 2nd commit?
>
> No, I don't know in advance, but the truth is that it doesn't bother
> anyone, because we are exposing our internal HW to kernel clients and
> doing it with minimal impact on the maintainers.

Yep, this is exactly what i am trying to say, there are no two ways to
describe/write (mlx5_ifc) code,
if it is a HW spec, why shouldn't it appear from day one ?