[dpdk-dev] [RFC PATCH 0/7] add OSv support
On Fri, Mar 13, 2015 at 7:00 PM, Bruce Richardson <
bruce.richardson at intel.com> wrote:
> On Fri, Mar 13, 2015 at 06:05:41AM +0900, Takuya ASADA wrote:
> > Hi DPDK developers,
> >
> > I'd like to contribute a new EAL to support our open-sourced operating
> system called "OSv".
> > It is a new operating system build from scratch for cloud computing, to
> run application faster with lower footprint on IaaS.
> > Unlike general propose OS, it is a library OS designed to run single
> application per one instance, everything run in kernel mode, single memory
> space.
> > It's not using Linux kernel but has compatibility with Linux
> application, not perfect but we already supported various applications such
> as Cassandra, memcached, Redis, etc.
> >
> > In DPDK case, PMDs can access devices directly, without kernel driver
> help.
> > At this point I haven't enough optimized performance of the EAL yet, but
> it has potential to get better performance than Linux with fewer resources.
> >
> > OSv web site: http://osv.io
> > USENIX ATC'14 paper:
> https://www.usenix.org/conference/atc14/technical-sessions/presentation/kivity
>
> This sounds really interesting. Any chance of adding in a "Getting Started
> Guide"
> with your patchset to make it easy for us to try out DPDK on OSv?
>
We have an application repository for OSv, I'll add DPDK to deploy it
easier:
https://github.com/cloudius-systems/osv-apps
And we will add DPDK building instructions on OSv wiki:
https://github.com/cloudius-systems/osv/wiki
Since Linux and FreeBSD has "Getting Started Guide", probably I need to add
OSv version too?
> >
> > Takuya ASADA (7):
> > mk: support compiling C++ code
> > eal: Add extern C on eal_hugepages.h
> > eal: Add extern C on eal_thread.h
> > eal: Add extern C on eal_private.h
> > add OSv support
> > virtio: enable MSI-X on OSv
> > app/test: support OSv
> >
> > app/test/test_eal_flags.c | 34 +--
> > app/test/test_timer_perf.c | 2 +-
> > config/{common_linuxapp => common_osvapp} | 20 +-
> > ...xapp-gcc => defconfig_x86_64-native-osvapp-gcc} | 2 +-
> > lib/librte_eal/Makefile| 2 +
> > lib/librte_eal/common/eal_hugepages.h | 8 +
> > lib/librte_eal/common/eal_private.h| 8 +
> > lib/librte_eal/common/eal_thread.h | 8 +
> > Makefile => lib/librte_eal/osvapp/Makefile | 5 +-
> > lib/librte_eal/osvapp/eal/Makefile | 115
> > lib/librte_eal/{linuxapp => osvapp}/eal/eal.c | 123 +---
> > .../{linuxapp => osvapp}/eal/eal_alarm.c | 0
> > .../{linuxapp => osvapp}/eal/eal_debug.c | 0
> > lib/librte_eal/osvapp/eal/eal_hugepage_info.cc | 63 +
> > .../{bsdapp => osvapp}/eal/eal_interrupts.c| 0
> > .../eal/eal_lcore.c => osvapp/eal/eal_lcore.cc}| 53 ++--
> > lib/librte_eal/{bsdapp => osvapp}/eal/eal_log.c| 0
> > lib/librte_eal/osvapp/eal/eal_memory.cc| 148 ++
> > lib/librte_eal/osvapp/eal/eal_pci.cc | 311
> +
> > .../{linuxapp => osvapp}/eal/eal_thread.c | 0
> > lib/librte_eal/osvapp/eal/eal_timer.c | 121
> > .../eal/include/exec-env/rte_interrupts.h | 0
> > lib/librte_pmd_virtio/virtio_ethdev.c | 15 +-
> > mk/exec-env/{linuxapp => osvapp}/rte.app.mk| 0
> > mk/exec-env/{linuxapp => osvapp}/rte.vars.mk | 6 +-
> > mk/internal/rte.compile-pre.mk | 41 ++-
> > mk/target/generic/rte.vars.mk | 4 +
> > mk/toolchain/gcc/rte.vars.mk | 5 +-
> > 28 files changed, 907 insertions(+), 187 deletions(-)
> > copy config/{common_linuxapp => common_osvapp} (97%)
> > copy config/{defconfig_x86_64-native-linuxapp-gcc =>
> defconfig_x86_64-native-osvapp-gcc} (98%)
> > copy Makefile => lib/librte_eal/osvapp/Makefile (93%)
> > create mode 100644 lib/librte_eal/osvapp/eal/Makefile
> > copy lib/librte_eal/{linuxapp => osvapp}/eal/eal.c (87%)
> > copy lib/librte_eal/{linuxapp => osvapp}/eal/eal_alarm.c (100%)
> > copy lib/librte_eal/{linuxapp => osvapp}/eal/eal_debug.c (100%)
> > create mode 100644 lib/librte_eal/osvapp/eal/eal_hugepage_info.cc
> > copy lib/librte_eal/{bsdapp => osvapp}/eal/eal_interrupts.c (100%)
> > copy lib/librte_eal/{bsdapp/eal/eal_lcore.c => osvapp/eal/eal_lcore.cc}
> (80%)
> > copy lib/librte_eal/{bsdapp => osvapp}/eal/eal_log.c (100%)
> > create mode 100644 lib/librte_eal/osvapp/eal/eal_memory.cc
> > create mode 100644 lib/librte_eal/osvapp/eal/eal_pci.cc
> > copy lib/librte_eal/{linuxapp => osvapp}/eal/eal_thread.c (100%)
> > create mode 100644 lib/librte_eal/osvapp/eal/eal_timer.c
> > copy lib/librte_eal/{bsdapp =>
> osvapp}/eal/include/exec-env/rte_interrupts.h (100%)
> > copy mk/exec-env/{linuxapp => osvapp}/rte.app.mk (100%)
> > copy mk/exec-env/
[dpdk-dev] [RFC PATCH 0/7] add OSv support
On Fri, Mar 13, 2015 at 10:42 PM, Neil Horman wrote:
> On Fri, Mar 13, 2015 at 06:05:41AM +0900, Takuya ASADA wrote:
> > Hi DPDK developers,
> >
> > I'd like to contribute a new EAL to support our open-sourced operating
> system called "OSv".
> > It is a new operating system build from scratch for cloud computing, to
> run application faster with lower footprint on IaaS.
> > Unlike general propose OS, it is a library OS designed to run single
> application per one instance, everything run in kernel mode, single memory
> space.
> > It's not using Linux kernel but has compatibility with Linux
> application, not perfect but we already supported various applications such
> as Cassandra, memcached, Redis, etc.
> >
> > In DPDK case, PMDs can access devices directly, without kernel driver
> help.
> > At this point I haven't enough optimized performance of the EAL yet, but
> it has potential to get better performance than Linux with fewer resources.
> >
> > OSv web site: http://osv.io
> > USENIX ATC'14 paper:
> https://www.usenix.org/conference/atc14/technical-sessions/presentation/kivity
> >
> > Takuya ASADA (7):
> > mk: support compiling C++ code
> > eal: Add extern C on eal_hugepages.h
> > eal: Add extern C on eal_thread.h
> > eal: Add extern C on eal_private.h
> > add OSv support
> > virtio: enable MSI-X on OSv
> > app/test: support OSv
> >
> > app/test/test_eal_flags.c | 34 +--
> > app/test/test_timer_perf.c | 2 +-
> > config/{common_linuxapp => common_osvapp} | 20 +-
> > ...xapp-gcc => defconfig_x86_64-native-osvapp-gcc} | 2 +-
> > lib/librte_eal/Makefile| 2 +
> > lib/librte_eal/common/eal_hugepages.h | 8 +
> > lib/librte_eal/common/eal_private.h| 8 +
> > lib/librte_eal/common/eal_thread.h | 8 +
> > Makefile => lib/librte_eal/osvapp/Makefile | 5 +-
> > lib/librte_eal/osvapp/eal/Makefile | 115
> > lib/librte_eal/{linuxapp => osvapp}/eal/eal.c | 123 +---
> > .../{linuxapp => osvapp}/eal/eal_alarm.c | 0
> > .../{linuxapp => osvapp}/eal/eal_debug.c | 0
> > lib/librte_eal/osvapp/eal/eal_hugepage_info.cc | 63 +
> > .../{bsdapp => osvapp}/eal/eal_interrupts.c| 0
> > .../eal/eal_lcore.c => osvapp/eal/eal_lcore.cc}| 53 ++--
> > lib/librte_eal/{bsdapp => osvapp}/eal/eal_log.c| 0
> > lib/librte_eal/osvapp/eal/eal_memory.cc| 148 ++
> > lib/librte_eal/osvapp/eal/eal_pci.cc | 311
> +
> > .../{linuxapp => osvapp}/eal/eal_thread.c | 0
> > lib/librte_eal/osvapp/eal/eal_timer.c | 121
> > .../eal/include/exec-env/rte_interrupts.h | 0
> > lib/librte_pmd_virtio/virtio_ethdev.c | 15 +-
> > mk/exec-env/{linuxapp => osvapp}/rte.app.mk| 0
> > mk/exec-env/{linuxapp => osvapp}/rte.vars.mk | 6 +-
> > mk/internal/rte.compile-pre.mk | 41 ++-
> > mk/target/generic/rte.vars.mk | 4 +
> > mk/toolchain/gcc/rte.vars.mk | 5 +-
> > 28 files changed, 907 insertions(+), 187 deletions(-)
> > copy config/{common_linuxapp => common_osvapp} (97%)
> > copy config/{defconfig_x86_64-native-linuxapp-gcc =>
> defconfig_x86_64-native-osvapp-gcc} (98%)
> > copy Makefile => lib/librte_eal/osvapp/Makefile (93%)
> > create mode 100644 lib/librte_eal/osvapp/eal/Makefile
> > copy lib/librte_eal/{linuxapp => osvapp}/eal/eal.c (87%)
> > copy lib/librte_eal/{linuxapp => osvapp}/eal/eal_alarm.c (100%)
> > copy lib/librte_eal/{linuxapp => osvapp}/eal/eal_debug.c (100%)
> > create mode 100644 lib/librte_eal/osvapp/eal/eal_hugepage_info.cc
> > copy lib/librte_eal/{bsdapp => osvapp}/eal/eal_interrupts.c (100%)
> > copy lib/librte_eal/{bsdapp/eal/eal_lcore.c => osvapp/eal/eal_lcore.cc}
> (80%)
> > copy lib/librte_eal/{bsdapp => osvapp}/eal/eal_log.c (100%)
> > create mode 100644 lib/librte_eal/osvapp/eal/eal_memory.cc
> > create mode 100644 lib/librte_eal/osvapp/eal/eal_pci.cc
> > copy lib/librte_eal/{linuxapp => osvapp}/eal/eal_thread.c (100%)
> > create mode 100644 lib/librte_eal/osvapp/eal/eal_timer.c
> > copy lib/librte_eal/{bsdapp =>
> osvapp}/eal/include/exec-env/rte_interrupts.h (100%)
> > copy mk/exec-env/{linuxapp => osvapp}/rte.app.mk (100%)
> > copy mk/exec-env/{linuxapp => osvapp}/rte.vars.mk (95%)
> >
> > --
> > 2.1.0
> >
> >
>
> I presume you intend for this to get merged during the 2.1 release?
>
> Neil
>
>
Yes, I think it would be nice if it can merge for v2.1.
[dpdk-dev] PMD architecture related to code
Thank for replay Bruce , I am looking code related to NIC to DMA mapping and DMA to user space . Suggestions are welcome . Regards, Kuldeep -Original Message- From: Bruce Richardson [mailto:bruce.richard...@intel.com] Sent: Friday, March 13, 2015 8:22 PM To: Kuldeep Samasi (WT01 - Global Media & Telecom) Cc: dev at dpdk.org; dev-bounces at dpdk.org Subject: Re: [dpdk-dev] PMD architecture related to code On Fri, Mar 13, 2015 at 04:45:47AM +, kuldeep.samasi at wipro.com wrote: > Hi Developer Team , > > > I am trying add new functionality on Poll Mode driver . > But I don't have idea how packets are coming to kernel mode and going to user > space and doing packet processing DPDK . The packets never go into the kernel when DPDK is in use. Instead the DPDK PMD configures the NIC to DMA the packets directly into userspace buffers. Hence the high performance. /Bruce > > I need suggestion on which file the PMD architecture defined . > > > > Regards , > Kuldeep > The information contained in this electronic message and any > attachments to this message are intended for the exclusive use of the > addressee(s) and may contain proprietary, confidential or privileged > information. If you are not the intended recipient, you should not > disseminate, distribute or copy this e-mail. Please notify the sender > immediately and destroy all copies of this message and any > attachments. WARNING: Computer viruses can be transmitted via email. > The recipient should check this email and any attachments for the > presence of viruses. The company accepts no liability for any damage > caused by any virus transmitted by this email. www.wipro.com The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com
[dpdk-dev] pktgen rx errors with intel 82599
Hi Matt
On 3/13/15, 3:49 PM, "Matt Smith" wrote:
>
>Hi,
>
>I?ve been using DPDK pktgen 2.8.0 (built against DPDK 1.8.0 libraries) to
>send traffic on a server using an Intel 82599 (X520-2). Traffic gets sent
>out port 1 through another server which also an Intel 82599 installed and
>is forwarded back into port 0. When I send using a single source and
>destination IP address, this works fine and packets arrive on port 0 at
>close to the maximum line rate.
>
>If I change port 1 to range mode and send traffic from a range of source
>IP addresses to a single destination IP address, for a second or two the
>display indicates that some packets were received on port 0 but then the
>rate of received packets on the display goes to 0 and all incoming
>packets on port 0 are registered as rx errors.
>
>The server that traffic is being forwarded through is running the
>ip_pipeline example app. I ruled this out as the source of the problem by
>sending directly from port 1 to port 0 of the pktgen box. The issue still
>occurs when the traffic is not being forwarded through the other box.
>Since ip_pipeline is able to receive the packets and forward them without
>getting rx errors and it?s running with the same model of NIC as pktgen
>is using, I checked to see if there were any differences in
>initialization of the rx port between ip_pipeline and pktgen. I noticed
>that pktgen has a setting that ip_pipeline doesn't:
>
>const struct rte_eth_conf port_conf = {
>.rxmode = {
>.mq_mode = ETH_MQ_RX_RSS,
>
>If I comment out the .mq_mode setting and rebuild pktgen, the problem no
>longer occurs and I now receive packets on port 0 at near line rate when
>testing from a range of source addresses.
>
>I recall reading in the past that if a receive queue fills up on an 82599
>, that receiving stalls for all of the other queues and no more packets
>can be received. Could that be happening with pktgen? Is there any
>debugging I can do to help track it down?
I have seen this problem on some platforms a few times and it looks like
you may have found a possible solution to the problem. I will have to look
into the change and see if this is the problem, but it does seem to
suggest this may be the issue. When the port gets into this state the port
receives the number mbufs matching the number of descriptors and the rest
are ?missed? frames at the wire. The RX counter is the number of missed
frames.
Thanks for the input
++Keith
>
>The command line I have been launching pktgen with is:
>
>pktgen -c f -n 3 -m 512 -- -p 0x3 -P -m 1.0,2.1
>
>Thanks,
>
>-Matt Smith
>
>
>
>
>
[dpdk-dev] pktgen rx errors with intel 82599
Hi Matt,
On 3/14/15, 8:47 AM, "Wiles, Keith" wrote:
>Hi Matt
>
>On 3/13/15, 3:49 PM, "Matt Smith" wrote:
>
>>
>>Hi,
>>
>>I?ve been using DPDK pktgen 2.8.0 (built against DPDK 1.8.0 libraries) to
>>send traffic on a server using an Intel 82599 (X520-2). Traffic gets sent
>>out port 1 through another server which also an Intel 82599 installed and
>>is forwarded back into port 0. When I send using a single source and
>>destination IP address, this works fine and packets arrive on port 0 at
>>close to the maximum line rate.
>>
>>If I change port 1 to range mode and send traffic from a range of source
>>IP addresses to a single destination IP address, for a second or two the
>>display indicates that some packets were received on port 0 but then the
>>rate of received packets on the display goes to 0 and all incoming
>>packets on port 0 are registered as rx errors.
>>
>>The server that traffic is being forwarded through is running the
>>ip_pipeline example app. I ruled this out as the source of the problem by
>>sending directly from port 1 to port 0 of the pktgen box. The issue still
>>occurs when the traffic is not being forwarded through the other box.
>>Since ip_pipeline is able to receive the packets and forward them without
>>getting rx errors and it?s running with the same model of NIC as pktgen
>>is using, I checked to see if there were any differences in
>>initialization of the rx port between ip_pipeline and pktgen. I noticed
>>that pktgen has a setting that ip_pipeline doesn't:
>>
>>const struct rte_eth_conf port_conf = {
>>.rxmode = {
>>.mq_mode = ETH_MQ_RX_RSS,
>>
>>If I comment out the .mq_mode setting and rebuild pktgen, the problem no
>>longer occurs and I now receive packets on port 0 at near line rate when
>>testing from a range of source addresses.
>>
>>I recall reading in the past that if a receive queue fills up on an 82599
>>, that receiving stalls for all of the other queues and no more packets
>>can be received. Could that be happening with pktgen? Is there any
>>debugging I can do to help track it down?
>
>I have seen this problem on some platforms a few times and it looks like
>you may have found a possible solution to the problem. I will have to look
>into the change and see if this is the problem, but it does seem to
>suggest this may be the issue. When the port gets into this state the port
>receives the number mbufs matching the number of descriptors and the rest
>are ?missed? frames at the wire. The RX counter is the number of missed
>frames.
>
>Thanks for the input
>++Keith
I added code to hopefully setup the correct RX/TX conf values. The HEAD of
the Pktgen-DPDK v2.8.4 should build and work with DPDK 1.8.0 or 2.0.0-rc1.
I did still see some RX errors and reduced bit rate, but the traffic does
not stop on my machine. Please give version 2.8.4 a try and let me know if
you still see problems.
Regards,
++Keith
>>
>>The command line I have been launching pktgen with is:
>>
>>pktgen -c f -n 3 -m 512 -- -p 0x3 -P -m 1.0,2.1
>>
>>Thanks,
>>
>>-Matt Smith
>>
>>
>>
>>
>>
>
>
>
[dpdk-dev] Symmetric RSS Hashing, Part 2
A few months ago we had this thread about symmetric hashing of TCP in RSS: http://dpdk.org/ml/archives/dev/2014-December/010148.html I was wondering if we ever did figure out how to get the 0x6d5a hash key mentioned in there to work, or another alternative one. Thanks, Matthew.
