From: Yuanhan Liu <yuanhan.liu@linux.intel.com>
To: Huawei Xie <huawei.xie@intel.com>
Cc: dev@dpdk.org
Subject: Re: [PATCH] virtio: split virtio rx/tx queue
Date: Fri, 27 May 2016 17:07:56 +0800 [thread overview]
Message-ID: <20160527090756.GC5641@yliu-dev.sh.intel.com> (raw)
In-Reply-To: <1464097112-47411-1-git-send-email-huawei.xie@intel.com>
On Tue, May 24, 2016 at 09:38:32PM +0800, Huawei Xie wrote:
> vq->vq_ring_mem = mz->phys_addr;
> vq->vq_ring_virt_mem = mz->addr;
> - PMD_INIT_LOG(DEBUG, "vq->vq_ring_mem: 0x%"PRIx64, (uint64_t)mz->phys_addr);
> - PMD_INIT_LOG(DEBUG, "vq->vq_ring_virt_mem: 0x%"PRIx64, (uint64_t)(uintptr_t)mz->addr);
> - vq->virtio_net_hdr_mz = NULL;
> - vq->virtio_net_hdr_mem = 0;
> + PMD_INIT_LOG(DEBUG, "vq->vq_ring_mem: 0x%"PRIx64,
> + (uint64_t)mz->phys_addr);
> + PMD_INIT_LOG(DEBUG, "vq->vq_ring_virt_mem: 0x%"PRIx64,
> + (uint64_t)(uintptr_t)mz->addr);
> +
> + hdr_mz = rte_memzone_reserve_aligned(vq_hdr_name, sz_hdr_mz, socket_id,
> + 0, RTE_CACHE_LINE_SIZE);
We don't need allocate hdr_mz for Rx queue, and in such case, sz_hdr_mz
is 0. I'm wondering what hdr_mz would be then, NULL?
Anyway, you should skip the hdr_mz allocation for Rx queue, and I also
would suggest you to move the vq_hdr_name setup here.
> + if (hdr_mz == NULL) {
> + if (rte_errno == EEXIST)
> + hdr_mz = rte_memzone_lookup(vq_hdr_name);
> + if (hdr_mz == NULL) {
> + ret = -ENOMEM;
> + goto fail_q_alloc;
> + }
> + }
>
...
>
> PMD_INIT_FUNC_TRACE();
> ret = virtio_dev_queue_setup(dev, VTNET_CQ, VTNET_SQ_CQ_QUEUE_IDX,
> - vtpci_queue_idx, 0, socket_id, &vq);
> + vtpci_queue_idx, 0, socket_id, (void **)&cvq);
Unnecessary cast. Note that there are few others like that in this
patch.
> - PMD_RX_LOG(DEBUG, "dequeue:%d", num);
> - PMD_RX_LOG(DEBUG, "packet len:%d", len[0]);
> + PMD_RX_LOG(DEBUG, "dequeue:%d\n", num);
> + PMD_RX_LOG(DEBUG, "packet len:%d\n", len[0]);
We should not append "\n" for PMD_RX_LOG; this macro alreadys does it.
Another note is that you might want to run checkpatch; I saw quite many
warnings.
--yliu
next prev parent reply other threads:[~2016-05-27 9:05 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-04 0:50 [PATCH] virtio: split virtio rx/tx queue Huawei Xie
2016-05-05 0:03 ` Yuanhan Liu
2016-05-05 1:54 ` Xie, Huawei
2016-05-05 3:07 ` Yuanhan Liu
2016-05-05 3:29 ` Xie, Huawei
2016-05-05 3:50 ` Yuanhan Liu
2016-05-05 5:29 ` Xie, Huawei
2016-05-09 5:14 ` Yuanhan Liu
2016-05-09 5:44 ` Xie, Huawei
2016-05-09 16:02 ` Yuanhan Liu
2016-05-24 13:38 ` Huawei Xie
2016-05-25 10:07 ` Thomas Monjalon
2016-05-25 15:01 ` Xie, Huawei
2016-05-27 9:07 ` Yuanhan Liu [this message]
2016-05-30 2:40 ` Xie, Huawei
2016-05-30 3:03 ` Yuanhan Liu
2016-05-30 8:17 ` Xie, Huawei
2016-05-30 9:06 ` [PATCH v3] " Huawei Xie
2016-06-01 7:15 ` Yuanhan Liu
2016-06-02 6:38 ` Xie, Huawei
2016-06-02 6:43 ` Yuanhan Liu
2016-06-01 16:12 ` Huawei Xie
2016-06-02 8:09 ` Xie, Huawei
2016-06-03 2:53 ` Yuanhan Liu
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=20160527090756.GC5641@yliu-dev.sh.intel.com \
--to=yuanhan.liu@linux.intel.com \
--cc=dev@dpdk.org \
--cc=huawei.xie@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.