Bug: When a timer is running - if rte_timer_stop is
called, the pending decrement is skipped (decremented
only if the timer is pending) and due to the update
flag the future processing is skipped so the timer is
counted as pending while it is stopped. - the same
applies when rte_time
Bug: when a periodic timer's callback is running, if
another timer is manipulated, the periodic timer is
not reloaded.
Solution: set the update flag only if the
modified timer is in RUNNING state
Signed-off-by: Vadim Suraev
---
lib/librte_timer/rte_timer.c |8 ++--
1 file changed
Vadim Suraev (2):
Bug: when a periodic timer's callback is running, if another
timer is manipulated, the periodic timer is not reloaded.
Solution: set the update flag only if the modified timer is
in RUNNING state
Bug: When a timer is running - if rte_timer_stop is ca
2014-05-23 15:39, Bruce Richardson:
> The variable CONFIG_RTE_BUILD_SHARED_LIB was in rte.app.mk as
> "RTE_BUILD_SHARED_LIB", which meant that none of the example apps linked
> in the PMDs and just didn't work with any eth ports in any static builds
>
> Link for l2fwd before patch:
> "... -Wl,--
Hi Cristian,
On 05/23/2014 05:21 PM, Cristian Dumitrescu wrote:
> Bug fix in cmdline library to allow return on EOF as opposed to infinite loop.
>
> Signed-off-by: Cristian Dumitrescu
> ---
> lib/librte_cmdline/cmdline.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
> mode ch
Hi Vadim,
It's even more simple that what I've suggested. It should
work since the only case where state is RTE_TIMER_RUNNING
is that we are modifying the timer currently running on the
same lcore. Indeed, timer_set_config_state() prevents us to
modify a running timer belonging to another lcore.
Acked-by: Olivier Matz
On 05/21/2014 10:35 PM, Vadim Suraev wrote:
> Bug: When a timer is running
> - if rte_timer_stop is called, the pending decrement is
> skipped (decremented only if the timer is pending) and due
> to the update flag the future processing is skipped so the
> timer is
Hi Konstantin,
> I don't see any big changes in the v2 of that patch.
>
> At least both things that I have concerns about, stay unchanged in
> the v2:
>
> 1) merge physaddr and buf_len in a bitfield - I still think we better
> keep physaddr as 64bit field (PATCH 5).
As nobody reacted to ou
Hi Venky,
> It's because we haven't gotten to testing the patch yet, and figuring
> out all the problems. Putting it in and modifying MBUF needs a bit of
> time - one other option that I've looked at is to let the transmit
> offload parts (except for the VLAN) flow onto the second cache
> lin
Bug fix in cmdline library to allow return on EOF as opposed to infinite loop.
Signed-off-by: Cristian Dumitrescu
---
lib/librte_cmdline/cmdline.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
mode change 100644 => 100755 lib/librte_cmdline/cmdline.c
diff --git a/lib/librte_cmdli
Hi Konstantin,
Thanks for these code examples and explanations.
On 05/20/2014 06:35 PM, Ananyev, Konstantin wrote:
> So with the following fragment of code:
> extern int *x;
> extern __128i a, *p;
> L0:
> _mm_stream_si128( p, a);
> rte_compiler_barrier();
> L1:
> *x = 0;
>
> There is n
This patch supports multiple queues feature in DPDK based virtio-net frontend.
It firstly gets max queue number of virtio-net from virtio PCI configuration and
then send command to negotiate the queue number with backend; When receiving and
transmitting packets, it negotiates multiple virtio-net qu
The variable CONFIG_RTE_BUILD_SHARED_LIB was in rte.app.mk as
"RTE_BUILD_SHARED_LIB", which meant that none of the example apps linked
in the PMDs and just didn't work with any eth ports in any static builds
Link for l2fwd before patch:
"... -Wl,--whole-archive -Wl,-lrte_kni -Wl,-lrte_timer -Wl,
The patch changes the way of reserving memory in Dom0 driver. It will reserve
memory at installing rte_dom0_mm.ko kernel module instead of requesting memory
dynamically during DPDK application startup. Meanwhile, now driver requests
memory size of 4M once first, if it failed, and request memory
Olivier,
>> It's because we haven't gotten to testing the patch yet, and figuring > out
>> all the problems. Putting it in and modifying MBUF needs a bit of > time -
>> one other option that I've looked at is to let the transmit > offload parts
>> (except for the VLAN) flow onto the second
Hi Thomas,
I don't see any big changes in the v2 of that patch.
At least both things that I have concerns about, stay unchanged in the v2:
1) merge physaddr and buf_len in a bitfield - I still think we better keep
physaddr as 64bit field (PATCH 5).
2) fix_tcp_phdr_cksum() is inside ixgbe TX funct
1)If igb_alloc_rx_queue_mbufs() would fail to allocate an mbuf for RX queue,
it calls igb_rx_queue_release(rxq).
That causes rxq to be silently freed, without updating dev->data->rx_queues[].
So any firther reference to it will trigger the SIGSEGV.
Same thing in em PMD too.
To fix: igb_alloc_rx_qu
On 05/23/2014 04:08 AM, Ouyang, Changchun wrote:
> Hi Ivan
>
> To some extent, I also agree with you.
> But customer hope DPDK can provide an interface like "ifconfig up" and
> "ifconfig down" in linux,
> They can invoke such an interface in user application to repeated stop and
> start dev frequ
Hi Anatoly,
2014-05-01 15:43, Burakov, Anatoly:
> > From: Didier Pallard
> >
> > In current version, coremask can only be specified using a bitmask.
> > It will now be possible to specify core masks in 2 different ways:
> > - Using a bitmask (-c 0xnnn): bitmask must be in hex format and start wi
Hi Jijiang,
2014-05-23 14:53, Jijiang Liu:
> The patch changes the way of reserving memory in Dom0 driver. It will
> reserve memory at installing rte_dom0_mm.ko kernel module instead of
> requesting memory dynamically during DPDK application startup. Meanwhile,
> now driver requests memory size of
Hi Konstantin,
2014-05-22 17:55, Konstantin Ananyev:
> With latest HW and optimised RX/TX path there is a huge gap between
> tespmd iofwd and l3fwd performance results.
> So there is an attempt to optimise l3fwd LPM code path and reduce the gap:
> - Instead of processing each input packet up to c
2014-05-23 08:11, Stephen Hemminger:
> On Thu, 22 May 2014 15:13:49 +0200
>
> Thomas Monjalon wrote:
> > 2014-05-19 16:51, Anatoly Burakov:
> > > Note that since igb_uio no longer has a PCI ID list, it can now be
> > > bound to any device, not just those explicitly supported by DPDK. In
> > > oth
Hi Thomas,
> I don't understand what would be improved by adding a new parameter.
> I think being able to handle the 2 syntaxes within the same option is nice.
Well, -c option has been handling everything as hex since forever. Our own
documentation usually has coremasks without the 0x prefix. Th
Thanks.
I Will add changelog for next time.
-Original Message-
From: Thomas Monjalon [mailto:thomas.monja...@6wind.com]
Sent: Friday, May 23, 2014 4:20 PM
To: Liu, Jijiang
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH v2]xen:reserve memory at installing dom0_mm
kernel module
Hi Jij
On Thu, 22 May 2014 15:13:49 +0200
Thomas Monjalon wrote:
> 2014-05-19 16:51, Anatoly Burakov:
> > Note that since igb_uio no longer has a PCI ID list, it can now be
> > bound to any device, not just those explicitly supported by DPDK. In
> > other words, it now behaves similar to PCI stub, VFIO
Hi Ivan
To some extent, I also agree with you.
But customer hope DPDK can provide an interface like "ifconfig up" and
"ifconfig down" in linux,
They can invoke such an interface in user application to repeated stop and
start dev frequently, and
Make sure RX and TX work fine after each start, I t
On 22/05/14 13:13, Thomas Monjalon wrote:
> 2014-05-19 16:51, Anatoly Burakov:
>> Note that since igb_uio no longer has a PCI ID list, it can now be
>> bound to any device, not just those explicitly supported by DPDK. In
>> other words, it now behaves similar to PCI stub, VFIO and other generic
>>
27 matches
Mail list logo
