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 DAF3FA053A; Wed, 5 Aug 2020 10:52:19 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id CDCF01BFF7; Wed, 5 Aug 2020 10:52:18 +0200 (CEST) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [207.211.31.81]) by dpdk.org (Postfix) with ESMTP id 772FCE07 for ; Wed, 5 Aug 2020 10:52:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1596617536; 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=gbtjTaIYlto1/zzMaes3p6IFqjKhjPwL47lIXQ+vyVc=; b=aRBWuHfyc6/iwP2QEqzZN42iZo0yUmhLUrv1fPw4YUxqZPSj5CqWwW6VBgzdfyqXgd2j4H L5fRUrmdUWb6HtblsHNxgIlgWmsmAmFtB4bxSkJzMWuvnRGyGMCjVOr/NhMD3FdWTh3VaW L8/fCTcKiDMxmIxfstVZd8jFZlTOY38= Received: from mail-oi1-f197.google.com (mail-oi1-f197.google.com [209.85.167.197]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-291-oGP34LQCPj6nUuHbjQI-ww-1; Wed, 05 Aug 2020 04:52:14 -0400 X-MC-Unique: oGP34LQCPj6nUuHbjQI-ww-1 Received: by mail-oi1-f197.google.com with SMTP id 17so1632956oij.19 for ; Wed, 05 Aug 2020 01:52:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=gbtjTaIYlto1/zzMaes3p6IFqjKhjPwL47lIXQ+vyVc=; b=sdyIOUalmJfHMVhT6esTK/X1UuaBMJZcNSK3fS9LrgoEpmEIfKPJTaz9sa+14K5b12 UhMRImRuW5ZSK1mmDkLDyNm4Wtmq39t8o8ywY0bGkKmGtFoO914pBZOC+j/6lYCMWh+6 XDyZBHBhH3dN9AI02O9NgJXjHBWf2paYMcG8q/59tWsCo5ne9RufyiXUR2kpGsDe0Cwc 8iZEqC/NNRia0SWa/+BV7bGnl4m03TziaklQAwtQ5H1oxLRhE94BAd+SZUKLxivcyGqQ hs6w9Ej35CoXtPb6Z/fz2Cp7hYsSgdFZ7VnOOhZ2BeUXNWtpWAs7DR6yGVDVYI6ncxwy 3j2w== X-Gm-Message-State: AOAM532VOvdsXeuvpq4sTR1hDM4hHXbVx0C4LULYSVqB8Yk8sZ0n9lEj JRRPwfBkO8UkHy1pvQDyfQD9Itju7xz4FUvCuVwGRcoLAytVMpYAa4/b9avrlIzVplN1J+M8srk K13RKQCKBhA19bRV7gO8= X-Received: by 2002:a9d:3df5:: with SMTP id l108mr1786118otc.369.1596617533872; Wed, 05 Aug 2020 01:52:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxI5bh57YxXCkjA8paG5rP2VY2mC2IGQxw1LDBXgCqlMsy7K2c3bHga17aIdLwC8AGqPtQRj13NIughCRFE/cI= X-Received: by 2002:a9d:3df5:: with SMTP id l108mr1786104otc.369.1596617533555; Wed, 05 Aug 2020 01:52:13 -0700 (PDT) MIME-Version: 1.0 References: <1594930811-12873-1-git-send-email-nicolas.chautru@intel.com> <1594930811-12873-2-git-send-email-nicolas.chautru@intel.com> <18daf845-298b-43c9-2e2a-316d64cec9fd@redhat.com> In-Reply-To: From: David Marchand Date: Wed, 5 Aug 2020 10:51:48 +0200 Message-ID: To: "Chautru, Nicolas" , Maxime Coquelin Cc: "dev@dpdk.org" , "akhil.goyal@nxp.com" , "thomas@monjalon.net" , "Richardson, Bruce" X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [20.11, PATCH v2] baseband/fpga_5gnr_fec: add companion PF config App 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" Hello Nicolas, Maxime, On Tue, Aug 4, 2020 at 10:49 AM Maxime Coquelin wrote: > >>>> One question I have is whether this is the tool itself that has a > >>>> dependency on the PMD, or just the config file? > >>> > >>> Each PMD directory would have its own version of the companion PF > >> config application. > >>> Ie. the patch above is only for baseband/fpga_5gnr_fec ie. Intel Vist= a Creek > >> with 5G LDPC user image. > >> > >> OK. Does it mean the same application and configuration will work for > >> baseband/fpga_5gnr_fec PMD versions v20.11, v21.02, v21.05, etc, ...? > >> > >> If not, is there a way for the PMD driver to detect whether a wrong > >> configuration was applied? Something like checking the FW version of a= NIC > >> is supported by the PMD driver. > >> > > > > As mentioned above there is no API between the 2 config-app companion a= nd BBDEV/DPDK, as they belong logically to 2 different entities (possibly c= ontainers) without shared interface except indirectly through HW. > > There is no strict API which could be broken between the 2, but purely = 2 SW ingredients that ideally should be aligned to avoid discrepancy during= deployment or validation. > > To answer your question I don't foresee a specific case right now causi= ng a strict loss of functional compatibility. > > > > Note that the configure function being used within config-app already e= xists right now within the DPDK PMD : ie. that function is the one being ex= posed by PMD and used when running bbdev-test in DPDK for PF. The limitatio= n being that this is only used when running *within DPDK and from PF*, whic= h is not the deployment use case ie. when DPDK is on the VF only, and PF on= ly performs HW configuration without DPDK dependency (apologize for repeati= ng). I am naively thinking that the bitstream + this configuration are a whole for a given usecase and should be loaded as a single step. A bit like how vendors provide ready-to-use firmwares on their nics. Leaving the users with the possibility to load whatever config they write is scary. When hitting an init issue, application crash etc... in a customer env, how will we know the configuration is actually what it should be? > > OK, got it. > > > You can see 'fpga_write_config()' in the current patchset which does ma= tch line-for-line with 'fpga_5gnr_fec_configure()' already in the PMD on DP= DK main branch. Virtually the same code really with same config input struc= ture 'fpga_5gnr_fec_conf' and same registers being written to. > > Difference being that the former implementation is formally integrated = in DPDK while the other (config app companion in same directory) has no DPD= K dependency. That's it. > > There is concern in having these 2 different implementations of the sam= e initialization sequence diverging (a fix to a register setting would need= to be applied on both repositories with different versioning) and splittin= g the HW support into multiple repos, hence my personal preference to keep = everything in one place. > > I understand it would be easier for you. > Maybe an alternative would be to have a simple DPDK application that > uses the PMD driver on the PF just for the initialization. Doing that, > you would not even have to duplicate the config part between the PMD > driver and the application, and you would have a single config app for > every cards and bitstreams. It would also mean you get rid off the > external dependency on inih library. > > > As stated from the beginning I personally see pros and cons on both sid= es, all in all DPDK arguably being cleaner to me for the reasons above. > > Still the most important is that it needs to make sense and be valuable= to DPDK. > > Based on latest feedback from Maxime and Thomas, I believe this is now = trending towards being preferred outside of DPDK. If you can confirm by ema= il then that is fine and I will just abandon this ticket so that we can con= sider alternate options and split this into different repos. > > In its current form, this is a nack for me. I would prefer either having > it outside of DPDK, or having a DPDK application calling the PMD > driver init. This is a nack from me too. About having a DPDK application calling the PMD driver init. This requires to have a DPDK application from version X touching the hw in the host, while a guest could be running DPDK version Y. This will result in ping/pong when the support on the host and guest sides is done by two different teams. Thanks. --=20 David Marchand