On 2016/04/18 3:27, Sharath wrote:
> I am facing feew compile errors while compiling dpdk. The env is ubuntu
> running as an VM, VM is started by qemu. How do I fix the compile errors?
Default qemu virtual cpu does not support SSE4.2.
Try qemu -cpu help, and specify your reasonable cpu.
Hi Tomasz,
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Tomasz Kulasek
> Sent: Friday, April 15, 2016 9:39 PM
> To: dev at dpdk.org
> Cc: Zhang, Helin; Ananyev, Konstantin
> Subject: [dpdk-dev] [PATCH] ixgbe: fix bad shift operation in
> ixgbe_set_pool_r
Hi,
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Tomasz Kulasek
> Sent: Friday, April 15, 2016 10:33 PM
> To: dev at dpdk.org
> Cc: Zhang, Helin; Ananyev, Konstantin
> Subject: [dpdk-dev] [PATCH] ixgbe: fix bad shift operation in
> ixgbe_set_pool_tx
>
>
Fix build failure since PAGE_SIZE is not defined on ARM (multiple values
are possible, so it needs to dynamically get the page size used).
Signed-off-by: Ricardo Salveti
---
drivers/net/xenvirt/rte_eth_xenvirt.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/xenvirt/rte_eth_x
It is hard for me to spot what exactly is missing, but while it was never
intended for trusty the version we have for xenial should get you going.
# all kind of dependencies
sudo apt-get install build-essential ubuntu-dev-tools debhelper dh-python
dh-systemd doxygen graphviz inkscape libcap-dev li
Hi,
Basically, you have to make sure you call rte_eth_tx_burst() every 100
ms in your forwarding loop. Here is such an example:
const uint64_t bond_tx_cycles = (rte_get_timer_hz() + MS_PER_S - 1) *
100 / MS_PER_S;
uint64_t cur_bond_cycles, diff_cycles;
uint64_t last_bond_tx_cycles = 0;
/* Insid
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Dmitriy Yakovlev
> Sent: Friday, April 15, 2016 11:59 PM
> To: dev at dpdk.org
> Cc: Dmitriy Yakovlev
> Subject: [dpdk-dev] [PATCH] cfgfile: fix return value comment
>
> Function rte_cfgfile_load can return N
Hi, Frasca,
> -Original Message-
> From: Michael Frasca [mailto:michael.frasca at oracle.com]
> Sent: Friday, April 15, 2016 3:32 AM
> To: Chen, Jing D
> Cc: dev at dpdk.org; Michael Frasca
> Subject: [PATCH] fm10k: set packet type for multi-segment packets
>
> When building a chain of mb
On 15/04/2016 23:56, Gopakumar Choorakkot Edakkunni wrote:
> This time the problem statement is more narrowed down.
>
> 1. dpdk is enabled on the interface, interfaces bound to igb_uio
> 3. kill the process using dpdk
> 3. rmmod rte_kni
> 4. rmmod igb_uio
> 5. bind interface to igb
> 6. ethtool, i
Dear DPDK exports.
I am Ick-Sung Choi living in South Korea.
Thank you very much for your contributions.
I studied a lot from your source codes.
However, actually I have a lot of codes/algorithms that I can't understand.
The codes seems to be incomplete, but it works in my test case.
If I take
Hi Mark,
Not a problem. I?ll post a v2 change with check for
RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE.
Thanks,
Michael
> On Apr 18, 2016, at 4:40 AM, Chen, Jing D wrote:
>
> Hi, Frasca,
>
>> -Original Message-
>> From: Michael Frasca [mailto:michael.frasca at oracle.com]
>> Sent: Friday, A
When building a chain of mbufs for a multi-segment packet, the
packet_type field resides at the end of the chain. It should be
copied forward to the head of the list.
Also, uses RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE to guard packet-type
computation. The mbuf fields are not copied when this define is
Hi Lazaros,
Looks ok to me in general, few comments below.
One more generic question - did you observe any performance impact
caused by these changes?
Konstantin
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Lazaros Koromilas
> Sent: Monday, April 04, 201
Hi,
> -Original Message-
> From: Michael Frasca [mailto:michael.frasca at oracle.com]
> Sent: Monday, April 18, 2016 8:52 PM
> To: Chen, Jing D
> Cc: dev at dpdk.org; Michael Frasca
> Subject: [PATCH v2] fm10k: set packet type for multi-segment packets
>
> When building a chain of mbufs
2016-03-31 19:15, Rasesh Mody:
> --- a/scripts/test-build.sh
> +++ b/scripts/test-build.sh
> @@ -116,6 +116,7 @@ config () #
> test "$DPDK_DEP_ZLIB" != y || \
> sed -ri 's,(BNX2X_PMD=)n,\1y,' $1/.config
> sed -ri's,(NFP_PMD=)n,\1y,'
2016-03-31 19:15, Rasesh Mody:
> --- a/config/common_base
> +++ b/config/common_base
> +CONFIG_RTE_LIBRTE_QEDE_RX_COAL_US=24
> +CONFIG_RTE_LIBRTE_QEDE_TX_COAL_US=48
It looks to be some tuning which could be done at runtime. Isn't it?
> +CONFIG_RTE_LIBRTE_QEDE_TX_SWITCHING=y
Is it possible to ena
Hi Ick-Sung,
Please see inline.
On Mon, Apr 18, 2016 at 2:14 PM, ??? wrote:
> If I take an example, the worker assignment method using & (not %) in
> load balancing was not fixed yet.
If the code works, there is nothing to fix, right? ;)
> Question #1) I would like to know how can I read/writ
Fix issue reported by Coverity.
Coverity ID 13302:
There may be a null pointer dereference, or else the comparison against
null is unnecessary.
In i40evf_config_vlan_pvid: All paths that lead to this null pointer
comparison already dereference the pointer earlier
Fixes: 2b12431b5369 ("i40e: add v
> -Original Message-
> From: Mrzyglod, DanielX T
> Sent: Tuesday, April 19, 2016 12:49 AM
> To: Chen, Jing D ; Wu, Jingjing intel.com>;
> Zhang, Helin
> Cc: dev at dpdk.org; Mrzyglod, DanielX T
> Subject: [PATCH] i40e: dereference before null check
>
> Fix issue reported by Coverity.
Fix issue reported by Coverity.
Coverity ID 13302:
There may be a null pointer dereference, or else the comparison against
null is unnecessary.
In i40evf_config_vlan_pvid: All paths that lead to this null pointer
comparison already dereference the pointer earlier
Fixes: 2b12431b5369 ("i40e: add v
2016-03-31 19:15, Rasesh Mody:
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -371,6 +371,13 @@ M: Declan Doherty
> F: drivers/crypto/aesni_gcm/
> F: doc/guides/cryptodevs/aesni_gcm.rst
>
> +QLogic qede PMD
> +M: Harish Patil
> +M: Rasesh Mody
> +M: Sony Chacko
> +F: drivers/net/qede/
> +F: d
I assume there is a leak somewhere on adding/removing vhost_user ports.
Although it could also be "only" a fragmentation issue.
Reproduction is easy:
I set up a pair of nicely working OVS-DPDK connected KVM Guests.
Then in a loop I
- add up to more 512 ports
- test connectivity between the t
On Mon, Apr 18, 2016 at 07:18:05PM +0200, Christian Ehrhardt wrote:
> I assume there is a leak somewhere on adding/removing vhost_user ports.
> Although it could also be "only" a fragmentation issue.
>
> Reproduction is easy:
> I set up a pair of nicely working OVS-DPDK connected KVM Guests.
> The
On Mon, Apr 18, 2016 at 10:46:50AM -0700, Yuanhan Liu wrote:
> On Mon, Apr 18, 2016 at 07:18:05PM +0200, Christian Ehrhardt wrote:
> > I assume there is a leak somewhere on adding/removing vhost_user ports.
> > Although it could also be "only" a fragmentation issue.
> >
> > Reproduction is easy:
>
>> Not sure this is the right way to handle it. The driver should
>> return an error rather than silently discard what the
>> application asked.
>
> I also think it should return an error with checking if the
> host is kernel driver, and crc strip is disabled in VF. Thank
> you David!
Thanks for
Hi,
Here I'd like to announce a new tree for vhost/virtio[0], and I'm
going to be the maintainer.
[0]: http://dpdk.org/browse/next/dpdk-next-virtio/
This is done by a private request to Thomas few days ago (well, I'd
confess this should have been a public request/discussion, and you
can fin
>
>2016-03-31 19:15, Rasesh Mody:
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -371,6 +371,13 @@ M: Declan Doherty
>> F: drivers/crypto/aesni_gcm/
>> F: doc/guides/cryptodevs/aesni_gcm.rst
>>
>> +QLogic qede PMD
>> +M: Harish Patil
>> +M: Rasesh Mody
>> +M: Sony Chacko
>> +F: drivers/net
27 matches
Mail list logo
