From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id AFFD3A0531; Tue, 4 Feb 2020 11:03:25 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D9D981C00E; Tue, 4 Feb 2020 11:03:24 +0100 (CET) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by dpdk.org (Postfix) with ESMTP id CCC711C00D for ; Tue, 4 Feb 2020 11:03:23 +0100 (CET) X-Originating-IP: 37.58.153.206 Received: from [10.0.3.185] (bny206.haproxy.com [37.58.153.206]) (Authenticated sender: grive@u256.net) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id A632E60012; Tue, 4 Feb 2020 10:03:22 +0000 (UTC) To: Thomas Monjalon , Pavan Nikhilesh Bhagavatula Cc: "dev@dpdk.org" , David Marchand , Vamsi Krishna Attunuru , Jerin Jacob Kollanukkaran References: <3825f1afeebd62b3e50535574ddedadb31435616.1579772895.git.grive@u256.net> <9100295.rMLUfLXkoz@xps> From: Gaetan Rivet Message-ID: <9b82a6cd-a286-5a5e-7cef-6d16a4355e06@u256.net> Date: Tue, 4 Feb 2020 11:03:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: <9100295.rMLUfLXkoz@xps> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v7] eal: add manual probing option X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 03/02/2020 23:21, Thomas Monjalon wrote: > 03/02/2020 06:16, Pavan Nikhilesh Bhagavatula: >> @David Marchand @thomas@monjalon.net >> >> Ping? >> >> Are there any more changes required for this patch? It's been in queue since last October. > > Sorry we have not decided whether it is a good idea or not. > > All changes related to probing are very sensitive, > and we know a big refactoring would be better than stacking > more and more options and corner cases. > > As we are busy with ABI stability stuff, we did not allocate > enough time to properly think about this feature. > Please accept our apologies, and let's consider it as > a high priority for 20.05 cycle. > > > Hello Thomas, This is unfortunate. I pushed Pavan to accept an alternative implementation of this functionality that was less obtrusive, to make the integration smoother. I took care to alleviate those risks from the common path. The big refactoring is needed yes, but considering the current path I'm not seeing it happen in 20.05. If that means taking this patch as-is in 20.05 for Marvell users, I'm not sure much is gained from waiting 3 months, except minimal risk avoidance.