[dpdk-dev] DPDK Support for the i217 ?
Palin, Support for the i217 will be available in the Intel DPDK version 1.7. I?m not sure of the timeline, but next release. Gerald On 1/30/14, 10:59 AM, "Palin, Francois" wrote: >Hi all, > >We would like to know if DPDK support for the i217 will be provided >anytime soon. >The Supported NICs list does't show the i217. Intel DPDK Release Notes >don't >mention the i217 either. > >Thank you ! > >Fran?ois Palin >
[dpdk-dev] DPDK Support for the i217 ?
Hi all, We would like to know if DPDK support for the i217 will be provided anytime soon. The Supported NICs list does't show the i217. Intel DPDK Release Notes don't mention the i217 either. Thank you ! Fran?ois Palin
[dpdk-dev] Selecting Linux distribution for DPDK applications: CentOS or Debian
Hi Dan, We are also using Debian 7.3, from the DPDK v1.3.1 up to version 1.5.1r1. it works completely fine. regards, - Hamed On Thu, Jan 30, 2014 at 3:40 PM, Daniel Kaminsky < daniel.kaminsky at infinitelocality.com> wrote: > We're using CentOS 6.5 and Ubuntu 12.04 and don't see any issue with both > of them. > > Regards, > Daniel Kaminsky > > > On Thu, Jan 30, 2014 at 12:12 PM, Prashant Upadhyaya < > prashant.upadhyaya at aricent.com> wrote: > > > Hi Dan, > > > > Intel DPDK release notes(1.5.2) mention the following tested OS -- > > * Fedora release 18 > > * Ubuntu* 12.04 LTS > > * Wind River* Linux* 5 > > * Red Hat* Enterprise Linux 6.3 > > * SUSE Enterprise Linux* 11 SP2 > > > > I have personally used Fedora 18 and it works fine for me for > > virtualization including SRIOV and pass through as well as virtio with > KNI > > backend. > > So I am tending to stick to Fedora 18. > > > > I don't know why is CentOS not tested and mentioned in release notes. > > > > Regards > > -Prashant > > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Daniel Kan > > Sent: Thursday, January 30, 2014 2:01 PM > > To: dev at dpdk.org > > Subject: [dpdk-dev] Selecting Linux distribution for DPDK applications: > > CentOS or Debian > > > > I'm deciding between Debian 7.3 (3.2.0 kernel) and CentOS 6.5 (2.6.32 > > kernel) for production. I'm wondering if anyone has recommendation. We > run > > the DPDK application in a virtualized environment. Currently, we > configure > > NICs in pass-through mode which gives the best performance. In the > future, > > we plan to use DPDK with paravirtualized nics (eg. vmxnet3-usermap). > Thanks. > > > > Dan > > > > > > > > > > > > > === > > Please refer to http://www.aricent.com/legal/email_disclaimer.html > > for important disclosures regarding this electronic communication. > > > > > === > > >
[dpdk-dev] checking packet drop at NIC
hi! are there any interrupts which are raised by DPDK, for the fifo errors. please let me know, where can I find the details and how to handle such interrupts ? Tx -SB On Thu, Jan 30, 2014 at 2:30 PM, Sharath wrote: > Thanks Daniel ! > Let me check it out . . . > On Jan 29, 2014 8:54 PM, "Daniel Kaminsky" < > daniel.kaminsky at infinitelocality.com> wrote: > >> Hi Sharath, >> >> Try rte_eth_stats_get, I think this should give you what you're looking >> for. >> >> Regards, >> Daniel >> >> >> On Tue, Jan 28, 2014 at 7:29 AM, Sharath > gmail.com>wrote: >> >>> hi ! >>> >>> can someone please tell me whether the DPDK provides any method to handle >>> below >>> >>> a. account the packet drops at NIC level ? is there any interrupt raised >>> by >>> DPDK for the same ? >>> b. to check fifo errors ? >>> c. way to check rx and tx in sync >>> >>> Tx, >>> -SB >>> >> >>
[dpdk-dev] packets dropped when called rte_pktmbuf_prepend
Hi All, Any ideas would be helpful My situation is when I am running the l3fwd under example directory, which provide by Intel DPDK( Version is 1.2). I modify the source code of l3fwd, its function is just receive packets from port 0, then call rte_pktmbuf_prepend to insert a new header then sent out from port 1. I send 32000 packets(256 bytes) from port 0, the result is : a. if the length of new header is larger than 22 bytes, it can only received 31911 packets in port 1, some packets dropped by driver. b. if the length of new header is less than 22 bytes, it can received all packets. I found in function ixgbe_xmit_pkts, it can't sent all packets from queue, it may be warning there is no free TX descriptors to use. I am wonder if you have fix this bug. I would appreciate if you can share your experience to solve this problem. Thank you very much. PS: Attachment is the sourcecode of l3fwd, you can replace the main.c under example in your PC. You can modify the PREPEND_LEN to running different cases. After make, running as following? ./build/l3fwd -c f -n 4 -- -p 0x3 --config="(0,0,0),(0,1,2),(1,0,1),(1,1,3)" & Rong
[dpdk-dev] [PATCH RFC] dpif-netdev: Add support Intel DPDK based ports.
Prashant, IVShm is supported by the Intel DPDK client rings, and a patched QEMU/KVM from the OVDK work on 01.org (https://01.org/packet-processing). The main part being the patched QEMU/KVM to map the Intel DPDK Huge Page Tables (with Release of Intel DPDK 1.6 the requirement to map 1 GB huge pages has been removed, but still supported) into the QEMU/KVM ivshm device (the Client rings are standard in Intel DPDK releases). My suggestion to add this functionality is similar to the way different interfaces are supported under Linux (tap, socket, etc.). Basically add another Intel DPDK Netdev type for client rings. Once the rings are instantiated (upon Intel DPDK initialization), then it is simple enough to have the OpenVSwitch control to initialize them into the polling method (just like the physical ports are done today). Structures like mac address, MTU, etc. for the would need to be considered since the client rings are not really thought of as ?Ethernet? ports within DPDK. If you want to make them virtual ?Ethernet? ports, then assigning the Ethernet parameters a static value upon initialization would be acceptable. Thoughts from the community are much welcomed on this whole topic. As Pravin mentioned in one of his previous e-mails, the support for IVShmem, Intel DPDK QOS, vxLan etc. wasn?t added (and in some cases doesn?t exist as an Intel DPDK library, ie. vxLan) to simplify the patch. It will be worked on for subsequent patches. Sincerely, Gerald On 1/30/14, 3:15 AM, "Prashant Upadhyaya" wrote: >Hi Pravin, > >Request you to please validate atleast one method to interface VM's with >your innovative dpdk port on the OVS. >Preferably IVSHM. >Please do publish the steps for that too. > >We really need the above for huge acceptance. > >Regards >-Prashant > > >-Original Message- >From: Pravin Shelar [mailto:pshelar at nicira.com] >Sent: Thursday, January 30, 2014 3:00 AM >To: Prashant Upadhyaya >Cc: dev at openvswitch.org; dev at dpdk.org; dpdk-ovs at lists.01.org; Gerald >Rogers >Subject: Re: [dpdk-dev] [PATCH RFC] dpif-netdev: Add support Intel DPDK >based ports. > >On Wed, Jan 29, 2014 at 12:56 AM, Prashant Upadhyaya > wrote: >> Hi Pravin, >> >> I think your stuff is on the brink of a creating a mini revolution :) >> >> Some questions inline below -- >> +ovs-vsctl add-port br0 dpdk0 -- set Interface dpdk0 type=dpdk >> What do you mean by portid here, do you mean the physical interface id >>like eth0 which I have bound to igb_uio now ? >> If I have multiple interfaces I have assigned igb_uio to, eg. eth0, >>eth1, eth2 etc., what is the id mapping for those ? >> >Port id is id assigned by DPDK. DPDK interface takes this port id as >argument. Currently you need to look at pci id to figure out the device >mapping to port id. I know it is clean and I am exploring better >interface so that we can specify device names to ovs-vsctl. > >> If I have VM's running, then typically how to interface those VM's to >>this OVS in user space now, do I use the same classical 'tap' interface >>and add it to the OVS above. > >tap device will work, but you would not get performance primarily due to >scheduling delay and memcopy. >DPDK has multiple drivers to create interface with KVM guests OS. >those should perform better. I have no tried it yet. > >> What is the actual path the data takes from the VM now all the way to >>the switch, wouldn't it be hypervisor to kernel to OVS switch in user >>space to other VM/Network ? > >Depends on method you use. e.g. Memnic bypass hypervisor and host kernel >entirely. > >> I think if we can solve the VM to OVS port connectivity remaining in >>userspace only, then we have a great thing at our hand. Kindly comment >>on this. >> >right, performance looks pretty good. Still DPDK needs constant polling >which consumes more power. RFC ovs-dkdp patch has simple polling which >need tweaking for better power usage. > >Thanks, >Pravin. > > > >> Regards >> -Prashant >> >> > > > > >== >= >Please refer to http://www.aricent.com/legal/email_disclaimer.html >for important disclosures regarding this electronic communication. >== >=
[dpdk-dev] [PATCH RFC] dpif-netdev: Add support Intel DPDK based ports.
Hi Pravin, Request you to please validate atleast one method to interface VM's with your innovative dpdk port on the OVS. Preferably IVSHM. Please do publish the steps for that too. We really need the above for huge acceptance. Regards -Prashant -Original Message- From: Pravin Shelar [mailto:pshe...@nicira.com] Sent: Thursday, January 30, 2014 3:00 AM To: Prashant Upadhyaya Cc: dev at openvswitch.org; dev at dpdk.org; dpdk-ovs at lists.01.org; Gerald Rogers Subject: Re: [dpdk-dev] [PATCH RFC] dpif-netdev: Add support Intel DPDK based ports. On Wed, Jan 29, 2014 at 12:56 AM, Prashant Upadhyaya wrote: > Hi Pravin, > > I think your stuff is on the brink of a creating a mini revolution :) > > Some questions inline below -- > +ovs-vsctl add-port br0 dpdk0 -- set Interface dpdk0 type=dpdk > What do you mean by portid here, do you mean the physical interface id like > eth0 which I have bound to igb_uio now ? > If I have multiple interfaces I have assigned igb_uio to, eg. eth0, eth1, > eth2 etc., what is the id mapping for those ? > Port id is id assigned by DPDK. DPDK interface takes this port id as argument. Currently you need to look at pci id to figure out the device mapping to port id. I know it is clean and I am exploring better interface so that we can specify device names to ovs-vsctl. > If I have VM's running, then typically how to interface those VM's to this > OVS in user space now, do I use the same classical 'tap' interface and add it > to the OVS above. tap device will work, but you would not get performance primarily due to scheduling delay and memcopy. DPDK has multiple drivers to create interface with KVM guests OS. those should perform better. I have no tried it yet. > What is the actual path the data takes from the VM now all the way to the > switch, wouldn't it be hypervisor to kernel to OVS switch in user space to > other VM/Network ? Depends on method you use. e.g. Memnic bypass hypervisor and host kernel entirely. > I think if we can solve the VM to OVS port connectivity remaining in > userspace only, then we have a great thing at our hand. Kindly comment on > this. > right, performance looks pretty good. Still DPDK needs constant polling which consumes more power. RFC ovs-dkdp patch has simple polling which need tweaking for better power usage. Thanks, Pravin. > Regards > -Prashant > > === Please refer to http://www.aricent.com/legal/email_disclaimer.html for important disclosures regarding this electronic communication. ===
[dpdk-dev] Selecting Linux distribution for DPDK applications: CentOS or Debian
Hi Dan, Intel DPDK release notes(1.5.2) mention the following tested OS -- * Fedora release 18 * Ubuntu* 12.04 LTS * Wind River* Linux* 5 * Red Hat* Enterprise Linux 6.3 * SUSE Enterprise Linux* 11 SP2 I have personally used Fedora 18 and it works fine for me for virtualization including SRIOV and pass through as well as virtio with KNI backend. So I am tending to stick to Fedora 18. I don't know why is CentOS not tested and mentioned in release notes. Regards -Prashant -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Daniel Kan Sent: Thursday, January 30, 2014 2:01 PM To: dev at dpdk.org Subject: [dpdk-dev] Selecting Linux distribution for DPDK applications: CentOS or Debian I'm deciding between Debian 7.3 (3.2.0 kernel) and CentOS 6.5 (2.6.32 kernel) for production. I'm wondering if anyone has recommendation. We run the DPDK application in a virtualized environment. Currently, we configure NICs in pass-through mode which gives the best performance. In the future, we plan to use DPDK with paravirtualized nics (eg. vmxnet3-usermap). Thanks. Dan === Please refer to http://www.aricent.com/legal/email_disclaimer.html for important disclosures regarding this electronic communication. ===
[dpdk-dev] checking packet drop at NIC
Thanks Daniel ! Let me check it out . . . On Jan 29, 2014 8:54 PM, "Daniel Kaminsky" < daniel.kaminsky at infinitelocality.com> wrote: > Hi Sharath, > > Try rte_eth_stats_get, I think this should give you what you're looking > for. > > Regards, > Daniel > > > On Tue, Jan 28, 2014 at 7:29 AM, Sharath gmail.com>wrote: > >> hi ! >> >> can someone please tell me whether the DPDK provides any method to handle >> below >> >> a. account the packet drops at NIC level ? is there any interrupt raised >> by >> DPDK for the same ? >> b. to check fifo errors ? >> c. way to check rx and tx in sync >> >> Tx, >> -SB >> > >
[dpdk-dev] Selecting Linux distribution for DPDK applications: CentOS or Debian
We're using CentOS 6.5 and Ubuntu 12.04 and don't see any issue with both of them. Regards, Daniel Kaminsky On Thu, Jan 30, 2014 at 12:12 PM, Prashant Upadhyaya < prashant.upadhyaya at aricent.com> wrote: > Hi Dan, > > Intel DPDK release notes(1.5.2) mention the following tested OS -- > * Fedora release 18 > * Ubuntu* 12.04 LTS > * Wind River* Linux* 5 > * Red Hat* Enterprise Linux 6.3 > * SUSE Enterprise Linux* 11 SP2 > > I have personally used Fedora 18 and it works fine for me for > virtualization including SRIOV and pass through as well as virtio with KNI > backend. > So I am tending to stick to Fedora 18. > > I don't know why is CentOS not tested and mentioned in release notes. > > Regards > -Prashant > > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Daniel Kan > Sent: Thursday, January 30, 2014 2:01 PM > To: dev at dpdk.org > Subject: [dpdk-dev] Selecting Linux distribution for DPDK applications: > CentOS or Debian > > I'm deciding between Debian 7.3 (3.2.0 kernel) and CentOS 6.5 (2.6.32 > kernel) for production. I'm wondering if anyone has recommendation. We run > the DPDK application in a virtualized environment. Currently, we configure > NICs in pass-through mode which gives the best performance. In the future, > we plan to use DPDK with paravirtualized nics (eg. vmxnet3-usermap). Thanks. > > Dan > > > > > > === > Please refer to http://www.aricent.com/legal/email_disclaimer.html > for important disclosures regarding this electronic communication. > > === >
[dpdk-dev] [memnic PATCH] linux: fix build with kernel >= 3.3
I never noticed about that and I haven't check compilation with newer kernel.
But I think you have completed to test it.
Fine to me.
thanks,
Hiroshi
> Subject: [dpdk-dev] [memnic PATCH] linux: fix build with kernel >= 3.3
>
> Signed-off-by: Olivier Matz
> ---
> linux/memnic_net.c | 28 ++--
> 1 file changed, 26 insertions(+), 2 deletions(-)
>
> diff --git a/linux/memnic_net.c b/linux/memnic_net.c
> index 747ae51..b6018fb 100644
> --- a/linux/memnic_net.c
> +++ b/linux/memnic_net.c
> @@ -2,6 +2,7 @@
> * BSD LICENSE
> *
> * Copyright(c) 2013-2014 NEC All rights reserved.
> + * Copyright(c) 2014 6WIND S.A.
> *
> * Redistribution and use in source and binary forms, with or without
> * modification, are permitted provided that the following conditions
> @@ -29,6 +30,7 @@
> */
> /* Dual BSD/GPL */
>
> +#include
> #include
> #include
>
> @@ -259,13 +261,35 @@ static void memnic_tx_timeout(struct net_device *netdev)
> {
> }
>
> -static void memnic_vlan_rx_add_vid(struct net_device *netdev, unsigned short
> vid)
> +#if LINUX_VERSION_CODE >= KERNEL_VERSION(3,10,0)
> +static int memnic_vlan_rx_add_vid(struct net_device *netdev, __be16 proto,
> u16 vid)
> +{
> + return 0;
> +}
> +
> +static int memnic_vlan_rx_kill_vid(struct net_device *netdev, __be16 proto,
> u16 vid)
> +{
> + return 0;
> +}
> +#elif LINUX_VERSION_CODE >= KERNEL_VERSION(3,3,0)
> +static int memnic_vlan_rx_add_vid(struct net_device *netdev, uint16_t vid)
> +{
> + return 0;
> +}
> +
> +static int memnic_vlan_rx_kill_vid(struct net_device *netdev, uint16_t vid)
> +{
> + return 0;
> +}
> +#else
> +static void memnic_vlan_rx_add_vid(struct net_device *netdev, uint16_t vid)
> {
> }
>
> -static void memnic_vlan_rx_kill_vid(struct net_device *netdev, unsigned
> short vid)
> +static void memnic_vlan_rx_kill_vid(struct net_device *netdev, uint16_t vid)
> {
> }
> +#endif
>
> static int memnic_ioctl(struct net_device *netdev, struct ifreq *req, int
> cmd)
> {
> --
> 1.8.4.rc3
[dpdk-dev] [memnic PATCH] pmd: use memory barrier function instead of asm volatile
> Subject: [dpdk-dev] [memnic PATCH] pmd: use memory barrier function instead
> of asm volatile
>
> Use the DPDK specific function rte_mb() instead of
> the GCC statement asm volatile ("" ::: "memory").
Yes, that's preferred for DPDK, I think.
Looks okay to me.
By the way, I was also asked to use rte atomic function
instead of cmpxchg asm statement.
My re-submitted version in dpdk-ovs has such a change.
What do you think?
thanks,
Hiroshi
>
> Signed-off-by: Olivier Matz
> ---
> common/memnic.h | 2 --
> pmd/pmd_memnic.c | 6 +++---
> 2 files changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/common/memnic.h b/common/memnic.h
> index 6ff38a0..fdc9fa3 100644
> --- a/common/memnic.h
> +++ b/common/memnic.h
> @@ -123,8 +123,6 @@ struct memnic_area {
> /* for userspace */
> #define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))
>
> -#define barrier() do { asm volatile("": : :"memory"); } while (0)
> -
> static inline uint32_t cmpxchg(uint32_t *dst, uint32_t old, uint32_t new)
> {
> volatile uint32_t *ptr = (volatile uint32_t *)dst;
> diff --git a/pmd/pmd_memnic.c b/pmd/pmd_memnic.c
> index bc01746..1586222 100644
> --- a/pmd/pmd_memnic.c
> +++ b/pmd/pmd_memnic.c
> @@ -100,7 +100,7 @@ static int memnic_dev_start(struct rte_eth_dev *dev)
>
> /* invalidate */
> adapter->nic->hdr.valid = 0;
> - barrier();
> + rte_mb();
> /* reset */
> adapter->nic->hdr.reset = 1;
> /* no need to wait here */
> @@ -242,7 +242,7 @@ static uint16_t memnic_recv_pkts(void *rx_queue,
> mb->pkt.data_len = p->len;
> rx_pkts[nr] = mb;
>
> - barrier();
> + rte_mb();
> p->status = MEMNIC_PKT_ST_FREE;
>
> if (++idx >= MEMNIC_NR_PACKET)
> @@ -290,7 +290,7 @@ retry:
>
> rte_memcpy(p->data, rte_pktmbuf_mtod(tx_pkts[nr], void *), len);
>
> - barrier();
> + rte_mb();
> p->status = MEMNIC_PKT_ST_FILLED;
>
> rte_pktmbuf_free(tx_pkts[nr]);
> --
> 1.8.4.rc3
[dpdk-dev] [memnic PATCH] pmd: fix attributes
> Subject: [dpdk-dev] [memnic PATCH] pmd: fix attributes
>
> Add missing "const" and remove useless "rte_unused" attributes.
Good catch. Looks fine to me.
thanks,
Hiroshi
>
> Signed-off-by: Olivier Matz
> ---
> pmd/pmd_memnic.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/pmd/pmd_memnic.c b/pmd/pmd_memnic.c
> index d16eb0d..bc01746 100644
> --- a/pmd/pmd_memnic.c
> +++ b/pmd/pmd_memnic.c
> @@ -57,7 +57,7 @@ struct memnic_adapter {
> struct ether_addr mac_addr;
> };
>
> -static inline struct memnic_adapter *get_adapter(struct rte_eth_dev *dev)
> +static inline struct memnic_adapter *get_adapter(const struct rte_eth_dev
> *dev)
> {
> return (struct memnic_adapter *)(dev->data->dev_private);
> }
> @@ -67,7 +67,7 @@ struct memnic_queue {
> uint8_t port_id;
> };
>
> -static struct memnic_queue *memnic_queue_alloc(struct rte_eth_dev *dev,
> +static struct memnic_queue *memnic_queue_alloc(const struct rte_eth_dev *dev,
> int tx, uint16_t id)
> {
> struct memnic_adapter *adapter = get_adapter(dev);
> @@ -119,7 +119,7 @@ static void memnic_dev_stop(struct rte_eth_dev *dev)
> return;
> }
>
> -static void memnic_dev_infos_get(__rte_unused struct rte_eth_dev *dev,
> +static void memnic_dev_infos_get(struct rte_eth_dev *dev,
>struct rte_eth_dev_info *dev_info)
> {
> dev_info->driver_name = dev->driver->pci_drv.name;
> --
> 1.8.4.rc3
[dpdk-dev] [PATCH 11/11] kvargs: add test case in app/test
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier Matz > Sent: Tuesday, January 28, 2014 4:07 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH 11/11] kvargs: add test case in app/test > > Add a file app/test/test_kvargs.c that checks the rte_kvargs API. > The test passes: > > RTE>>kvargs > == test valid case == > == test invalid case == > PMD: Error parsing device, invalid key > Test OK > > I also tested that rte_eth_pcap runs with the following arguments: > > ./app/testpmd -c 0x15 -n 3 --proc-type=primary --huge-dir=/mnt/huge \ > --use-device="eth_pcap0;iface=ixgbe0" \ > -- -i --port-topology=chained > > ./app/testpmd -c 0x15 -n 3 --proc-type=primary --huge-dir=/mnt/huge \ > --use- > device="eth_pcap0;rx_iface=ixgbe0;rx_iface=ixgbe1;tx_iface=ixgbe0" \ > -- -i --port-topology=chained > > Signed-off-by: Olivier Matz > --- > app/test/Makefile | 1 + > app/test/commands.c| 8 ++ > app/test/test.h| 1 + > app/test/test_kvargs.c | 235 > + > 4 files changed, 245 insertions(+) > create mode 100644 app/test/test_kvargs.c Acked-by: Bruce Richardson
[dpdk-dev] [PATCH 10/11] kvargs: make the NULL key to match all entries
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier Matz > Sent: Tuesday, January 28, 2014 4:07 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH 10/11] kvargs: make the NULL key to match all > entries > > In rte_kvargs_process() and rte_kvargs_count(), if the key_match argument > is NULL, process all entries. > > Signed-off-by: Olivier Matz > --- > lib/librte_kvargs/rte_kvargs.c | 4 ++-- lib/librte_kvargs/rte_kvargs.h | 5 > +++-- > 2 files changed, 5 insertions(+), 4 deletions(-) > Acked-by: Bruce Richardson
[dpdk-dev] [PATCH 09/11] kvargs: add the key in handler pameters
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier Matz > Sent: Tuesday, January 28, 2014 4:07 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH 09/11] kvargs: add the key in handler pameters > > This argument can be useful when rte_kvargs_process() is called with > key=NULL, in this case the handler is invoked for all entries of the kvlist. > > Signed-off-by: Olivier Matz > --- > lib/librte_kvargs/rte_kvargs.c | 2 +- > lib/librte_kvargs/rte_kvargs.h | 2 +- > lib/librte_pmd_pcap/rte_eth_pcap.c | 10 +- > 3 files changed, 7 insertions(+), 7 deletions(-) Acked-by: Bruce Richardson
[dpdk-dev] [memnic PATCH 3/3] common: remove double underscores
Looks fine to me. thanks, Hiroshi > Subject: [memnic PATCH 3/3] common: remove double underscores > > The usage of double underscores is reserved. > > Signed-off-by: Thomas Monjalon > --- > common/memnic.h |6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/common/memnic.h b/common/memnic.h > index 58dd019..e5b3c6f 100644 > --- a/common/memnic.h > +++ b/common/memnic.h > @@ -28,8 +28,8 @@ > * > */ > > -#ifndef __MEMNIC_H__ > -#define __MEMNIC_H__ > +#ifndef MEMNIC_H > +#define MEMNIC_H > > #define MEMNIC_MAGIC 0x43494e76 > #define MEMNIC_VERSION 0x0001 > @@ -135,4 +135,4 @@ static inline uint32_t cmpxchg(uint32_t *dst, uint32_t > old, uint32_t new) > } > #endif /* __KERNEL__ */ > > -#endif /* __MEMNIC_H__ */ > +#endif /* MEMNIC_H */ > -- > 1.7.10.4
[dpdk-dev] [memnic PATCH 2/3] pmd: remove useless includes
> Subject: [memnic PATCH 2/3] pmd: remove useless includes > > Signed-off-by: Thomas Monjalon > --- > common/memnic.h |4 > pmd/pmd_memnic.c |4 > 2 files changed, 8 deletions(-) > > diff --git a/common/memnic.h b/common/memnic.h > index 6ff38a0..58dd019 100644 > --- a/common/memnic.h > +++ b/common/memnic.h > @@ -31,10 +31,6 @@ > #ifndef __MEMNIC_H__ > #define __MEMNIC_H__ > > -#ifndef __KERNEL__ > -#include > -#endif /* __KERNEL__ */ > - I'm not sure, but you're not seeing error, it's okay. I put it for uintxx_t series, originally. others, fine to me. thanks, Hiroshi > #define MEMNIC_MAGIC 0x43494e76 > #define MEMNIC_VERSION 0x0001 > #define MEMNIC_VERSION_1 0x0001 > diff --git a/pmd/pmd_memnic.c b/pmd/pmd_memnic.c > index d16eb0d..619941a 100644 > --- a/pmd/pmd_memnic.c > +++ b/pmd/pmd_memnic.c > @@ -30,18 +30,14 @@ > */ > > #include > - > #include > #include > #include > -#include > > #include "memnic.h" > > #include > -#include > #include > -#include > #include > #include > > -- > 1.7.10.4
[dpdk-dev] [PATCH 08/11] kvargs: add const attribute in handler parameters
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier Matz > Sent: Tuesday, January 28, 2014 4:07 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH 08/11] kvargs: add const attribute in handler > parameters > > The "value" argument is read-only and should be const. > > Signed-off-by: Olivier Matz > --- > lib/librte_kvargs/rte_kvargs.h | 2 +- > lib/librte_pmd_pcap/rte_eth_pcap.c | 14 +++--- > 2 files changed, 8 insertions(+), 8 deletions(-) Acked-by: Bruce Richardson
[dpdk-dev] [PATCH 07/11] kvargs: be strict when matching a key
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier Matz
> Sent: Tuesday, January 28, 2014 4:07 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH 07/11] kvargs: be strict when matching a key
>
> When we match a key in is_valid_key() and rte_kvargs_process(), do a strict
> comparison (strcmp()) instead of using strstr(s1, s2) which tries a find s1 in
> s2. This old behavior could lead to unexpected match, for instance "cola"
> match "chocolate".
>
> Surprisingly, no patch was needed on rte_kvargs_count() as it already used
> strcmp().
>
> Signed-off-by: Olivier Matz
> ---
> lib/librte_kvargs/rte_kvargs.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/lib/librte_kvargs/rte_kvargs.c b/lib/librte_kvargs/rte_kvargs.c
> index 6aaa316..73034fc 100644
> --- a/lib/librte_kvargs/rte_kvargs.c
> +++ b/lib/librte_kvargs/rte_kvargs.c
> @@ -94,9 +94,10 @@ is_valid_key(const char *valid[], const char
> *key_match) {
> const char **valid_ptr;
>
> - for (valid_ptr = valid; *valid_ptr != NULL; valid_ptr++)
> - if (strstr(key_match, *valid_ptr) != NULL)
> + for (valid_ptr = valid; *valid_ptr != NULL; valid_ptr++) {
> + if (strcmp(key_match, *valid_ptr) == 0)
> return 1;
> + }
> return 0;
> }
>
> @@ -159,7 +160,7 @@ rte_kvargs_process(const struct rte_kvargs *kvlist,
>
> for (i = 0; i < kvlist->count; i++) {
> pair = >pairs[i];
> - if (strstr(pair->key, key_match) != NULL) {
> + if (strcmp(pair->key, key_match) == 0) {
> if ((*handler)(pair->value, opaque_arg) < 0)
> return -1;
> }
> --
> 1.8.4.rc3
Acked-by: Bruce Richardson
[dpdk-dev] [PATCH 06/11] kvargs: simpler parsing and allow duplicated keys
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier Matz > Sent: Tuesday, January 28, 2014 4:07 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH 06/11] kvargs: simpler parsing and allow > duplicated keys > > Remove the rte_kvargs_add_pair() function whose only role was to check if > a key is duplicated. Having duplicated keys is now allowed by kvargs API. > > Also replace rte_strsplit() by more a standard function strtok_r() that is > easier to understand for people already knowing the libc. It also avoids > useless calls to strnlen(). The delimiters macros become strings instead of > chars due to the strtok_r() API. > > Signed-off-by: Olivier Matz > --- > lib/librte_kvargs/rte_kvargs.c | 71 > ++ > lib/librte_kvargs/rte_kvargs.h | 8 +++-- > 2 files changed, 22 insertions(+), 57 deletions(-) > Acked-by: Bruce Richardson
[dpdk-dev] [PATCH 05/11] kvargs: rework API to fix memory leak
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier Matz > Sent: Tuesday, January 28, 2014 4:07 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH 05/11] kvargs: rework API to fix memory leak > > Before the patch, a call to rte_kvargs_tokenize() resulted in a call to > strdup() to allocate a modifiable copy of the argument string. This string > was never freed, excepted in the error cases of > rte_kvargs_tokenize() where rte_free() was wrongly called instead of free(). > In other cases, freeing this string was impossible as the pointer not saved. > > This patch introduces rte_kvargs_free() in order to free the structure > properly. The pointer to the duplicated string is now kept in the rte_kvargs > structure. A call to rte_kvargs_parse() directly allocates the structure, > making rte_kvargs_init() useless. > > The only drawback of this API change is that a key/value associations > cannot be added to an existing kvlist. But it's not used today, and there is > not obvious use case for that. > > Signed-off-by: Olivier Matz > --- > lib/librte_kvargs/Makefile | 3 +- > lib/librte_kvargs/rte_kvargs.c | 64 > ++ > lib/librte_kvargs/rte_kvargs.h | 42 +++-- > lib/librte_pmd_pcap/rte_eth_pcap.c | 27 > 4 files changed, 63 insertions(+), 73 deletions(-) > Acked-by: Bruce Richardson
[dpdk-dev] [memnic PATCH 1/3] pmd: remove symlink
Hi, > Subject: [memnic PATCH 1/3] pmd: remove symlink > > No need to have a symbolic link to a common file > when it can be simply included. Looks fine to me. When I prepared the file with a bit complex file path layout, easy to keep consistency. Because you separated the code from DPDK vSwitch, there is no reason to do that. thanks, Hiroshi > > Signed-off-by: Thomas Monjalon > --- > pmd/Makefile |2 +- > pmd/memnic.h |1 - > 2 files changed, 1 insertion(+), 2 deletions(-) > delete mode 12 pmd/memnic.h > > diff --git a/pmd/Makefile b/pmd/Makefile > index a96e125..7f96af1 100644 > --- a/pmd/Makefile > +++ b/pmd/Makefile > @@ -59,7 +59,7 @@ ifeq '$(RTE_INCLUDE)' '' > endif > $(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) \ > -I$(RTE_INCLUDE) -include $(RTE_CONFIG) \ > - -o $@ $< > + -I$S/../common -o $@ $< > > install : $(DESTDIR)$(libdir)/$(SOLIB) > install -D -m 644 $S/README.rst $(DESTDIR)$(docdir)/README.rst > diff --git a/pmd/memnic.h b/pmd/memnic.h > deleted file mode 12 > index 5303ad4..000 > --- a/pmd/memnic.h > +++ /dev/null > @@ -1 +0,0 @@ > -../common/memnic.h > \ No newline at end of file > -- > 1.7.10.4
[dpdk-dev] Selecting Linux distribution for DPDK applications: CentOS or Debian
I?m deciding between Debian 7.3 (3.2.0 kernel) and CentOS 6.5 (2.6.32 kernel) for production. I?m wondering if anyone has recommendation. We run the DPDK application in a virtualized environment. Currently, we configure NICs in pass-through mode which gives the best performance. In the future, we plan to use DPDK with paravirtualized nics (eg. vmxnet3-usermap). Thanks. Dan
[dpdk-dev] [ovs-dev] [PATCH RFC] dpif-netdev: Add support Intel DPDK based ports.
On 01/29/2014 09:47 PM, Fran?ois-Fr?d?ric Ozog wrote: > In the telecom world, if you fix the underlying framework of an app, you > will still have to validate the solution, ie app/framework. In addition, the > idea of shared libraries introduces the implied requirement to validate apps > against diverse versions of DPDK shared libraries. This translates into > development and support costs. > > I also expect many DPDK applications to tackle core networking features, > with sub micro second packet handling delays and even lower than 200ns > (NAT64...). The lazy binding based on ELF PLT represent quite a cost, not > mentioning that optimization stops are shared libraries boundaries (gcc > whole program optimization can be very effective...). Microsoft DLL linkage > are an order of magnitude faster. If Linux was to provide that, I would > probably revise my judgment. (I haven't checked Linux dynamic linking > implementation for some time so my understanding of Linux dynamic linking > may be outdated). All very valid points and I am not suggesting to stop offering the static linking option in any way. Dynamic linking will by design result in more cycles. My sole point is that for a core platform component like OVS, the shared library benefits _might_ outweigh the performance difference. In order for a shared library to be effective, some form of ABI compatibility must be guaranteed though. > I don't think it is so straight forward. Many recent cards such as Chelsio > and Myricom have a very different "packet memory layout" that does not fit > so easily into actual DPDK architecture. > > 1) "traditional" architecture: the driver reserves X buffers and provide the > card with descriptors of those buffers. Each packet is DMA'ed into exactly > one buffer. Typically you have 2K buffers, a 64 byte packet consumes exactly > one buffer > > 2) "alternative" new architecture: the driver reserves a memory zone, say > 4MB, without any structure, and provide a a single zone description and a > ring buffer to the card. (there no individual buffer descriptors any more). > The card fills the memory zone with packets, one next to the other and > specifies where the packets are by updating the supplied ring. Out of the > many issues fitting this scheme into DPDK, you cannot free a single mbuf: > you have to maintain a ref count to the memory zone so that, when all mbufs > have been "released", the memory zone can be freed. > That's quite a stretch from actual paradigm. > > Apart from this aspect, managing RSS is two tied to Intel's flow director > concepts and cannot accommodate directly smarter or dumber RSS mechanisms. > > That said, I fully agree PMD API should be revisited. Fair enough. I don't see a reason why multiple interfaces could not coexist in order to support multiple memory layouts. What I'm hearing so far is that while there is no objection to bringing stability to the APIs, it should not result in performance side effects and it is still early to nail down the yet fluent APIs.
