On Mon, Nov 14, 2016 at 2:28 PM, ?? wrote:
> Hi all,
>
>
> I have two threads process the packets with different ways. thread A (core 0)
> is very heavy, thread B (core 1) is very light. If I just run each of them,
> their throughput is huge different with small packet. Thread A polls queue 0
> -Original Message-
> From: Yuanhan Liu [mailto:yuanhan.liu at linux.intel.com]
> Sent: Monday, September 05, 2016 12:10 AM
> To: Kyle Larose
> Cc: dev at dpdk.org; huawei.xie at intel.com; jianfeng.tan at intel.com
> Subject: Re: virtio kills qemu VM after stopp
> -Original Message-
> From: Tan, Jianfeng [mailto:jianfeng.tan at intel.com]
> Sent: Friday, September 02, 2016 2:56 AM
> To: Kyle Larose; dev at dpdk.org
> Cc: huawei.xie at intel.com; yuanhan.liu at linux.intel.com
> Subject: Re: virtio kills qemu VM after stopp
)
- Guest OS: CentOS Linux release 7.2.1511 (Core)
- Qemu-kvm version: 1.5.3-86.el7_1.6
Fixes: 9a0615af7746 ("virtio: fix restart")
Signed-off-by: Kyle Larose
---
drivers/net/virtio/virtio_ethdev.c | 10 --
drivers/net/virtio/virtio_pci.h| 1 +
2 files changed, 9 insertions(
Hello everyone,
In my own testing, I recently stumbled across an issue where I could get qemu
to exit when sending traffic to my application. To do this, I simply needed to
do the following:
1) Start my virtio interfaces
2) Send some traffic into/out of the interfaces
3) Stop the interfaces
4)
Hello Wei,
On Tue, Aug 2, 2016 at 2:59 AM, Zhao1, Wei wrote:
> Hi, Wujingjing and Kyle Larose
>
>
>
>> -Original Message-
>> From: Zhao1, Wei
>> Sent: Tuesday, August 2, 2016 11:27 AM
>> To: Wu, Jingjing ; Lu, Wenzhuo
>>
>> Cc: dev at dp
On Fri, Jul 29, 2016 at 4:50 AM, Wei Zhao1 wrote:
> rx_good_bytes and rx_good_packets statistic is inconsistent when port
> stopped,ipackets statistic is minus the discard packets but rx_bytes
> statistic not.Also,i40e has no statistic of discard bytes, so we have to
> delete discard packets item
On Mon, Mar 21, 2016 at 10:52 AM, Bruce Richardson
wrote:
> On Sun, Mar 20, 2016 at 08:18:57PM +0100, Thomas Monjalon wrote:
>> 2016-03-20 14:17, Zhang, Helin:
>> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
>> > > 2016-03-18 10:16, Stephen Hemminger:
>> > > > Right now, all
Hello,
On Sun, Mar 13, 2016 at 10:38 AM, ?? wrote:
> Hi all,
> When I use the dpdk lookup function, I met the segment fault problem. Can
> anybody help to look at why this happens. I will put the aim what I want to
> do and the related piece of code, and my debug message,
>
>
> This problem
On Wed, Mar 9, 2016 at 4:37 PM, Bruce Richardson
wrote:
> On Fri, Mar 04, 2016 at 08:25:07AM -0500, Kyle Larose wrote:
>> On Fri, Mar 4, 2016 at 3:11 AM, Tom Kiely wrote:
>> > Sure.
>> >Tom
>> >
>> >
>> > On 03/04/2016 06:16 AM, Xie, Huaw
and introducing a delay in a secondary stage.
Without the fix, the process stops receiving packets fairly quicky. With the
fix, it continues to receive packets.
Signed-off-by: Kyle Larose
---
v2:
* Added missing sign-off.
* Cleaned up the commit message a bit.
---
drivers/net/virtio
On Fri, Mar 4, 2016 at 3:11 AM, Tom Kiely wrote:
> Sure.
>Tom
>
>
> On 03/04/2016 06:16 AM, Xie, Huawei wrote:
>>
>> On 2/23/2016 12:23 AM, Tom Kiely wrote:
>>>
>>> Hi,
>>> Sorry I missed the last few messages until now. I'm happy with
>>> just removing the "if". Kyle, when you say you
eed different ops
pointers.
-Original Message-
From: Kyle Larose
Sent: Friday, February 26, 2016 11:47 AM
To: 'dev at dpdk.org'
Subject: client_server example application crash with virtio
I just ran into an issue trying to run the client server example application
using virito. W
I just ran into an issue trying to run the client server example application
using virito. Whenever the client (running as a secondary process) tried to
send packets, it would crash. I traced the issue to an invalid vtpci_ops
structure:
(gdb) p *vq->hw->vtpci_ops
$6 = {
read_dev_cfg =
On Fri, Feb 26, 2016 at 9:35 AM, Igor Ryzhov wrote:
> Hello, Harry.
>
> Understood about size of packets. It's a bit confusing, because in all other
> drivers undersized packet is an error. Maybe we should add another one size
> bin for virtio - 60 to 63 bytes?
>
I'm not sure we need to add a
On Tue, Jan 5, 2016 at 2:13 AM, Xie, Huawei wrote:
> On 12/17/2015 7:18 PM, Tom Kiely wrote:
>>
>>
>> On 11/25/2015 05:32 PM, Xie, Huawei wrote:
>>> On 11/13/2015 5:33 PM, Tom Kiely wrote:
If all rx descriptors are processed while transient
mbuf exhaustion is present, the rx ring ends
On Tue, Feb 2, 2016 at 7:44 AM, Tahhan, Maryam
wrote:
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Matthew Hall
>> Sent: Friday, January 22, 2016 8:49 PM
>> To: Igor Ryzhov
>> Cc: dev at dpdk.org
>> Subject: Re: [dpdk-dev] Future Direction for rte_eth_stats_get()
>>
>> On Fri, Jan
Hi Harry,
On Wed, Jan 20, 2016 at 9:45 AM, Van Haaren, Harry
wrote:
> Hi Kyle,
>
> In theory we could create a new API for this, but I think the current xstats
> API is a good fit for exposing this info, so why create extra APIs? As a
> client of the DPDK API, I would prefer more statistics
On Wed, Jan 20, 2016 at 9:28 AM, Harry van Haaren
wrote:
> This patch exposes link duplex, speed, and status via the
> existing xstats API.
>
I'm slightly confused by this. Why are we exposing operational
properties of the chip through an API which I thought was primarily
targeting statistics?
On Mon, Dec 14, 2015 at 2:17 PM, Aaron Conole wrote:
> No need to donate to the cause on this one, I think :) The issues
> surrounding tcpdump are, imo, ones of library/application workflow. HOW
> does the user enable tcpdump-like support? The current option is to
> start up with a pcap PMD
On Tue, Dec 1, 2015 at 8:42 AM, Matthew Hall wrote:
> I am planning to use this to do the captures so you don't incur the headache
> or performance issues with rte_kni.
>
> I am curious how I might be able to link it up w/ the standard libpcap based
> tools to get an end-to-end solution with
Hi Tim,
On Mon, Nov 30, 2015 at 3:50 PM, O'Driscoll, Tim
wrote:
> Tcpdump Support: Support for tcpdump will be added to DPDK. This will improve
> usability and debugging of DPDK applications.
I'm curious about the proposed tcpdump support. Is there a concrete plan for
this, or is that still
On Wed, Nov 25, 2015 at 11:47 PM, Younghwan Go wrote:
> Hello,
>
> Thank you all for helping us understand on issues with no hugepage option.
>
> As Konstantin mentioned at the end, I tried using VFIO module instead of IGB
> UIO module. I enabled all necessary parameters (IOMMU, virtualization,
>
On Tue, Nov 3, 2015 at 6:28 PM, Stephen Hemminger
wrote:
>
> No. configuration is the enemy of usability.
> Why does DPDK have to behave differently than BSD and Linux, what possible
> value could this be to the end user?
I honestly can't think of any good reasons for why a user would need
On Tue, Nov 3, 2015 at 5:05 PM, Stephen Hemminger
wrote:
>
> IMHO this is a bug. Other drivers don't include the CRC, and the Intel driver
> only includes CRC in count for one direction, and depends on value of
> stripping flag.
>
> I sent a patch to fix this because our customers didn't like
On Thu, Oct 29, 2015 at 10:01 AM, Thomas Monjalon
wrote:
> So what is missing currently? Just having a consistent naming of
> similar counters?
A consistent naming scheme would certainly solve the problem.
Thanks again,
Kyle
Stephen,
Ultimately the issue we are trying to solve is that there is no device
independent way to get any detailed statistics from NICs controlled by
DPDK. These statistics are quite useful, not just for diagnostics, but
for long term reporting. People using DPDK-based NFV products in a
On Tue, Oct 20, 2015 at 2:12 AM, ??? wrote:
> Dear DPDK experts.
>
> Thank you very much for your best great efforts and precious answers.
>
>
> When I run test-pmd, most of received packets are RX-error.
>
> The computer has two 10GbE ports Intel NIC and the two ports are loop-backed
> each
Hello,
I have a system using dpdk 1.8 with 82599ES ixgbe NICs. These are
provided to a virtual guest via pci passthrough. Our dpdk application
on the guest takes control of the NICs using igb_uio.
On certain systems, under conditions we have not yet figured out,
sending traffic causes the host
All of this information is in shared memory, is it not? For example,
you could patch the ring library to give a programmable interface to
the following function:
http://dpdk.org/doc/api/rte__ring_8h.html#a7bfcef0ad324fcc4c03bcb59cd7e867f.
This would allow you to see the full set of rings in a
On Mon, Sep 21, 2015 at 9:45 AM, Van Haaren, Harry
wrote:
>> From: Igor Ryzhov [mailto:iryzhov at arccn.ru]
>> Thank you, I'll wait for result of mspdc testing.
>
> Hi Igor,
>
> Regarding your original question:
> The datasheet says that a packet with total size < 32 bytes is
> discarded by MAC
Hi Huawei,
> Kyle:
> Could you tell us how did you produce this issue, very small pool size
> or you are using pipeline model?
If I understand correctly, by pipeline model you mean a model whereby
multiple threads handle a given packet, with some sort IPC (e.g. dpdk
rings) between them? If so,
On Sun, Sep 13, 2015 at 5:43 PM, Thomas Monjalon
wrote:
>
> Hi,
>
> 2015-09-11 12:32, Kyle Larose:
> > Looking through the version tree for virtio_rxtx.c, I saw the following
> > commit:
> >
> > http://dpdk.org/browse/dpdk/commit/lib/librte_pmd_virtio?id=8c09
Hi all,
I've been debugging an issue we see occasionally when under load. We have a
non-DPDK linux-bridge host sending to our guest via vhost-net. The guest is
running a DPDK 1.8 application using virtio PMDs.
The symptoms of the problem are that host interfaces report all packets
sent to the
On Mon, Sep 7, 2015 at 7:44 AM, Tahhan, Maryam
wrote:
> > From: Olivier MATZ [mailto:olivier.matz at 6wind.com]
> > Sent: Monday, September 7, 2015 9:30 AM
> > To: Tahhan, Maryam; Andriy Berestovskyy
> > Cc: dev at dpdk.org
> > Subject: Re: ixgbe: account more Rx errors Issue
> >
> > Hi,
> >
> >
Are you reading from the pcap faster than the device can transmit? Does the
app hold off reading from the pcap when the ethdev is pushing back, or does
it just tail drop?
On Fri, Sep 4, 2015 at 12:14 AM, Yerden Zhumabekov
wrote:
> Hello,
>
> Did anyone try to work with pcap PMD recently? We're
Hi Maryam,
I was not aware of the proc_info app. Is there any documentation on dpdk.org
about it, or should I browse the code?
Thanks,
Kyle
On Fri, Jun 26, 2015 at 10:30 AM, Tahhan, Maryam
wrote:
>
>
> On Fri, Jun 26, 2015 at 8:59 AM, Maryam Tahhan
> wrote:
>
> Remove non generic stats in
On Fri, Jun 26, 2015 at 8:59 AM, Maryam Tahhan
wrote:
> Remove non generic stats in rte_stats_strings and mark the relevant
> fields in struct rte_eth_stats as deprecated.
>
> Signed-off-by: Maryam Tahhan
> ---
> doc/guides/rel_notes/abi.rst | 11 +++
> lib/librte_ether/rte_ethdev.c |
On Wed, Jun 17, 2015 at 9:58 AM, Thomas Monjalon
wrote:
[...]
>
> You are extending the generic stats. This is not the idea behind xstats.
> The xstats are specific to the driver.
> Furthermore we should migrate some "not really generic stats" to xstats
> in order to keep only the really basic
I'm fairly new to dpdk, so I may be completely out to lunch on this, but
here's an idea to possibly improve performance compared to a straight copy
of the entire packet. If this idea makes sense, perhaps it could be added
to the mbuf library as an extension of the clone functionality?
If you are
40 matches
Mail list logo
