raev at gmail.com"
> >
> > This patch adds mbuf bulk allocation/freeing functions and unittest
> >
> > Signed-off-by: Vadim Suraev
> >
> > ---
> > New in v2:
> > - function rte_pktmbuf_alloc_bulk added
> > - function rte_pktmbuf_
tin.ananyev at intel.com> wrote:
> Hi Vadim,
>
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Vadim Suraev
> > Sent: Monday, March 23, 2015 5:31 PM
> > To: Olivier MATZ
> > Cc: dev at dpdk.org
> > Subjec
Hi, Olivier,
No, I personally need to free a chain using mempool bulk. If I'm not
mistaken, it has been proposed by one of reviewers to have lower level
function, so it was done (I'm sorry if misunderstood)
Regards,
Vadim.
On Mar 23, 2015 8:44 PM, "Olivier MATZ" wrote:
> Hi Neil,
>
> On 03/19/201
;
> Hi Vadim,
>
>
> > From: Vadim Suraev [mailto:vadim.suraev at gmail.com]
> > Sent: Wednesday, March 18, 2015 5:19 AM
> > To: Ananyev, Konstantin
> > Cc: dev at dpdk.org; olivier.matz at 6wind.com; stephen at
> > networkplumber.org
> > Subject: Re: [PATCH v2] rt
> >
> > This patch adds mbuf bulk allocation/freeing functions and unittest
> >
> > Signed-off-by: Vadim Suraev
> >
> > ---
> > New in v2:
> > - function rte_pktmbuf_alloc_bulk added
> > - function rte
or should it be responsibility of the caller?
Regards,
Vadim.
On Tue, Mar 17, 2015 at 10:22 PM, Vadim Suraev
wrote:
> Hi, Olivier,
>
> >I don't understand the "assumes refcnt has been already decremented".
>
> I changed to 'assumes refcnt equals 0
Hi, Olivier,
>I don't understand the "assumes refcnt has been already decremented".
I changed to 'assumes refcnt equals 0'
>Adding this function is not a problem today because it is the free
> function associated to rte_pktmbuf_bulk_raw_alloc().
>However, I think that the 'raw' alloc/free funct
livier MATZ
wrote:
> Hi Vadim,
>
> On 02/27/2015 06:09 PM, Vadim Suraev wrote:
>
>> >Indeed, this function looks useful, and I also have a work in progress
>> >on this topic, but currently it is not well tested.
>> I'm sorry, I didn't know. I'll
decoupled from reset, one can save some cycles.
Regards,
Vadim.
On Fri, Feb 27, 2015 at 3:20 PM, Olivier MATZ
wrote:
> Hi Vadim, Hi Konstantin,
>
> On 02/27/2015 01:18 PM, Vadim Suraev wrote:
> > Hi, Konstantin,
> >
> >> Seems really useful.
>
> Indeed,
Hi, Konstantin,
>Seems really useful.
>One thought - why to introduce the limitation that all mbufs have to be
from the same mempool?
>I think you can reorder it a bit, so it can handle situation when chained
mbufs belong to different mempools.
I had a doubt, my concern was how practical is that
ke to see these patches.
>>
>> On Fri, Sep 26, 2014 at 1:23 PM, Vadim Suraev
>> wrote:
>>
>>> Hi, all,
>>> I found ixgbe in couple with rte_mbuf (and probably other PMD drivers)
>>> don't support GSO, I reverse engineered the linux kernel's
Hi, all,
I found ixgbe in couple with rte_mbuf (and probably other PMD drivers)
don't support GSO, I reverse engineered the linux kernel's ixgbe's gso
support and got it working in 1.6. Could it be useful to provide the patch?
Regards,
Vadim.
I'll add it. Thanks
On Sep 18, 2014 3:17 PM, "Neil Horman" wrote:
> On Thu, Sep 18, 2014 at 07:13:43AM +0300, Vadim Suraev wrote:
> > Hi,
> > I've published the source code of Linux kernel IP stack ported to user
> space
> > and integrated with DP
Hi,
I've published the source code of Linux kernel IP stack ported to user space
and integrated with DPDK (1.6 currently).
I includes also some example applications & test scripts as well as
documentation
about what & how is done and how to use & adapt it.
The source:
git at github.com:vadimsu/ipau
rd party* to obtain the source code via the same mechanism as the
> pre-compiled binary.
>
> You can?t sell the source, you have to make it available, either with the
> binary, or to anyone who asks.
>
> There are other terms and conditions with the GPL (patent licenses, etc.)
&g
two
> would end up
> being covered by the Linux GPLv2 license.
>
> On Mon, Sep 8, 2014 at 11:30 PM, Vadim Suraev
> wrote:
>
>> I've ported the Linux kernel TCP/IP stack to user space and integrated
>> with
>> DPDK, the source and documentation and the roa
IMHO, since GPL is more restrictive so the source must remain open
On Sep 9, 2014 9:39 AM, "Zhang, Helin" wrote:
>
>
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Vadim Suraev
> > Sent: Tuesday, September 9, 2014 2
I've ported the Linux kernel TCP/IP stack to user space and integrated with
DPDK, the source and documentation and the roadmap will be published (and
announced) within few days.
Regards,
Vadim
On Sep 9, 2014 9:20 AM, "Matthew Hall" wrote:
> On Tue, Sep 09, 2014 at 08:49:44AM +0800, zimeiw wrote:
rte_time_reset was called, the pending statistics was
incremented. If neither was called and the timer is
periodic, the pending statistics is incremented when
it is reloaded
Signed-off-by: Vadim Suraev
---
lib/librte_timer/rte_timer.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions
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
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_st
, the
pending statistics was incremented. If neither was called
and the timer is periodic, the pending statistics is
incremented when it is reloaded
Signed-off-by: Vadim Suraev
---
lib/librte_timer/rte_timer.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib
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 is the modified timer is
in RUNNING state
Signed-off-by: Vadim Suraev
---
lib/librte_timer/rte_timer.c |8 ++--
1 file chang
Description: while running a periodic timer's callback, if another
timer is manipulated, the updated flag is raised
preventing the periodic timer to reload.
Fix: move
updated flag from priv_timer to rte_timer stucture (one
per core)
Signed-off-by: Vadim Suraev
---
lib/librte_
Description: when going running, the
pending count is not incremented.
Fix: decremend
pending when going running. Then, if periodic,
increment, if one shot - do nothing
Signed-off-by: Vadim Suraev
---
lib/librte_timer/rte_timer.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions
two timer bugs fixed
lib/librte_timer/rte_timer.c | 21 ++---
lib/librte_timer/rte_timer.h |7 ++-
2 files changed, 16 insertions(+), 12 deletions(-)
--
1.7.9.5
Signed-off-by: Vadim Suraev
---
lib/librte_timer/rte_timer.c | 17 -
lib/librte_timer/rte_timer.h |7 ++-
2 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/lib/librte_timer/rte_timer.c b/lib/librte_timer/rte_timer.c
index f98e904..0cc5fa9 100755
--- a
Signed-off-by: Vadim Suraev
---
lib/librte_timer/rte_timer.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/librte_timer/rte_timer.c b/lib/librte_timer/rte_timer.c
index a3d5cca..f98e904 100755
--- a/lib/librte_timer/rte_timer.c
+++ b/lib/librte_timer/rte_timer.c
rte_timer: 2 bug fixes
Vadim Suraev (2):
rte_timer bug fix: pending timers count is not decremented when
going running. Fix: decrement pending when going running, increment
if reloaded, do nothing if not reloaded Signed-off-by: Vadim
Suraev
rte_timer bug fix: when a
---
lib/librte_timer/rte_timer.c | 14 --
lib/librte_timer/rte_timer.h |3 +++
2 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/lib/librte_timer/rte_timer.c b/lib/librte_timer/rte_timer.c
index f98e904..ea2f22a 100755
--- a/lib/librte_timer/rte_timer.c
+++ b/lib/li
---
lib/librte_timer/rte_timer.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/librte_timer/rte_timer.c b/lib/librte_timer/rte_timer.c
index a3d5cca..f98e904 100755
--- a/lib/librte_timer/rte_timer.c
+++ b/lib/librte_timer/rte_timer.c
@@ -173,7 +173,7 @@ timer_set_
*** BLURB HERE ***
Vadim Suraev (2):
Pending timers counting fixed
Bug fixed: when timer's callback (for periodic timer) calls
timer_reset for another timer, a per-core updated flag is
raised which prevents reloading of that periodic timer. The
flag is moved to the ti
32 matches
Mail list logo
