On Thu, Jun 18, 2015 at 08:37:46PM -0700, Matthew Hall wrote:
> dpdk/lib/librte_mbuf/rte_mbuf.h:68:20: error: poisoning existing macro
> [-Werror]
Hi all,
I finally figured out what happened. My older DPDK build configuration file
had defined the poisoned macros to try to enable the fe
On Jun 19, 2015, at 3:15 AM, Bruce Richardson
wrote:
> Thank you. It's finally nice to get some good news about compatibility! :-)
Hi Bruce,
I did manage to find just one weird issue when I was trying to use the new DPDK
v2.0.0. Previously I had code which was calling rte_eal_pci_probe() after
On Jun 21, 2015, at 3:54 PM, Tom Barbette wrote:
> Application call to rte_eal_pci_probe() is not needed anymore since DPDK 1.8.
>
> http://dpdk.org/ml/archives/dev/2014-September/005890.html
>
> You were not wrong before, it is just a change in DPDK. I came across the
> same problem a few days
Hello,
I have gone out on the internet for days looking at a bunch of different radix
tree implementations to see if I could figure a way to implement my own tree,
just to work around the really low 255 CIDR block limitation in librte_lpm.
Unfortunately every single one I could find falls into
On Jun 21, 2015, at 5:09 PM, Daeyoung Kim wrote:
> I am a newbie to DPDK.
Welcome!
> I'm making a packet capture program from the l3fwd
> sample application. When I tested my program in a virtual environment, it
> worked. But in a real world, it does not work correctly.
This topology is kind of
cked__));
> /* Using single uint8_t to store 3 values. */
> uint32_t valid :1; /**< Validation flag. */
> uint32_t ext_entry :1; /**< External entry. */
> uint32_t depth :6; /**< Rule depth. */
> };
> so we have 24 bit for next_h
On Mon, Jun 22, 2015 at 11:51:02PM -0400, Stephen Hemminger wrote:
> In order to make Vyatta/Brocade router work with LPM code
> I ended up redoing the layout. It is:
>
> And also several other scalability improvements (plus IPv6)
> and the correct handling of /32.
>
> Unfortunately, this is such
On Tue, Jun 23, 2015 at 10:19:58AM +0300, Vladimir Medvedkin wrote:
> Hi all,
>
> Matthew, I think ipv6 lpm code need less changes
> struct rte_lpm6_tbl_entry {
> uint32_t next_hop: 21; /**< Next hop / next table to be
> checked. */
> uint32_t depth :8; /**< Rule depth
On Tue, Jun 23, 2015 at 09:13:14PM -0700, Matthew Hall wrote:
> Vladimir,
>
> One thing I was confused, you published the changes to rte_lpm_tbl24_entry
> but
> you didn't say what you did to change rte_lpm_tbl8_entry, as that one only
> had
> an 8-bit next_hop as w
OK, I went and made a whole ton of patches to LPM and the tests and examples,
now the selftest errors out... but I think maybe I don't have an adequate
amount of hugepages. How much hugepage memory did people have when they did the
selftest successfully before?
I just keep seeing this over and
On Wed, Jun 24, 2015 at 10:04:53AM +0300, Vladimir Medvedkin wrote:
> I published changes to rte_lpm_tbl24_entry only because it was just an idea
> :)
Understood. Just wanted to be sure I understood it right to convert it into C
code. :)
> different defines and checks should be modified too.
Ye
On Thu, Jun 25, 2015 at 09:14:53AM +, Vass, Sandor (Nokia - HU/Budapest)
wrote:
> According to my understanding each packet should go
> through BR as fast as possible, but it seems that the rte_eth_rx_burst
> retrieves packets only when there are at least 2 packets on the RX queue of
> the
On Thu, Jun 25, 2015 at 06:46:30PM +0300, Avi Kivity wrote:
> What would be useful is a runtime switch between polling and interrupt
> modes. This was if the load is load you use interrupts, and as mitigation,
> you switch to poll mode, until the load drops again.
Yes... I believe this is part of
On Thu, Jun 25, 2015 at 08:44:51PM +0200, Thomas Monjalon wrote:
> DPDK is not a stack.
Hi Thomas,
Don't worry too much about that challenge.
When I get my app feature complete, I think we can change that.
Same for Avi and they server frameworks they are making at Cloudius. ;)
Matthew.
On Thu, Jun 25, 2015 at 09:13:59PM +, Vass, Sandor (Nokia - HU/Budapest)
wrote:
> Can anyone tell me the reason of this behavior? Using CPU 1 there are huge
> latencies, using other CPUs everything work as expected...
One possible guess what could be related. Normally DPDK uses "Core #0" as
Hi guys,
So I just finally fixed all the weird unit test failures for the basic-mode.
But the rte_lpm_lookupx4 will take quite a bit longer because it uses a lot of
real weird SSE intrinsic functions I never used before in my life.
However pretty soon I should get some kind of results how it wi
301 - 316 of 316 matches
Mail list logo
