From: Ferruh Yigit <ferruh.yigit@xilinx.com>
To: Chaoyong He <chaoyong.he@corigine.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 13:13:21 +0100 [thread overview]
Message-ID: <d801dd5e-9068-4107-7e60-f551961476d4@xilinx.com> (raw)
In-Reply-To: <SJ0PR13MB55458C9F6788D9F65D1D0A079E439@SJ0PR13MB5545.namprd13.prod.outlook.com>
On 9/9/2022 6:43 AM, Chaoyong He wrote:
>>> 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?
>>
> Oh, sorry, I understand now.
> I misspelled 'app_fw' to 'app_hw' in some place, I'll revise and check it.
ack
next prev parent reply other threads:[~2022-09-09 12:13 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
2022-09-09 5:43 ` Chaoyong He
2022-09-09 12:13 ` Ferruh Yigit [this message]
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=d801dd5e-9068-4107-7e60-f551961476d4@xilinx.com \
--to=ferruh.yigit@xilinx.com \
--cc=chaoyong.he@corigine.com \
--cc=dev@dpdk.org \
--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).