Re: [PATCH AUTOSEL 4.9 09/26] net/mlx5e: Init ethtool steering for representors

From: Sasha Levin <sashal@kernel.org>
To: Saeed Mahameed <saeedm@mellanox.com>
Cc: "ecree@solarflare.com" <ecree@solarflare.com>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>,
	"kuba@kernel.org" <kuba@kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"gerlitz.or@gmail.com" <gerlitz.or@gmail.com>,
	"davem@davemloft.net" <davem@davemloft.net>
Subject: Re: [PATCH AUTOSEL 4.9 09/26] net/mlx5e: Init ethtool steering for representors
Date: Thu, 16 Apr 2020 19:23:02 -0400	[thread overview]
Message-ID: <20200416232302.GR1068@sasha-vm> (raw)
In-Reply-To: <829c2b8807b4e6c59843b3ab85ca3ccc6cae8373.camel@mellanox.com>

On Thu, Apr 16, 2020 at 09:32:47PM +0000, Saeed Mahameed wrote:
>On Thu, 2020-04-16 at 15:53 -0400, Sasha Levin wrote:
>> If we agree so far, then why do you assume that the same people who
>> do
>> the above also perfectly tag their commits, and do perfect selection
>> of
>> patches for stable? "I'm always right except when I'm wrong".
>
>I am welling to accept people making mistakes, but not the AI..

This is where we disagree. If I can have an AI that performs on par with
an "average" kernel engineer - I'm happy with it.

The way I see AUTOSEL now is an "average" kernel engineer who does patch
sorting for me to review.

Given I review everything that it spits out at me, it's technically a
human error (mine), rather than a problem with the AI, right?

>if it is necessary and we have a magical solution, i will write good AI
>with no false positives to fix or help avoid memleacks.

Easier said than done :)

I think that the "Intelligence" in AI suggests that it can be making
mistakes.

>BUT if i can't achieve 100% success rate, and i might end up
>introducing memleack with my AI, then I wouldn't use AI at all.
>
>We have different views on things.. if i know AI is using kmalloc
>wrongly, I fix it, end of story :).
>
>fact: Your AI is broken, can introduce _new_ un-called for bugs, even
>it is very very very good 99.99% of the cases.

People are broken too, they introduce new bugs, so why are we accepting
new commits into the kernel?

My point is that everything is broken, you can't have 100% perfect
anything.

>> Here's my suggestion: give us a test rig we can run our stable
>> release
>> candidates through. Something that simulates "real" load that
>> customers
>> are using. We promise that we won't release a stable kernel if your
>> tests are failing.
>>
>
>I will be more than glad to do so, is there a formal process for such
>thing ?

I'd love to work with you on this if you're interested. There are a few
options:

1. Send us a mail when you detect a push to a stable-rc branch. Most
people/bots reply to Greg's announce mail with pass/fail.

2. Integrate your tests into kernelci (kernelci.org) - this means that
you'll run a "lab" on prem, and kernelci will schedule builds and tests
on it's own, sending reports to us.

3. We're open to other solutions if you had something in mind, the first
two usually work for people but if you have a different requirement
we'll be happy to figure it out.

-- 
Thanks,
Sasha