From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: Helin Zhang <helin.zhang@intel.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 1/3] i40evf: support I40E_VIRTCHNL_OP_CONFIG_VSI_QUEUES_EX in DPDK PF host
Date: Sat, 30 Aug 2014 16:43:15 +0200 [thread overview]
Message-ID: <1897473.c67KeMpIux@xps13> (raw)
In-Reply-To: <1408505611-6959-2-git-send-email-helin.zhang@intel.com>
Hi Helin,
The title mention i40evf but the patch is related to PF (for VF communication).
So I wonder wether it would be clearer to prefix it with i40e? Not sure.
2014-08-20 11:33, Helin Zhang:
> To configure VSI queues for VF, Linux PF host supports
> operation of I40E_VIRTCHNL_OP_CONFIG_VSI_QUEUES with
> limited configurations. To support more configurations
> (e.g configurable CRC stripping in VF), a new operation
> of I40E_VIRTCHNL_OP_CONFIG_VSI_QUEUES_EX has been
> supported in DPDK PF host.
This patch would be easier to read if you could split it in 3 patches:
1) renamings and line wrapping rework
2) introduction of new extended message/operation
3) crc config
> - int ret = I40E_SUCCESS;
> - struct i40e_virtchnl_vsi_queue_config_info *qconfig =
> - (struct i40e_virtchnl_vsi_queue_config_info *)msg;
> - int i;
> - struct i40e_virtchnl_queue_pair_info *qpair;
> -
> - if (msg == NULL || msglen <= sizeof(*qconfig) ||
> - qconfig->num_queue_pairs > vsi->nb_qps) {
> + struct i40e_virtchnl_vsi_queue_config_info *vc_vqci =
> + (struct i40e_virtchnl_vsi_queue_config_info *)msg;
> + struct i40e_virtchnl_queue_pair_info *vc_qpi;
> + struct i40e_virtchnl_queue_pair_extra_info *vc_qpei = NULL;
> + int i, ret = I40E_SUCCESS;
> +
> + if (msg == NULL || msglen <= sizeof(*vc_vqci) ||
> + vc_vqci->num_queue_pairs > vsi->nb_qps) {
> PMD_DRV_LOG(ERR, "vsi_queue_config_info argument wrong\n");
> ret = I40E_ERR_PARAM;
> goto send_msg;
> }
>
> - qpair = qconfig->qpair;
> - for (i = 0; i < qconfig->num_queue_pairs; i++) {
> - if (qpair[i].rxq.queue_id > vsi->nb_qps - 1 ||
> - qpair[i].txq.queue_id > vsi->nb_qps - 1) {
> + vc_qpi = vc_vqci->qpair;
> + if (opcode == I40E_VIRTCHNL_OP_CONFIG_VSI_QUEUES_EX)
> + vc_qpei = (struct i40e_virtchnl_queue_pair_extra_info *)
> + (((uint8_t *)vc_qpi) +
> + (sizeof(struct i40e_virtchnl_queue_pair_info) *
> + vc_vqci->num_queue_pairs));
> +
> + for (i = 0; i < vc_vqci->num_queue_pairs; i++) {
> + if (vc_qpi[i].rxq.queue_id > vsi->nb_qps - 1 ||
> + vc_qpi[i].txq.queue_id > vsi->nb_qps - 1) {
> ret = I40E_ERR_PARAM;
> goto send_msg;
> }
Mixing renaming and new feature makes it difficult to read.
> case I40E_VIRTCHNL_OP_ENABLE_QUEUES:
> PMD_DRV_LOG(INFO, "OP_ENABLE_QUEUES received\n");
> - i40e_pf_host_process_cmd_enable_queues(vf,
> - msg, msglen);
> + i40e_pf_host_process_cmd_enable_queues(vf, msg, msglen);
> break;
> case I40E_VIRTCHNL_OP_DISABLE_QUEUES:
> PMD_DRV_LOG(INFO, "OP_DISABLE_QUEUE received\n");
> - i40e_pf_host_process_cmd_disable_queues(vf,
> - msg, msglen);
> + i40e_pf_host_process_cmd_disable_queues(vf, msg, msglen);
> break;
> case I40E_VIRTCHNL_OP_ADD_ETHER_ADDRESS:
> PMD_DRV_LOG(INFO, "OP_ADD_ETHER_ADDRESS received\n");
> - i40e_pf_host_process_cmd_add_ether_address(vf,
> - msg, msglen);
> + i40e_pf_host_process_cmd_add_ether_address(vf, msg, msglen);
> break;
> case I40E_VIRTCHNL_OP_DEL_ETHER_ADDRESS:
> PMD_DRV_LOG(INFO, "OP_DEL_ETHER_ADDRESS received\n");
> - i40e_pf_host_process_cmd_del_ether_address(vf,
> - msg, msglen);
> + i40e_pf_host_process_cmd_del_ether_address(vf, msg, msglen);
> break;
> case I40E_VIRTCHNL_OP_ADD_VLAN:
> PMD_DRV_LOG(INFO, "OP_ADD_VLAN received\n");
> @@ -932,10 +951,9 @@ i40e_pf_host_handle_vf_msg(struct rte_eth_dev *dev,
> case I40E_VIRTCHNL_OP_FCOE:
> PMD_DRV_LOG(ERR, "OP_FCOE received, not supported\n");
> default:
> - PMD_DRV_LOG(ERR, "%u received, not supported\n",
> - opcode);
> - i40e_pf_host_send_msg_to_vf(vf, opcode,
> - I40E_ERR_PARAM, NULL, 0);
> + PMD_DRV_LOG(ERR, "%u received, not supported\n", opcode);
> + i40e_pf_host_send_msg_to_vf(vf, opcode, I40E_ERR_PARAM,
> + NULL, 0);
> break;
> }
Line wrapping should go in a cleanup patch (like renaming).
Thanks
--
Thomas
next prev parent reply other threads:[~2014-08-30 14:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-20 3:33 [dpdk-dev] [PATCH 0/3] support of configurable CRC stripping in VF Helin Zhang
2014-08-20 3:33 ` [dpdk-dev] [PATCH 1/3] i40evf: support I40E_VIRTCHNL_OP_CONFIG_VSI_QUEUES_EX in DPDK PF host Helin Zhang
2014-08-30 14:43 ` Thomas Monjalon [this message]
2014-09-15 0:21 ` Zhang, Helin
2014-08-20 3:33 ` [dpdk-dev] [PATCH 2/3] i40evf: support I40E_VIRTCHNL_OP_CONFIG_VSI_QUEUES_EX in i40e VF PMD Helin Zhang
2014-08-30 14:52 ` Thomas Monjalon
2014-08-20 3:33 ` [dpdk-dev] [PATCH 3/3] config: remove useless config of CONFIG_RTE_LIBRTE_I40E_PF_DISABLE_STRIP_CRC Helin Zhang
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=1897473.c67KeMpIux@xps13 \
--to=thomas.monjalon@6wind.com \
--cc=dev@dpdk.org \
--cc=helin.zhang@intel.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).