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 87473A0566; Tue, 10 Mar 2020 15:11:30 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 16F6C1BFF7; Tue, 10 Mar 2020 15:11:30 +0100 (CET) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by dpdk.org (Postfix) with ESMTP id B90E91BFF5 for ; Tue, 10 Mar 2020 15:11:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1583849488; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=H635jZqvcSSRtgI7gV7MrpLxfUZkLaDEY60pTm/k2s8=; b=hAiRGin4HFickCagX4Sj8n3S3Mgd4SOX0WvFe/fZNWCCmW8PMRrDScjKvtDPaGd661/0dn E/1HOinTqFkK43sm1vWkNPc2h7CvWXHAgOjza/xEKOreE/KVz1ZZrOaTjaqe4SMr07he/k 9vsRQq7tXSpaWt0qhFXJfUWuQg4XpZ0= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-145-qbg7OgpLNC2z9odUlXfujQ-1; Tue, 10 Mar 2020 10:11:21 -0400 X-MC-Unique: qbg7OgpLNC2z9odUlXfujQ-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 2708A1B18BDE; Tue, 10 Mar 2020 14:11:19 +0000 (UTC) Received: from dhcp-25.97.bos.redhat.com (unknown [10.18.25.84]) by smtp.corp.redhat.com (Postfix) with ESMTPS id F265860304; Tue, 10 Mar 2020 14:11:14 +0000 (UTC) From: Aaron Conole To: Ferruh Yigit Cc: Thomas Monjalon , Kevin Traynor , David Marchand , "Ye\, Xiaolong" , "Wang\, Haiyue" , dev , "Zhang\, Qi Z" , "Yang\, Qiming" , "Xing\, Beilei" , "Zhao1\, Wei" , "ci\@dpdk.org" References: <20200309141437.11800-1-haiyue.wang@intel.com> <21697353.6Emhk5qWAg@xps> <8145ace5-7b3e-82fa-95e2-28dc1844459e@intel.com> Date: Tue, 10 Mar 2020 10:11:14 -0400 In-Reply-To: <8145ace5-7b3e-82fa-95e2-28dc1844459e@intel.com> (Ferruh Yigit's message of "Tue, 10 Mar 2020 09:36:42 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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" Ferruh Yigit writes: > On 3/10/2020 7:48 AM, Thomas Monjalon wrote: >> 10/03/2020 03:00, Wang, Haiyue: >>>> -----Original Message----- >>>> From: Kevin Traynor >>>> Sent: Tuesday, March 10, 2020 03:34 >>>> To: Thomas Monjalon ; David Marchand >>>> ; Ye, Xiaolong >>>> >>>> Cc: Wang, Haiyue ; dev ; >>>> Zhang, Qi Z ; Yang, >>>> Qiming ; Xing, Beilei >>>> ; Zhao1, Wei ; >>>> Aaron Conole ; ci@dpdk.org; Yigit, Ferruh >>>> Subject: Re: [dpdk-dev] [PATCH v1 0/4] add Intel DCF PMD support >>>> >>>> On 09/03/2020 17:57, Thomas Monjalon wrote: >>>>> 09/03/2020 17:20, Ye Xiaolong: >>>>>> 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 c= ore 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/1= 52461907 >>>>>>> >>>>>>> Maybe we could add something as an annotation to the cover letter o= r >>>>>>> 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 contai= ns some >>>>>> base tree info including the base commit and dependency patchset inf= o (if any), >>>>>> so the CI can determine the correct base on top of which the develop= er's >>>>>> patchset applies to avoid any apply issue and potential false positi= ve. >>>>>> >>>>>> 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 i= nfo 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), th= e developer >>>>>> applied well-known (on-flight, in the mailing list but not merged ye= t) patches >>>>>> X, Y and Z from somebody else or himself, and then built his three-p= atch series >>>>>> A, B, C, the commit history would be like: >>>>>> >>>>>> ................................................ >>>>>> ---P---X---Y---Z---A---B---C >>>>>> ................................................ >>>>>> >>>>>> With `git format-patch --base=3DP -3 C`, >>>>>> >>>>>> where P could be the exact commit sha, or variants e.g. HEAD~6, we c= an also use >>>>>> --base=3Dauto for convenience, the base tree information block will = be shown at >>>>>> the end of the first message the command outputs (either the first p= atch, 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 depende= ncy patches. >>>>>> >>>>>> >>>>>> With this info in place, I think CI should be able to setup the exac= t 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 patc= hes in >>>>>> patchwork, creating and maintaining such mapping in DB is doable, wh= at do you >>>>>> think? >>>>> >>>>> I think it would simpler to list dependencies as patchwork ids. >>>>> Example: >>>>> =09Depends-on: series-42, patch-12345 >>>>> >>>> >>> >>> Just list the 'series' ? Since it can download the whole patchset with >>> the single link format like: >>> >>> Depends-on: series-8843 --> https://patchwork.dpdk.org/series/8843/mbo= x/ >>=20 >> Yes, I was proposing both format: series-X and patch-Y (on top of series= -X). >> But we probably never need to be specific about a single patch. >> I think you are right, we can keep only "series-X" syntax, >> and allow describing a list of series, ordered and separated with comma. >>=20 > +1 to "Depends-on: series-#####" syntax I can do this - but I actually prefer just putting the series in the brackets. Metadata tags in the message will be preserved in the commit history, but the details of which series to start with for checking out don't really need to be preserved. It's just a way to get the bot to test, right? Maybe it can help maintainers to script an auto-fetch, too.