From: Ferruh Yigit <ferruh.yigit@xilinx.com>
To: Chaoyong He <chaoyong.he@corigine.com>
Cc: oss-drivers <oss-drivers@corigine.com>,
Niklas Soderlund <niklas.soderlund@corigine.com>,
"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [PATCH v8 05/12] net/nfp: add flower PF setup logic
Date: Fri, 9 Sep 2022 13:19:27 +0100 [thread overview]
Message-ID: <82a90702-3873-02bd-e804-ba66aad2d0ef@xilinx.com> (raw)
In-Reply-To: <SJ0PR13MB5545F4961279FACA5D8985A59E439@SJ0PR13MB5545.namprd13.prod.outlook.com>
On 9/9/2022 3:36 AM, Chaoyong He wrote:
>> On 9/8/2022 9:44 AM, Chaoyong He wrote:
>>> Adds the vNIC initialization logic for the flower PF vNIC. The flower
>>> firmware exposes this vNIC for the purposes of fallback traffic in the
>>> switchdev use-case.
>>>
>>> Adds minimal dev_ops for this PF device. Because the device is being
>>> exposed externally to DPDK it should also be configured using DPDK
>>> helpers like rte_eth_configure(). For these helpers to work the flower
>>> logic needs to implements a minimal set of dev_ops.
>>>
>>> Signed-off-by: Chaoyong He <chaoyong.he@corigine.com>
>>> Reviewed-by: Niklas Söderlund <niklas.soderlund@corigine.com>
<...>
>>> +static int
>>> +nfp_flower_init_pf_vnic(struct nfp_net_hw *hw) {
>>> + int ret;
>>> + uint16_t i;
>>> + uint16_t n_txq;
>>> + uint16_t n_rxq;
>>> + uint16_t port_id;
>>> + unsigned int numa_node;
>>> + struct rte_mempool *mp;
>>> + struct nfp_pf_dev *pf_dev;
>>> + struct rte_eth_dev *eth_dev;
>>> + struct nfp_app_fw_flower *app_fw_flower;
>>> +
>>> + static const struct rte_eth_conf port_conf = {
>>> + .rxmode = {
>>> + .mq_mode = RTE_ETH_MQ_RX_RSS,
>>> + .offloads = RTE_ETH_RX_OFFLOAD_CHECKSUM,
>>> + },
>>> + .txmode = {
>>> + .mq_mode = RTE_ETH_MQ_TX_NONE,
>>> + },
>>> + };
>>> +
>>> + /* Set up some pointers here for ease of use */
>>> + pf_dev = hw->pf_dev;
>>> + app_fw_flower = NFP_PRIV_TO_APP_FW_FLOWER(pf_dev-
>>> app_fw_priv);
>>> +
>>> + /*
>>> + * Perform the "common" part of setting up a flower vNIC.
>>> + * Mostly reading configuration from hardware.
>>> + */
>>> + ret = nfp_flower_init_vnic_common(hw, "pf_vnic");
>>> + if (ret != 0)
>>> + goto done;
>>> +
>>> + hw->eth_dev = rte_eth_dev_allocate("nfp_pf_vnic");
>>> + if (hw->eth_dev == NULL) {
>>> + ret = -ENOMEM;
>>> + goto done;
>>> + }
>>> +
>>> + /* Grab the pointer to the newly created rte_eth_dev here */
>>> + eth_dev = hw->eth_dev;
>>> +
>>> + numa_node = rte_socket_id();
>>> +
>>> + /* Fill in some of the eth_dev fields */
>>> + eth_dev->device = &pf_dev->pci_dev->device;
>>> + eth_dev->data->dev_private = hw;
>>> +
>>> + /* Create a mbuf pool for the PF */
>>> + app_fw_flower->pf_pktmbuf_pool = nfp_flower_pf_mp_create();
>>> + if (app_fw_flower->pf_pktmbuf_pool == NULL) {
>>> + ret = -ENOMEM;
>>> + goto port_release;
>>> + }
>>> +
>>> + mp = app_fw_flower->pf_pktmbuf_pool;
>>> +
>>> + /* Add Rx/Tx functions */
>>> + eth_dev->dev_ops = &nfp_flower_pf_vnic_ops;
>>> +
>>> + /* PF vNIC gets a random MAC */
>>> + eth_dev->data->mac_addrs = rte_zmalloc("mac_addr",
>> RTE_ETHER_ADDR_LEN, 0);
>>> + if (eth_dev->data->mac_addrs == NULL) {
>>> + ret = -ENOMEM;
>>> + goto mempool_cleanup;
>>> + }
>>> +
>>> + rte_eth_random_addr(eth_dev->data->mac_addrs->addr_bytes);
>>> + rte_eth_dev_probing_finish(eth_dev);
>>> +
>>> + /* Configure the PF device now */
>>> + n_rxq = hw->max_rx_queues;
>>> + n_txq = hw->max_tx_queues;
>>> + port_id = hw->eth_dev->data->port_id;
>>> +
>>> + ret = rte_eth_dev_configure(port_id, n_rxq, n_txq, &port_conf);
>>
>> Still not sure about PMD calling 'rte_eth_dev_configure()', can you please
>> give more details on what specific configuration is expected with that call?
>
> The main configuration we need is the number of rx/tx queue.
> So we should use the internal api `eth_dev_rx/tx_queue_config` to instead?
>
nb_rx_q/nb_tx_q are parameters provided by user (via
rte_eth_dev_configure()), won't is wrong for PMD to set a value on its own?
Why nb_rx_q/nb_tx_q are required in the probe() stage? Probe stage is
not to configure the device.
next prev parent reply other threads:[~2022-09-09 12:19 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
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 [this message]
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=82a90702-3873-02bd-e804-ba66aad2d0ef@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).