| Message ID | 20200309141437.11800-1-haiyue.wang@intel.com (mailing list archive) |
|---|---|
| Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 5C127A052E; Mon, 9 Mar 2020 15:22:25 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C61A51C068; Mon, 9 Mar 2020 15:22:24 +0100 (CET) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 74D602BE6 for <dev@dpdk.org>; Mon, 9 Mar 2020 15:22:22 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Mar 2020 07:22:21 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,533,1574150400"; d="scan'208";a="235704299" Received: from npg-dpdk-haiyue-1.sh.intel.com ([10.67.119.213]) by orsmga008.jf.intel.com with ESMTP; 09 Mar 2020 07:22:19 -0700 From: Haiyue Wang <haiyue.wang@intel.com> To: dev@dpdk.org, xiaolong.ye@intel.com, qi.z.zhang@intel.com, qiming.yang@intel.com, beilei.xing@intel.com Cc: wei.zhao1@intel.com, Haiyue Wang <haiyue.wang@intel.com> Date: Mon, 9 Mar 2020 22:14:33 +0800 Message-Id: <20200309141437.11800-1-haiyue.wang@intel.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: [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 <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
| Series | add Intel DCF PMD support | |
Message
Wang, Haiyue
March 9, 2020, 2:14 p.m. UTC
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 And it needs the coming iavf common lib update to compile, the modified ice flow function to work. Haiyue Wang (4): net/iavf: stop the PCI probe in DCF mode net/ice: export the DDP definition symbols net/ice: add the DCF framework doc: add release notes for Intel ice PMD doc/guides/nics/ice.rst | 47 ++ doc/guides/nics/img/ice_dcf.png | Bin 0 -> 39168 bytes doc/guides/rel_notes/release_20_05.rst | 5 + drivers/common/Makefile | 1 + drivers/net/iavf/iavf_ethdev.c | 41 ++ drivers/net/ice/Makefile | 6 + drivers/net/ice/ice_dcf.c | 651 +++++++++++++++++++++++++ drivers/net/ice/ice_dcf.h | 61 +++ drivers/net/ice/ice_dcf_ethdev.c | 319 ++++++++++++ drivers/net/ice/ice_dcf_ethdev.h | 33 ++ drivers/net/ice/ice_dcf_parent.c | 348 +++++++++++++ drivers/net/ice/ice_ethdev.c | 9 +- drivers/net/ice/ice_ethdev.h | 8 + drivers/net/ice/meson.build | 8 +- mk/rte.app.mk | 1 + 15 files changed, 1528 insertions(+), 10 deletions(-) create mode 100644 doc/guides/nics/img/ice_dcf.png create mode 100644 drivers/net/ice/ice_dcf.c create mode 100644 drivers/net/ice/ice_dcf.h create mode 100644 drivers/net/ice/ice_dcf_ethdev.c create mode 100644 drivers/net/ice/ice_dcf_ethdev.h create mode 100644 drivers/net/ice/ice_dcf_parent.c
Comments
On Mon, Mar 9, 2020 at 3:22 PM Haiyue Wang <haiyue.wang@intel.com> 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?
Hi, David On 03/09, David Marchand wrote: >On Mon, Mar 9, 2020 at 3:22 PM Haiyue Wang <haiyue.wang@intel.com> 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 >
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 <haiyue.wang@intel.com> 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? I think it would simpler to list dependencies as patchwork ids. Example: Depends-on: series-42, patch-12345
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 <haiyue.wang@intel.com> 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? > > I think it would simpler to list dependencies as patchwork ids. > Example: > Depends-on: series-42, patch-12345 > +1. I don't think it should depend on a base-commit. If it doesn't apply/build/work with the latest upstream code then it's a valid error. >
> -----Original Message----- > From: Kevin Traynor <ktraynor@redhat.com> > Sent: Tuesday, March 10, 2020 03:34 > To: Thomas Monjalon <thomas@monjalon.net>; David Marchand <david.marchand@redhat.com>; Ye, Xiaolong > <xiaolong.ye@intel.com> > Cc: Wang, Haiyue <haiyue.wang@intel.com>; dev <dev@dpdk.org>; Zhang, Qi Z <qi.z.zhang@intel.com>; Yang, > Qiming <qiming.yang@intel.com>; Xing, Beilei <beilei.xing@intel.com>; Zhao1, Wei <wei.zhao1@intel.com>; > Aaron Conole <aconole@redhat.com>; ci@dpdk.org; Yigit, Ferruh <ferruh.yigit@intel.com> > 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 <haiyue.wang@intel.com> 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? > > > > I think it would simpler to list dependencies as patchwork ids. > > Example: > > Depends-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/mbox/ > +1. I don't think it should depend on a base-commit. If it doesn't > apply/build/work with the latest upstream code then it's a valid error. > > >
10/03/2020 03:00, Wang, Haiyue: > > -----Original Message----- > > From: Kevin Traynor <ktraynor@redhat.com> > > Sent: Tuesday, March 10, 2020 03:34 > > To: Thomas Monjalon <thomas@monjalon.net>; David Marchand <david.marchand@redhat.com>; Ye, Xiaolong > > <xiaolong.ye@intel.com> > > Cc: Wang, Haiyue <haiyue.wang@intel.com>; dev <dev@dpdk.org>; Zhang, Qi Z <qi.z.zhang@intel.com>; Yang, > > Qiming <qiming.yang@intel.com>; Xing, Beilei <beilei.xing@intel.com>; Zhao1, Wei <wei.zhao1@intel.com>; > > Aaron Conole <aconole@redhat.com>; ci@dpdk.org; Yigit, Ferruh <ferruh.yigit@intel.com> > > 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 <haiyue.wang@intel.com> 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? > > > > > > I think it would simpler to list dependencies as patchwork ids. > > > Example: > > > Depends-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/mbox/ 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.
On 3/10/2020 7:48 AM, Thomas Monjalon wrote: > 10/03/2020 03:00, Wang, Haiyue: >>> -----Original Message----- >>> From: Kevin Traynor <ktraynor@redhat.com> >>> Sent: Tuesday, March 10, 2020 03:34 >>> To: Thomas Monjalon <thomas@monjalon.net>; David Marchand <david.marchand@redhat.com>; Ye, Xiaolong >>> <xiaolong.ye@intel.com> >>> Cc: Wang, Haiyue <haiyue.wang@intel.com>; dev <dev@dpdk.org>; Zhang, Qi Z <qi.z.zhang@intel.com>; Yang, >>> Qiming <qiming.yang@intel.com>; Xing, Beilei <beilei.xing@intel.com>; Zhao1, Wei <wei.zhao1@intel.com>; >>> Aaron Conole <aconole@redhat.com>; ci@dpdk.org; Yigit, Ferruh <ferruh.yigit@intel.com> >>> 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 <haiyue.wang@intel.com> 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? >>>> >>>> I think it would simpler to list dependencies as patchwork ids. >>>> Example: >>>> Depends-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/mbox/ > > 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. > +1 to "Depends-on: series-#####" syntax
David Marchand <david.marchand@redhat.com> writes: > On Mon, Mar 9, 2020 at 3:22 PM Haiyue Wang <haiyue.wang@intel.com> 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? It's something that's possibly worth doing; I can update the bot to recognize: series_XXX in the cover-letter metadata (IE: between the '[...]'), and automatically check out the correct branch. Additionally, if the idea is not to get the patch applied right away while finalizing on the preceding series, the RFC keyword will prevent the bot from running. THAT SAID In general, I dislike posting series that depend on other series. It makes review much harder, and if there's a feedback on the preceding series that requires lots of change, the dependent series may also need to be re-done completely. I see there are more replies to this thread - sorry I didn't get to it yesterday (personal stuff).
Ferruh Yigit <ferruh.yigit@intel.com> writes: > On 3/10/2020 7:48 AM, Thomas Monjalon wrote: >> 10/03/2020 03:00, Wang, Haiyue: >>>> -----Original Message----- >>>> From: Kevin Traynor <ktraynor@redhat.com> >>>> Sent: Tuesday, March 10, 2020 03:34 >>>> To: Thomas Monjalon <thomas@monjalon.net>; David Marchand >>>> <david.marchand@redhat.com>; Ye, Xiaolong >>>> <xiaolong.ye@intel.com> >>>> Cc: Wang, Haiyue <haiyue.wang@intel.com>; dev <dev@dpdk.org>; >>>> Zhang, Qi Z <qi.z.zhang@intel.com>; Yang, >>>> Qiming <qiming.yang@intel.com>; Xing, Beilei >>>> <beilei.xing@intel.com>; Zhao1, Wei <wei.zhao1@intel.com>; >>>> Aaron Conole <aconole@redhat.com>; ci@dpdk.org; Yigit, Ferruh <ferruh.yigit@intel.com> >>>> 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 <haiyue.wang@intel.com> 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? >>>>> >>>>> I think it would simpler to list dependencies as patchwork ids. >>>>> Example: >>>>> Depends-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/mbox/ >> >> 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. >> > +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.