From: Chaoyong He <chaoyong.he@corigine.com>
To: Ferruh Yigit <ferruh.yigit@xilinx.com>, "dev@dpdk.org" <dev@dpdk.org>
Cc: oss-drivers <oss-drivers@corigine.com>,
Niklas Soderlund <niklas.soderlund@corigine.com>
Subject: RE: [PATCH v8 01/12] net/nfp: move app specific attributes to own struct
Date: Fri, 9 Sep 2022 01:49:27 +0000 [thread overview]
Message-ID: <SJ0PR13MB55453951FA73865432E693959E439@SJ0PR13MB5545.namprd13.prod.outlook.com> (raw)
In-Reply-To: <56767658-8756-e1ba-77d4-c6f5fd2fd118@xilinx.com>
> On 9/8/2022 9:44 AM, Chaoyong He wrote:
> > The NFP card can load different firmware applications. Currently only
> > the CoreNIC application is supported. This commit makes needed
> > infrastructure changes in order to support other firmware applications
> > too.
> >
> > Clearer separation is made between the PF device and any application
> > specific concepts. The PF struct is now generic regardless of the
> > application loaded. A new struct is also made for the CoreNIC
> > application. Future additions to support other applications should
> > also add an applications specific struct.
> >
>
> What do you think to replace 'application' usage in the commit log with
> 'application firmware'?
>
> <...>
>
> > diff --git a/drivers/net/nfp/nfp_ethdev.c
> > b/drivers/net/nfp/nfp_ethdev.c index e9d01f4..bd9cf67 100644
> > --- a/drivers/net/nfp/nfp_ethdev.c
> > +++ b/drivers/net/nfp/nfp_ethdev.c
> > @@ -39,15 +39,15 @@
> > #include "nfp_cpp_bridge.h"
> >
> > static int
> > -nfp_net_pf_read_mac(struct nfp_pf_dev *pf_dev, int port)
> > +nfp_net_pf_read_mac(struct nfp_app_fw_nic *app_hw_nic, int port)
>
> Is this intentional that struct name is 'nfp_app_fw_nic' but variable name is
> 'app_hw_nic'? Why is app_fw vs app_hw difference?
>
Sorry, I'm not quite sure I catch your doubt.
Do you mean I should just use `app_hw` as variable name if the function only
process one type of the application firmware?
> <...>
>
> > @@ -890,27 +937,12 @@
> > }
> >
> > /* Populate the newly created PF device */
> > + pf_dev->app_fw_id = app_hw_id;
>
> ditto.
Our PMD driver can support two different application firmwares now.
We get the application firmware's type from the firmware in the probe function,
and store it in the structure of pf device. Then we can invoke different initialization
logics according to the application firmware's type.
We have a `structure nfp_pf_dev`, which is used to store the common information.
We defined a structure for each type of application firmware to keep the specific information.
The `structure nfp_pf_dev` has a `void *app_fw_priv` filed, which can point to different structure
based on the type of application firmware.
So, what you mean is we need not store it in the structure of pf device as no other logics
out of this function will use it?
next prev parent reply other threads:[~2022-09-09 1:49 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-08 8:44 [PATCH v8 00/12] preparation for the rte_flow offload of nfp PMD Chaoyong He
2022-09-08 8:44 ` [PATCH v8 01/12] net/nfp: move app specific attributes to own struct Chaoyong He
2022-09-08 16:24 ` Ferruh Yigit
2022-09-09 1:49 ` Chaoyong He [this message]
2022-09-09 5:43 ` Chaoyong He
2022-09-09 12:13 ` Ferruh Yigit
2022-09-08 8:44 ` [PATCH v8 02/12] net/nfp: simplify initialization and remove dead code Chaoyong He
2022-09-08 8:44 ` [PATCH v8 03/12] net/nfp: move app specific init logic to own function Chaoyong He
2022-09-08 8:44 ` [PATCH v8 04/12] net/nfp: add initial flower firmware support Chaoyong He
2022-09-08 16:24 ` Ferruh Yigit
2022-09-08 8:44 ` [PATCH v8 05/12] net/nfp: add flower PF setup logic Chaoyong He
2022-09-08 16:24 ` Ferruh Yigit
2022-09-09 2:36 ` Chaoyong He
2022-09-09 12:13 ` Ferruh Yigit
2022-09-14 9:20 ` Thomas Monjalon
2022-09-09 12:19 ` Ferruh Yigit
2022-09-13 6:51 ` Chaoyong He
2022-09-13 9:08 ` Ferruh Yigit
2022-09-14 1:23 ` Chaoyong He
2022-09-14 9:25 ` Thomas Monjalon
2022-09-08 8:44 ` [PATCH v8 06/12] net/nfp: add flower PF related routines Chaoyong He
2022-09-08 8:44 ` [PATCH v8 07/12] net/nfp: add flower ctrl VNIC related logics Chaoyong He
2022-09-08 8:44 ` [PATCH v8 08/12] net/nfp: move common rxtx function for flower use Chaoyong He
2022-09-08 8:44 ` [PATCH v8 09/12] net/nfp: add flower ctrl VNIC rxtx logic Chaoyong He
2022-09-08 8:45 ` [PATCH v8 10/12] net/nfp: add flower representor framework Chaoyong He
2022-09-08 8:45 ` [PATCH v8 11/12] net/nfp: move rxtx function to header file Chaoyong He
2022-09-08 8:45 ` [PATCH v8 12/12] net/nfp: add flower PF rxtx logic Chaoyong He
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=SJ0PR13MB55453951FA73865432E693959E439@SJ0PR13MB5545.namprd13.prod.outlook.com \
--to=chaoyong.he@corigine.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@xilinx.com \
--cc=niklas.soderlund@corigine.com \
--cc=oss-drivers@corigine.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).