Missed the patch. Please find the patch.
diff --git a/examples/l3fwd-acl/main.c b/examples/l3fwd-acl/main.c
index 9b2c21b..8a5dde8 100644
--- a/examples/l3fwd-acl/main.c
+++ b/examples/l3fwd-acl/main.c
@@ -85,6 +85,8 @@
#define MBUF_SIZE (2048 + sizeof(struct rte_mbuf) + RTE_PKTMBUF_HEADROOM)
+
Hi All,
I am trying to add new acl rule support to filter the packets based on TCP
flags. I have followed the structure updates as per DPDK Programmers guide. I
have attached the code diff along with this mail.
Some how packet filtering is not happening with our modifications.
Input configura
On 25/07/14 10:43, Thomas Monjalon wrote:
>> On 24/07/14 07:59, Matthew Hall wrote:
>>> I ran into some weird symbol conflicts between system netinet/in.h and DPDK
>>> rte_ip.h. They have a lot of duplicated definitions for stuff like
>>> IPPROTO_IP
>>> and so on. This breaks when you want to use
v2 change:
- Resolve conflicts wiht the tip code;
- And resolve 2 issues:
-- fix mbuf leak when discard a uncompleted packet.
-- refine pkt.data to point to actual payload data start point.
v1 change:
This patch supports mergeable buffer feature in DPDK based virtio PMD, which can
rece
Acked-by: Tommy Long
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Huawei Xie
Sent: Friday, July 18, 2014 10:56 AM
To: dev at dpdk.org
Subject: [dpdk-dev] [PATCH v2] lib/librte_vhost: vhost library support to
facilitate integration with vswitch.
Signed-off-by:
Hi all,
2014-07-24 22:55, Antti Kantee:
> On 24/07/14 07:59, Matthew Hall wrote:
> > I ran into some weird symbol conflicts between system netinet/in.h and DPDK
> > rte_ip.h. They have a lot of duplicated definitions for stuff like
> > IPPROTO_IP
> > and so on. This breaks when you want to use in
The driver must listen to broadcast packets, like other devices.
Otherwise protocols like ARP won't work!
Signed-off-by: Stephen Hemminger
--- a/lib/librte_pmd_vmxnet3/vmxnet3_ethdev.c 2014-07-25 10:49:18.720201127
-0700
+++ b/lib/librte_pmd_vmxnet3/vmxnet3_ethdev.c 2014-07-25 10:49:18.720
Fix a couple of issues with my earlier igb_uio stuff:
1. With MSI (like MSI-X) actual IRQ number is not known until
after the pci_enable_msi() is done.
2. If INTX fails, fall back to running without IRQ.
This allows usermode PCI to recover and run without out IRQ
for cases where PCI INTX s
Add more compatibility wrappers, and split out all the wrapper
code to a separate file. Builds on Debian Squeeze (2.6.32) which
is oldest version of kernel current DPDK supports.
Signed-off-by: Stephen Hemminger
---
lib/librte_eal/linuxapp/igb_uio/compat.h | 103 ++
>
> I don't know if it will work right on both Linux and BSD and/or if they also
> 100% agree with the libc / glibc values compiled into the
> system's .so files. That's the risk that you run if you don't have more
> complete support in the DPDK itself for these features.
Looking at linux and
Thanks!
I have found the problem. It is that I used clock_gettime() to measure the
latency. With rte_rdtsc(), the round trip latency is measured to be less
than 10 microseconds.
Thanks very much,
Kai
On Thu, Jul 24, 2014 at 8:48 AM, Wodkowski, PawelX <
pawelx.wodkowski at intel.com> wrote:
> R
On Thu, 24 Jul 2014 23:50:43 +0200
Thomas Monjalon wrote:
> 2014-07-22 15:07, Thomas Monjalon:
> > The compilation with old kernels should be fixed now.
> > If some distributions have backported the new PCI config locking functions,
> > the compilation may fail. Please report such errors.
>
> Co
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ouyang Changchun
> Sent: Friday, July 25, 2014 2:03 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v2] virtio: Support mergeable buffer in virtio PMD
>
> v2 change:
> - Resolve conflicts wiht the tip co
If the bare metal mode is getting yanked, then I think we can go with Antti's
advice and just yank the conflicting symbols and use the system versions.
--
Sent from my mobile device.
On July 25, 2014 7:40:02 AM PDT, Antti Kantee wrote:
>On 25/07/14 10:43, Thomas Monjalon wrote:
>>> On 24/07/14
Hello,
We also notice these conflicts, we just planned to fix it in our new feature
development. The proposal is like:
#ifndef _NETINET_IN_H
#ifndef _NETINET_IN_H_
#define IPPROTO_IP 0
... ...
#define IPPROTO_MAX 256
#endif
#endif
Do you think it is a good idea?
> -Original Messag
15 matches
Mail list logo