From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id B43301B2B7 for ; Fri, 26 Jan 2018 06:59:32 +0100 (CET) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1-us4.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 557C6280057; Fri, 26 Jan 2018 05:59:31 +0000 (UTC) Received: from [192.168.38.17] (84.52.114.114) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 26 Jan 2018 05:59:26 +0000 To: Thomas Monjalon CC: , Olivier Matz References: <1516899647-8541-1-git-send-email-arybchenko@solarflare.com> <56198984.NQf2azoMJa@xps> From: Andrew Rybchenko Message-ID: Date: Fri, 26 Jan 2018 08:59:21 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <56198984.NQf2azoMJa@xps> Content-Language: en-GB X-Originating-IP: [84.52.114.114] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-11.0.0.1191-8.100.1062-23620.002 X-TM-AS-Result: No--13.360700-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-MDID: 1516946372-Ed+wR1tZpJ5e Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH 0/6] net/sfc: implement dynamic logging 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: , X-List-Received-Date: Fri, 26 Jan 2018 05:59:33 -0000 On 01/26/2018 12:38 AM, Thomas Monjalon wrote: > 25/01/2018 18:00, Andrew Rybchenko: >> Unfortunately we're a bit late with dynamic logging implementation. >> So, it can wait for 18.05 release cycle if required. >> >> The series adds EXPERIMENTAL EAL feature which removes dependency >> on EAL arguments processing and log types registration. It stores >> EAL loglevel arguments in the list and adds API function to register >> a new log type and pick up its value from EAL arguments. >> >> For us it is important since we would like to be able to control >> per-device log level, e.g. pmd.net.sfc.main.0000:01:00.0. > Would it be possible to consider EAL patch for 18.05, > and others for 18.02? Artefacts of the EAL patch are used in the subsequent patches, so I think it does not make sense to redo subsequent patches without the EAL one and, then, change it once again on the next release cycle.