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 D855DA052E; Mon, 9 Mar 2020 17:23:31 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 066611C030; Mon, 9 Mar 2020 17:23:31 +0100 (CET) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id ADDF51C02E; Mon, 9 Mar 2020 17:23:29 +0100 (CET) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Mar 2020 09:23:28 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,533,1574150400"; d="scan'208";a="242019772" Received: from yexl-server.sh.intel.com (HELO localhost) ([10.67.117.17]) by orsmga003.jf.intel.com with ESMTP; 09 Mar 2020 09:23:25 -0700 Date: Tue, 10 Mar 2020 00:20:57 +0800 From: Ye Xiaolong To: David Marchand Cc: Haiyue Wang , dev , Qi Zhang , Qiming Yang , Beilei Xing , Wei Zhao , Aaron Conole , ci@dpdk.org, Ferruh Yigit , thomas@monjalon.net Message-ID: <20200309162057.GD112283@intel.com> References: <20200309141437.11800-1-haiyue.wang@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Subject: Re: [dpdk-dev] [PATCH v1 0/4] add Intel DCF PMD support 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" Hi, David On 03/09, David Marchand wrote: >On Mon, Mar 9, 2020 at 3:22 PM Haiyue Wang wrote: >> >> A DCF (Device Config Function) based approach is proposed where a device >> bound to the device's VF0 can act as a sole controlling entity to exercise >> advance functionality (such as switch, ACL) for rest of the VFs. >> >> The DCF works as a standalone PMD to support this function, which shares the >> ice PMD flow control core function and the iavf virtchnl mailbox core module. >> >> This patchset is based on: >> [1] https://patchwork.dpdk.org/cover/66417/ update ice base code > >The problem is that the CI(s) won't handle this. >Example for the robot: https://travis-ci.com/ovsrobot/dpdk/builds/152461907 > >Maybe we could add something as an annotation to the cover letter or >the first patch of a series so that the CI(s) can detect and try to be >intelligent? Agree, It'd be helpful if the cover letter of the first patch contains some base tree info including the base commit and dependency patchset info (if any), so the CI can determine the correct base on top of which the developer's patchset applies to avoid any apply issue and potential false positive. And I know there is one option '--base'' of `git format-patch` which is dedicated for this kind of usage, it can help create the base tree info block which can be easily consumed by the CI. Here is the simple intro of it. Imagine that on top of the public commit P (already in upstream), the developer applied well-known (on-flight, in the mailing list but not merged yet) patches X, Y and Z from somebody else or himself, and then built his three-patch series A, B, C, the commit history would be like: ................................................ ---P---X---Y---Z---A---B---C ................................................ With `git format-patch --base=P -3 C`, where P could be the exact commit sha, or variants e.g. HEAD~6, we can also use --base=auto for convenience, the base tree information block will be shown at the end of the first message the command outputs (either the first patch, or the cover letter), like this: ------------ base-commit: P prerequisite-patch-id: X prerequisite-patch-id: Y prerequisite-patch-id: Z ------------ Here P is the commit sha, and X,Y,Z are the patch ids of the dependency patches. With this info in place, I think CI should be able to setup the exact base for the coming patchset, the missing part I can see is the mapping of (in-flight patch <-> patch id), since we have all the in-flight patches in patchwork, creating and maintaining such mapping in DB is doable, what do you think? Thanks, Xiaolong > > >-- >David Marchand >