From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Yong Wang <yongwang@vmware.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v3] net/kni: add KNI PMD
Date: Fri, 4 Nov 2016 12:21:32 +0000 [thread overview]
Message-ID: <afaa670f-c646-b8f2-3561-0d1679b43af8@intel.com> (raw)
In-Reply-To: <BY2PR05MB2359471CAB7D494E39CFEE56AFA30@BY2PR05MB2359.namprd05.prod.outlook.com>
Hi Yong,
Thank you for the review.
On 11/3/2016 1:24 AM, Yong Wang wrote:
>> -----Original Message-----
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ferruh Yigit
>> Sent: Monday, October 10, 2016 6:20 AM
>> To: dev@dpdk.org
>> Cc: Ferruh Yigit <ferruh.yigit@intel.com>
>> Subject: [dpdk-dev] [PATCH v3] net/kni: add KNI PMD
>>
>> Add KNI PMD which wraps librte_kni for ease of use.
>>
>> KNI PMD can be used as any regular PMD to send / receive packets to the
>> Linux networking stack.
>>
>> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
>> ---
>>
>> v3:
>> * rebase on top of latest master
>>
>> v2:
>> * updated driver name eth_kni -> net_kni
>> ---
<...>
>> CONFIG_RTE_LIBRTE_KNI=n
>> +CONFIG_RTE_LIBRTE_PMD_KNI=n
>
> Nit: change this to CONFIG_RTE_LIBRTE_KNI_PMD instead to be consistent with all other pmds.
There is an inconsistency between virtual and physical PMD config options.
Physical ones: xxx_PMD=
*IXGBE_PMD, *I40E_PMD, *ENA_PMD, ...
Virtual ones: PMD_xxx=
*PMD_RING, *PMD_PCAP, *PMD_NULL, ...
So I am consistent with inconsistency J
<...>
>> +#define DRV_NAME net_kni
>
> The name generated this way is not consistent with other vdevs. Why not simply assign "KNI PMD" to drv_name?
Right, it is not consistent but intentionaly.
With macro RTE_PMD_REGISTER_VDEV(net_kni, xxx), rte_driver.name set to
"net_kni"
and if you set drivername to "KNI PMD", pmd will report driver name as
"KNI PMD"
so there will be two different driver names, I tried to unify them to a
single name.
And some physical drivers already does same thing.
<...>
>> +static uint16_t
>> +eth_kni_rx(void *q, struct rte_mbuf **bufs, uint16_t nb_bufs)
>> +{
>> + struct pmd_queue *kni_q = q;
>> + struct rte_kni *kni = kni_q->internals->kni;
>> + uint16_t nb_pkts;
>> +
>> + nb_pkts = rte_kni_rx_burst(kni, bufs, nb_bufs);
>> +
>> + kni_q->rx.pkts += nb_pkts;
>> + kni_q->rx.err_pkts += nb_bufs - nb_pkts;
>> +
>> + return nb_pkts;
>> +}
>> +
>
> I don't think it's safe to do receive from two queues concurrently on two cores sharing the same underlying KNI device due to the current limitation of KNI user-space queues not being multi-thread safe.
You are right, above code is not safe.
It is possible to create a KNI interface per queue, but I don't see any
advantage of this against creating a new virtual KNI port.
So I will limit to single queue.
> Is the proposed plan to have the application layer implement
synchronization logic?
> If that's the case, it needs to be clearly documented and depending on
the implementation, measurable overhead will be incurred.
> Otherwise (only single-queue supported), could you check queue number
if the application tries to configure multi-queue?
>
<...>
>> +static struct rte_eth_dev *
>> +eth_kni_create(const char *name, unsigned int numa_node)
>> +{
>> + struct pmd_internals *internals = NULL;
>> + struct rte_eth_dev_data *data;
>> + struct rte_eth_dev *eth_dev;
>> + uint16_t nb_rx_queues = 1;
>> + uint16_t nb_tx_queues = 1;
>
> Since these two values are always 1 here, I think they could be removed.
I will remove them.
Thanks,
ferruh
next prev parent reply other threads:[~2016-11-04 12:21 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-06 10:33 [dpdk-dev] [PATCH] " Ferruh Yigit
2016-09-08 7:44 ` Thomas Monjalon
2016-09-08 9:25 ` Bruce Richardson
2016-09-08 9:38 ` Thomas Monjalon
2016-09-08 18:11 ` Ferruh Yigit
2016-09-09 7:36 ` Thomas Monjalon
2016-09-16 11:29 ` [dpdk-dev] [PATCH v2] " Ferruh Yigit
2016-10-10 13:19 ` [dpdk-dev] [PATCH v3] " Ferruh Yigit
2016-11-03 1:24 ` Yong Wang
2016-11-04 12:21 ` Ferruh Yigit [this message]
2016-11-30 18:12 ` [dpdk-dev] [PATCH v4] " Ferruh Yigit
2016-12-12 21:59 ` Yong Wang
2016-12-14 15:59 ` Ferruh Yigit
2016-12-14 19:25 ` Yong Wang
2016-12-15 15:55 ` Ferruh Yigit
2016-12-19 17:52 ` Yong Wang
2017-01-30 16:57 ` [dpdk-dev] [PATCH v5] " Ferruh Yigit
2017-01-30 19:05 ` Yong Wang
2017-01-30 19:43 ` Ferruh Yigit
2017-01-30 20:09 ` [dpdk-dev] [PATCH v6] " Ferruh Yigit
2017-01-30 21:15 ` [dpdk-dev] [PATCH v7] " Ferruh Yigit
2017-01-31 12:18 ` [dpdk-dev] [PATCH v8] " Ferruh Yigit
2017-02-17 13:42 ` [dpdk-dev] [PATCH v9] " Ferruh Yigit
2017-02-17 13:47 ` Thomas Monjalon
2017-02-17 14:00 ` Eelco Chaudron
2017-02-17 14:29 ` Ferruh Yigit
2017-02-17 14:57 ` Bruce Richardson
2017-02-17 17:52 ` Yong Wang
2017-02-17 22:37 ` Thomas Monjalon
2017-02-20 12:54 ` Ferruh Yigit
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=afaa670f-c646-b8f2-3561-0d1679b43af8@intel.com \
--to=ferruh.yigit@intel.com \
--cc=dev@dpdk.org \
--cc=yongwang@vmware.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).