Coverity issue reported like
CID 119268 (#1 of 1): Unintended sign extension
(SIGN_EXTENSION)sign_extension: Suspicious implicit sign extension:
vsi_id with type unsigned short (16 bits, unsigned) is promoted in
vsi_id << 23 to type int (32 bits, signed), then sign-extended to type
unsigned long (6
On Tue, Dec 15, 2015 at 05:21:25PM +0300, Pavel Fedin wrote:
> Hello!
>
> > I'm thinking you can't simply unlink a file given by a user inside
> > a libraray unconditionaly. Say, what if a user gives a wrong socket
> > path?
>
> Well... We can improve the security by checking that:
>
> a) The
On Tue, Dec 15, 2015 at 04:07:57PM +0100, Thibaut Collet wrote:
> After a migration, to avoid netwotk outage, all interfaces of the guest
> must send a packet to update switches mapping (ideally a GARP).
> As some interfaces do not do it QEMU does it in behalf of the guest by
> sending a RARP (his
On Wed, Dec 16, 2015 at 10:38:03AM +0800, Peter Xu wrote:
> On Tue, Dec 15, 2015 at 04:07:57PM +0100, Thibaut Collet wrote:
> > After a migration, to avoid netwotk outage, all interfaces of the guest
> > must send a packet to update switches mapping (ideally a GARP).
> > As some interfaces do not d
On Tue, Dec 15, 2015 at 09:53:18AM -0700, Alex Williamson wrote:
> On Tue, 2015-12-15 at 13:43 +, O'Driscoll, Tim wrote:
> > > -Original Message-
> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Alex
> > > Williamson
> > > Sent: Friday, December 11, 2015 11:03 PM
> > > To:
Hello!
> 1. if vhost-user backend (or say, DPDK) supports GUEST_ANNOUNCE, and
>send another RARP (or say, GARP, I will use RARP as example),
>then there will be two RARP later on the line, right? (since the
>QEMU one is sent unconditionally from qemu_announce_self).
qemu_announce_se
On Tue, Dec 15, 2015 at 05:58:28PM +0300, Pavel Fedin wrote:
> Hello!
>
> > No idea. Maybe you have changed some other configures (such as of ovs)
> > without notice? Or, the ovs bridge interface resets?
>
> I don't touch the ovs at all. Just shut down the guest, rebuild the qemu,
> reinstall
On Mon, Dec 14, 2015 at 6:30 PM, Santosh Shukla wrote:
> This patch set add basic infrastrucure to run virtio-net-pci pmd driver for
> arm64/arm. Tested on ThunderX platfrom. Verified for existing dpdk(s) test
> applications like:
> - ovs-dpdk-vhost-user: across the VM's, for the use-cases like g
Hi Alex,
> On Wed, 2015-12-16 at 04:04 +, Ferruh Yigit wrote:
> > On Tue, Dec 15, 2015 at 09:53:18AM -0700, Alex Williamson wrote:
> > I tested the DPDK (HEAD of master) with the patch, with help of
> > Anatoly, and DPDK works in no-iommu environment with a little
> > modification.
> >
> > Bas
[Change log]
PATCH v1:
(Just listing functionality changes and important bug fix)
* Support virtio-net interrupt handling.
(It means virtio-net PMD on host and guest have same virtio-net features)
* Fix memory allocation method to allocate contiguous memory correctly.
* Port Hotplug is supported
This option is for allocating physically contiguous memory for EAL.
EAL will provide only one file descriptor for the memory.
So far, this memory will be used by virtio-net PMD on host or container.
DPDK already has had "RTE_EAL_SINGLE_FILE_SEGMENTS" compile option.
It allows us to create one file
The patch adds a new virtio-net PMD configuration that allows the PMD to
work on host as if the PMD is in VM.
Here is new configuration for virtio-net PMD.
- CONFIG_RTE_LIBRTE_VIRTIO_HOST_MODE
To use this mode, EAL needs physically contiguous memory. To allocate
such memory, enable below option, a
Hello Santosh,
On Wed, Dec 16, 2015 at 8:48 AM, Santosh Shukla wrote:
> Hi Yuanhan, Huawei and Others.
>
> I got arch specific review comment from arm maintainers and I am waiting
> for your review feedback on virtio specific patches? Is v3 patch and virtio
> iopci bar mapping to user-space appr
Hi Przemek,
We have configured the accelerated data path between a physical interface
to the VM using openvswitch netdev-dpdk with vhost-user support. The VM
created with this special data path and vhost library, I am calling as
DPDK instance.
If assigning ip manually to the newly created Ci
Fix missing link in the Linux GSG, accidentally removed
in previous merge:
WARNING: undefined label: linux_gsg_compiling_dpdk
Fixes: 29c673401c4d ("doc: improve Linux guide layout")
Signed-off-by: John McNamara
---
doc/guides/linux_gsg/build_dpdk.rst | 2 ++
1 file changed, 2 insertions(+)
On Mon, Dec 14, 2015 at 05:36:13PM -0500, Matthew Hall wrote:
> On Mon, Dec 14, 2015 at 04:29:41PM -0500, Kyle Larose wrote:
> > I've seen lots of ideas and options tossed around which would solve
> > some or all of the above items, but nobody actually committing to
> > anything. What can we do to
> -Original Message-
> From: Mcnamara, John
> Sent: Wednesday, December 16, 2015 10:43 AM
> To: dev at dpdk.org
> Cc: Iremonger, Bernard ; Mcnamara, John
>
> Subject: [PATCH] doc: fix missing link target
>
> Fix missing link in the Linux GSG, accidentally removed in previous merge:
>
>
2 points from our experience in saving pcap files from a dpdk 10G fire hose:
1)
Our capture module provides a small "bit-vector" to the code that handles
the packets.
Since our packet processing code is already finding out basic stuff about
the packet traversing it (is it IPv4? v6? is it TCP? is
Bruce,
This doesn't really sound like tcpdump to me; it sounds like port mirroring.
Your suggestion is limited to physical ports only, and cannot be attached
further inside the application, e.g. for mirroring packets related to a
specific VLAN.
Furthermore, it doesn't sound like the filtering
On Wed, Dec 16, 2015 at 2:17 PM, David Marchand
wrote:
> Hello Santosh,
>
> On Wed, Dec 16, 2015 at 8:48 AM, Santosh Shukla wrote:
>>
>> Hi Yuanhan, Huawei and Others.
>>
>> I got arch specific review comment from arm maintainers and I am waiting
>> for your review feedback on virtio specific pat
On Wed, Dec 16, 2015 at 12:40:43PM +0100, Morten Br?rup wrote:
> Bruce,
>
> This doesn't really sound like tcpdump to me; it sounds like port mirroring.
It's actually a bit of both, in my opinion, it's designed to allow basic
mirroring
of traffic on a port to allow that traffic to be sent to a t
Great idea, Arnon. Let?s look at existing use cases from the real world.
Our company makes network appliances. They are not running GNU/Linux or
similar, so they do not offer a BASH prompt or any other BSD/Linux like command
line interface.
Here?s a simplified description of how the user in
Hello!
> I can reproduce your issue on my side with above patch (and only when
> F_GUEST_ANNOUNCE is not set at DPDK vhost lib). TBH, I don't know
> why that happened, the cause could be subtle, and I don't think it's
> worthwhile to dig it, especially it's not the right way to do it.
May be no
On Wed, Dec 16, 2015 at 02:57:15PM +0300, Pavel Fedin wrote:
> Hello!
>
> > I can reproduce your issue on my side with above patch (and only when
> > F_GUEST_ANNOUNCE is not set at DPDK vhost lib). TBH, I don't know
> > why that happened, the cause could be subtle, and I don't think it's
> > wort
Bruce,
Please note that tcpdump is a stupid name for a packet capture application that
supports much more than just TCP.
I had missed the point about ethdev supporting virtual interfaces, so thank you
for pointing that out. That covers my concerns about capturing packets inside
tunnels.
I wil
x86 requires a special set of instructions to access ioports, but other
architectures let you remap io resources.
So let eal remap io resources by accepting IORESOURCE_IO flag for
architectures other than x86.
Signed-off-by: David Marchand
---
lib/librte_eal/common/include/rte_pci.h |3 ++-
Hello!
> However, I'm more curious about the ping loss? Did you still see
> that? And to be more specific, have the wireshark captured the
> GRAP from the guest?
Yes, everything is fine.
root at nfv_test_x86_64 /var/log/libvirt/qemu # tshark -i ovs-br0
Running as user "root" and group "root".
On Wed, Dec 16, 2015 at 01:31:04PM +0100, David Marchand wrote:
> x86 requires a special set of instructions to access ioports, but other
> architectures let you remap io resources.
> So let eal remap io resources by accepting IORESOURCE_IO flag for
> architectures other than x86.
One question: th
On Wed, Dec 16, 2015 at 03:43:06PM +0300, Pavel Fedin wrote:
> rYR8N8f/ookveMRL7BfPnj5lw+EJZd+uG+v/lZnBuWidyQ4r
> g586/P1rPsQw8p6wT+M7LnqvMLZM9eWq2ht53Bd5liqxFGckGmoxFxUnAgC5sFKthAIAAA==
> Status: O
> Content-Length: 4853
> Lines: 66
>
> Hello!
>
> > However, I'm more curious about the pin
On Wed, Dec 16, 2015 at 01:26:11PM +0100, Morten Br?rup wrote:
> Bruce,
>
> Please note that tcpdump is a stupid name for a packet capture application
> that supports much more than just TCP.
>
> I had missed the point about ethdev supporting virtual interfaces, so thank
> you for pointing that
On Wed, Dec 16, 2015 at 01:31:04PM +0100, David Marchand wrote:
> x86 requires a special set of instructions to access ioports, but other
> architectures let you remap io resources.
> So let eal remap io resources by accepting IORESOURCE_IO flag for
> architectures other than x86.
>
> Signed-off-b
Bruce,
On Wed, Dec 16, 2015 at 2:15 PM, Bruce Richardson <
bruce.richardson at intel.com> wrote:
>
> > +#if defined(RTE_ARCH_X86_64) || defined(RTE_ARCH_I686)
> > + /* x86 can not remap ioports, so skip it, remapping code
> will
> > + * look at dev->mem_resource[i].phys_a
On Mon, Dec 14, 2015 at 06:30:30PM +0530, Santosh Shukla wrote:
> Introducing module to mmap iopci bar region. Applicable for linuxapp for
> non-x86
> archs, Tested for arm64/ThunderX platform for linux. For that adding two
> global
> api.
> - virtio_ioport_init
> - virtio_ioport_unmap
>
> Signe
Yuanhan,
On Wed, Dec 16, 2015 at 1:48 PM, Yuanhan Liu
wrote:
> On Wed, Dec 16, 2015 at 01:31:04PM +0100, David Marchand wrote:
> > x86 requires a special set of instructions to access ioports, but other
> > architectures let you remap io resources.
> > So let eal remap io resources by accepting
On Wed, Dec 16, 2015 at 02:34:35PM +0100, David Marchand wrote:
> Yuanhan,
>
> On Wed, Dec 16, 2015 at 1:48 PM, Yuanhan Liu
> wrote:
>
> On Wed, Dec 16, 2015 at 01:31:04PM +0100, David Marchand wrote:
> > x86 requires a special set of instructions to access ioports, but other
> > arc
On Mon, Dec 14, 2015 at 06:30:24PM +0530, Santosh Shukla wrote:
> In x86 case io_base to store ioport address not more than 65535 ioports.
> i.e..0
> to but in non-x86 case in particular arm64 it need to store more than 32
> bit address so changing io_base datatype from 32 to 64.
>
> Signed-
On Wed, Dec 16, 2015 at 6:18 PM, Yuanhan Liu
wrote:
> On Wed, Dec 16, 2015 at 01:31:04PM +0100, David Marchand wrote:
>> x86 requires a special set of instructions to access ioports, but other
>> architectures let you remap io resources.
>> So let eal remap io resources by accepting IORESOURCE_IO
On Wed, Dec 16, 2015 at 7:18 PM, Yuanhan Liu
wrote:
> On Mon, Dec 14, 2015 at 06:30:24PM +0530, Santosh Shukla wrote:
>> In x86 case io_base to store ioport address not more than 65535 ioports.
>> i.e..0
>> to but in non-x86 case in particular arm64 it need to store more than 32
>> bit addre
A new 'make install' wrongly assumes that the output module name is
always 'uname -r' even if RTE_KERNELDIR is passed.
# make install T=... DESTDIR=/tmp/dpdk
RTE_KERNELDIR=/lib/modules/3.16.0-4-amd64/build
...
# ls /tmp/dpdk/lib/modules/
4.2.0-18-generic
--
Regards
Piotr Bartosiewicz
ping?
W dniu 09.12.2015 o 14:19, Kamil Rytarowski pisze:
> Currently dpdk_nic_bind.py detects Linux kernel modules via reading
> /proc/modules. Built-in ones aren't listed there and therefore they are not
> being found by the script.
>
> Add support for checking built-in modules with parsing the s
On Wed, Dec 16, 2015 at 6:59 PM, Yuanhan Liu
wrote:
> On Mon, Dec 14, 2015 at 06:30:30PM +0530, Santosh Shukla wrote:
>> Introducing module to mmap iopci bar region. Applicable for linuxapp for
>> non-x86
>> archs, Tested for arm64/ThunderX platform for linux. For that adding two
>> global
>> ap
On Wed, Dec 16, 2015 at 07:31:57PM +0530, Santosh Shukla wrote:
> On Wed, Dec 16, 2015 at 7:18 PM, Yuanhan Liu
> wrote:
> > On Mon, Dec 14, 2015 at 06:30:24PM +0530, Santosh Shukla wrote:
> >> In x86 case io_base to store ioport address not more than 65535 ioports.
> >> i.e..0
> >> to but in
On Wed, Dec 16, 2015 at 07:50:51PM +0530, Santosh Shukla wrote:
...
> >> + *resource_addr = (void *)((char *)ioport_map +
> >> (ioport_map_cnt)*offset);
> >
> > Redundant (), and the void * cast seems to be unnecessary.
> >
>
> (void *) is unnecessary, but couldn't get the redundant() part?
On Wed, Dec 16, 2015 at 7:53 PM, Yuanhan Liu
wrote:
> On Wed, Dec 16, 2015 at 07:31:57PM +0530, Santosh Shukla wrote:
>> On Wed, Dec 16, 2015 at 7:18 PM, Yuanhan Liu
>> wrote:
>> > On Mon, Dec 14, 2015 at 06:30:24PM +0530, Santosh Shukla wrote:
>> >> In x86 case io_base to store ioport address no
On Wed, Dec 16, 2015 at 8:07 PM, Yuanhan Liu
wrote:
> On Wed, Dec 16, 2015 at 07:50:51PM +0530, Santosh Shukla wrote:
> ...
>> >> + *resource_addr = (void *)((char *)ioport_map +
>> >> (ioport_map_cnt)*offset);
>> >
>> > Redundant (), and the void * cast seems to be unnecessary.
>> >
>>
>> (v
On Wed, Dec 16, 2015 at 08:09:40PM +0530, Santosh Shukla wrote:
> On Wed, Dec 16, 2015 at 7:53 PM, Yuanhan Liu
> wrote:
> > On Wed, Dec 16, 2015 at 07:31:57PM +0530, Santosh Shukla wrote:
> >> On Wed, Dec 16, 2015 at 7:18 PM, Yuanhan Liu
> >> wrote:
> >> > On Mon, Dec 14, 2015 at 06:30:24PM +0530
On Wed, Dec 16, 2015 at 8:28 PM, Yuanhan Liu
wrote:
> On Wed, Dec 16, 2015 at 08:09:40PM +0530, Santosh Shukla wrote:
>> On Wed, Dec 16, 2015 at 7:53 PM, Yuanhan Liu
>> wrote:
>> > On Wed, Dec 16, 2015 at 07:31:57PM +0530, Santosh Shukla wrote:
>> >> On Wed, Dec 16, 2015 at 7:18 PM, Yuanhan Liu
>
Hi Thomas,
> > On Tue, Dec 15, 2015 at 09:53:18AM -0700, Alex Williamson wrote:
> > So it works. ?Is it acceptable? ?Useful? ?Sufficiently complete? ?Does
> > it imply deprecating the uio interface? ?I believe the feature that
> > started this discussion was support for MSI/X interrupts so that V
On Wed, 2015-12-16 at 08:35 +, Burakov, Anatoly wrote:
> Hi Alex,
>
> > On Wed, 2015-12-16 at 04:04 +, Ferruh Yigit wrote:
> > > On Tue, Dec 15, 2015 at 09:53:18AM -0700, Alex Williamson wrote:
> > > I tested the DPDK (HEAD of master) with the patch, with help of
> > > Anatoly, and DPDK wo
Hi Alex,
> On Wed, 2015-12-16 at 08:35 +, Burakov, Anatoly wrote:
> > Hi Alex,
> >
> > > On Wed, 2015-12-16 at 04:04 +, Ferruh Yigit wrote:
> > > > On Tue, Dec 15, 2015 at 09:53:18AM -0700, Alex Williamson wrote:
> > > > I tested the DPDK (HEAD of master) with the patch, with help of
> > >
On Wed, Dec 16, 2015 at 11:56:11AM +, Bruce Richardson wrote:
> Having this work with any application is one of our primary targets here.
> The app author should not have to worry too much about getting basic debug
> support. Even if it doesn't work at 40G small packet rates, you can get a
>
2015-10-25 22:59 GMT+01:00 Marc Sune :
> The current rte_eth_dev_info abstraction does not provide any mechanism to
> get the supported speed(s) of an ethdev.
>
> For some drivers (e.g. ixgbe), an educated guess could be done based on the
> driver's name (driver_name in rte_eth_dev_info), see:
>
>
We will test on Mellanox NICs
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Marc Sune
Sent: Wednesday, December 16, 2015 10:38 PM
To: dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH v6 0/5] ethdev: add speed capabilities and
refactor link API
2015-10-25 22:59 GMT
Bruce,
Matthew presented a very important point a few hours ago: We don't need tcpdump
support for debugging the application in a lab; we already have plenty of other
tools for debugging what we are developing. We need tcpdump support for
debugging network issues in a production network.
In my
On Wed, Dec 16, 2015 at 11:45:46PM +0100, Morten Br?rup wrote:
> Matthew presented a very important point a few hours ago: We don't need
> tcpdump support for debugging the application in a lab; we already have
> plenty of other tools for debugging what we are developing. We need tcpdump
> suppo
rte_get_log_type and rte_get_log_level functions has been avaliable
for many versions. But they are missing from the shared library map
and therefore do not get exported correctly.
Signed-off-by: Stephen Hemminger
---
lib/librte_eal/linuxapp/eal/rte_eal_version.map | 2 ++
1 file changed, 2 inse
This patch unlinks existing unused sockets (which cause new bindings to fail,
e.g. vHost PMD) to ensure smooth startup.
In a lot of cases DPDK applications are terminated abnormally without proper
resource release. Therefore, DPDK libs should be able to deal with unclean boot
environment.
Signe
57 matches
Mail list logo
