On Tue, May 12, 2015 at 8:16 PM, Ravi Kerur wrote:
> On Mon, May 11, 2015 at 3:29 PM, Don Provan wrote:
>
> > I probably shouldn't stick my nose into this, but I can't help myself.
> >
> > An experienced programmer will tend to ignore the documentation for
> > a routine named "blahblah_memcmp" a
On Thu, May 21, 2015 at 8:33 AM, Dumitrescu, Cristian <
cristian.dumitrescu at intel.com> wrote:
> > > The problem I see with this approach is that you cannot turn off debug
> > > messages while still having the statistics collected. We should allow
> > > people to collects the stats without gett
On Fri, Mar 20, 2015 at 12:53 PM, Joseph Vossen wrote:
> hello,
>
> I am working on a dpdk-based app using version 1.6 under RH7.3. Under
> varying traffic loads, I will intermittently notice a kernel soft lockup
> and the RIP provided by the kernel always points to the same MOV
> instruction in
http://patchwork.dpdk.org/ml/archives/dev/2015-February/013335.html
Jay
On Wed, Mar 25, 2015 at 2:39 PM, Dey, Souvik wrote:
> Hi All,
> There looks like an issue will rte_kni.ko which gets
> kernel into deadlock. We are trying to run rte_kni.ko with multiple thread
> support whi
On Wed, Jun 15, 2016 at 4:43 AM, Yerden Zhumabekov
wrote:
> Hello everybody,
>
> DPDK already got a number of PMDs for various eth devices, it even has PMD
> emulations for backends such as pcap, sw rings etc.
>
> I've been thinking about the idea of having PMD which would generate mbufs
> on the
On Wed, Jun 15, 2016 at 7:11 AM, Yerden Zhumabekov
wrote:
>
>
> On 15.06.2016 17:50, Jay Rolette wrote:
>
>> On Wed, Jun 15, 2016 at 4:43 AM, Yerden Zhumabekov
>> wrote:
>>
>> Hello everybody,
>>>
>>> DPDK already got a number of PMDs for v
On Tue, Mar 1, 2016 at 8:02 PM, Stephen Hemminger <
stephen at networkplumber.org> wrote:
> On Mon, 29 Feb 2016 08:33:25 -0600
> Jay Rolette wrote:
>
> > On Mon, Feb 29, 2016 at 5:06 AM, Thomas Monjalon <
> thomas.monjalon at 6wind.com>
> > wrote:
> >
ot cause.
Doubtful this will matter to many (any?), but maybe it'll save someone some
time.
Jay Rolette
*infinite io*
Why are you adding newlines to log message strings? Shouldn't that be up to
whatever the messages end up getting routed to?
Jay
On Tue, Aug 26, 2014 at 9:09 AM, David Marchand
wrote:
> Clean log messages:
> - remove superfluous \n in log macros and add some \n where needed,
> - remove leading
7;s, I can see where this might be a little more pain, but having
PMD_LOG is a lot more useful it if easily integrates with central logging
facilities.
Thanks,
Jay
On Tue, Aug 26, 2014 at 9:55 AM, David Marchand
wrote:
> Hello Jay,
>
> On Tue, Aug 26, 2014 at 4:23 PM, Jay Rolette
> wr
*> We could run something like PC-Lint or Coverity, but they cost money :-)*
Pretty sure Coverity is free for open source projects...
Jay
On Wed, Aug 27, 2014 at 10:13 AM, Wiles, Roger Keith <
keith.wiles at windriver.com> wrote:
> Hi Everyone,
>
> I built dpdk with Clang and used the scan-build
and some are better then others. Some have a
> lot false positives and some report huge number of issues, but it just
> depends on the type and level of scan you want. One thing I found was you
> need to run different tools to find different problems as none of them do
> everything IM
On Wed, Dec 10, 2014 at 5:08 AM, Ananyev, Konstantin <
konstantin.ananyev at intel.com> wrote:
> I wonder why we do need to write our own bubble sort procedure?
> Why we can't use standard qsort() here?
>
Sadly, even bubble sort would be better than the selection sort being used
here. It's guaran
On Wed, Dec 10, 2014 at 12:39 PM, Ananyev, Konstantin <
konstantin.ananyev at intel.com> wrote:
> > I just got through replacing that entire function in my repo with a call
> to qsort() from the standard library last night myself. Faster
> > (although probably not material to most deployments) and
Signed-off-by: Jay Rolette
---
lib/librte_eal/linuxapp/eal/eal_memory.c | 59
+++-
1 file changed, 20 insertions(+), 39 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c
b/lib/librte_eal/linuxapp/eal/eal_memory.c
index bae2507..3656515 100644
--- a
Fixed spam from kni_allocate_mbufs() when no mbufs are free.
If mbufs exhausted, 'out of memory' message logged at EXTREMELY high rates.
Now logs no more than once per 10 mins
Signed-off-by: Jay Rolette
---
lib/librte_kni/rte_kni.c | 21 -
1 file changed, 20 insert
Because it doesn't work correctly :-)
On Mon, Dec 15, 2014 at 3:05 AM, Wodkowski, PawelX <
pawelx.wodkowski at intel.com> wrote:
>
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jay Rolette
> > Sent: Thursday, Decem
FWIW, it surprised the heck out of me as well.
Turns out that even though I'm compiling in 64-bit mode, gcc has
sizeof(int) as 4 bytes rather than 8. Not really sure what the scoop is on
that, but the standard leaves that up to the compiler. I'm used to int
always being the "natural size" on the C
gmail.com email rather than a corporate email
hosted via google apps.
Jay
On Tue, Dec 16, 2014 at 12:39 PM, Ananyev, Konstantin <
konstantin.ananyev at intel.com> wrote:
>
>
> Hi Jay,
>
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On
Actually, I just relooked at the email I sent and it looks correct
(properly indented, etc.). Any suggestions for what might be going on?
On Tue, Dec 16, 2014 at 1:18 PM, Jay Rolette wrote:
>
> Thanks Konstantin. Yes, I'll resend. Not sure why gmail is removing
> whitespace when I
Signed-off-by: Jay Rolette
---
lib/librte_eal/linuxapp/eal/eal_memory.c | 59 +++-
1 file changed, 20 insertions(+), 39 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c
b/lib/librte_eal/linuxapp/eal/eal_memory.c
index bae2507..3656515 100644
--- a
worry about
day-to-day. Appreciate the help getting things configured!
Jay
On Wed, Dec 17, 2014 at 7:08 AM, Qiu, Michael wrote:
>
> On 12/17/2014 7:01 PM, Ananyev, Konstantin wrote:
> > Hi Jay,
> >
> > From: Jay Rolette [mailto:rolette at infiniteio.com]
> > Sent: Tuesda
self-NAK now that I know that gmail web client borks up the patches. I'll
re-submit.
Jay
On Fri, Dec 12, 2014 at 7:28 PM, Jay Rolette wrote:
>
> Fixed spam from kni_allocate_mbufs() when no mbufs are free.
> If mbufs exhausted, 'out of memory' message logged at EXTREMEL
Signed-off-by: Jay Rolette
---
lib/librte_kni/rte_kni.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/lib/librte_kni/rte_kni.c b/lib/librte_kni/rte_kni.c
index fdb7509..f89319c 100644
--- a/lib/librte_kni/rte_kni.c
+++ b/lib/librte_kni/rte_kni.c
Hi Thomas,
Please read http://dpdk.org/dev#send for submission guidelines.
>
I did when I was figuring out how to submit the patch, but possible I'm
missing something on the tools to get it to include the commit comment
correctly.
A description of why you do it would be welcome in the commit log
What was the period of the issue? Also does this apply to just gmail.com
email addresses or also to other domains hosted by Google?
On Mon, Nov 3, 2014 at 3:25 AM, Thomas Monjalon
wrote:
> Hi all,
>
> There was a major failure with gmail accounts.
> Due to bounce errors, the mailing list system
Hi Reshma,
A few comments and questions about your design...
1) How do you envision the reorder library to be used? Based on the
description, it seems like the expectation is that packet order would be
maintained at either the interface/port level or maybe at the RX queue
level. Is that right or
kes
more sense in that context.
More detailed responses to your previous answers inline.
Regards,
Jay
On Fri, Oct 17, 2014 at 4:44 AM, Pattan, Reshma
wrote:
> Hi Jay,
>
>
>
> Please find comments inline.
>
>
>
> Thanks,
>
> Reshma
>
>
>
> *From:* Jay Rol
Tim,
Thanks for sharing this. If nothing else, I wanted to at least provide some
feedback on the parts that look useful to me for my applications/product.
Bits that make me interested in the release:
*> 2.0 (Q1 2015) DPDK Features:> Bifurcated Driver: With the Bifurcated
Driver, the kernel will
On Thu, Feb 5, 2015 at 6:00 AM, Damjan Marion (damarion) wrote:
> Hi,
>
> I have system with 2 NUMA nodes and 256G RAM total. I noticed that DPDK
> crashes in rte_eal_init()
> when number of available hugepages is around 4 or above.
> Everything works fine with lower values (i.e. 3).
>
>
On Thu, Feb 5, 2015 at 7:36 AM, Damjan Marion (damarion) wrote:
>
> On 05 Feb 2015, at 14:22, Jay Rolette wrote:
>
> Not directly related, but if you have to stick with 2MB hugepages, you
> might want to take a look at a patch I submitted that fixes the O(n^2)
> algorithm us
Environment:
* DPDK 1.6.0r2
* Ubuntu 14.04 LTS
* kernel: 3.13.0-38-generic
When we start exercising KNI a fair bit (transferring files across it, both
sending and receiving), I'm starting to see a fair bit of these kernel
lockups:
kernel: BUG: soft lockup - CPU#1 stuck for 22s! [kni_single:
k at the kernel messages. I will be glad to look at it.
>
>
>
> On Wed, Feb 11, 2015 at 1:33 AM, Jay Rolette
> wrote:
>
> > Environment:
> > * DPDK 1.6.0r2
> > * Ubuntu 14.04 LTS
> > * kernel: 3.13.0-38-generic
> >
> > When we start exerc
On Tue, Feb 10, 2015 at 7:33 PM, Jay Rolette wrote:
> Environment:
> * DPDK 1.6.0r2
> * Ubuntu 14.04 LTS
> * kernel: 3.13.0-38-generic
>
> When we start exercising KNI a fair bit (transferring files across it,
> both sending and receiving), I'm starting to see
On Mon, Feb 16, 2015 at 7:00 PM, Matthew Hall wrote:
> On Mon, Feb 16, 2015 at 10:33:52AM -0600, Jay Rolette wrote:
> > In kni_net_rx_normal(), it was calling netif_receive_skb() instead of
> > netif_rx(). The source for netif_receive_skb() point out that it should
> > onl
On Wed, Feb 25, 2015 at 6:38 AM, Marc Sune wrote:
>
> On 25/02/15 13:24, Hemant at freescale.com wrote:
>
>> Hi OIivier
>> Comments inline.
>> Regards,
>> Hemant
>>
>> -Original Message-
>>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier Deme
>>> Sent: 25/Feb/20
On Fri, Oct 23, 2015 at 5:28 AM, Mcnamara, John
wrote:
> Hi,
>
> We have had a few people wishing to submit DPDK related white papers.
> These tend to focus on particular aspects of DPDK and don't fit into
> any of the existing documents.
>
> Where should these be stored/made available? Some opti
On Wed, Sep 2, 2015 at 7:56 AM, Bruce Richardson wrote:
> On Wed, Sep 02, 2015 at 12:49:40PM +, Montorsi, Francesco wrote:
> > Hi all,
> >
> > Currently it seems that the only way to initialize EAL is using
> rte_eal_init() function, correct?
> >
> > I have the problem that rte_eal_init() wil
Most of the code in sort_by_physaddr() should be replaced by a call to
qsort() instead. Less code and gets rid of an O(n^2) sort. It's only init
code, but given how long EAL init takes, every bit helps.
I submitted a patch for this close to a year ago:
http://dpdk.org/dev/patchwork/patch/2061/
Ja
2015 at 5:35 AM, Gonzalez Monroy, Sergio <
sergio.gonzalez.monroy at intel.com> wrote:
> Following conversation in
> http://dpdk.org/ml/archives/dev/2015-September/023230.html :
>
> On 17/12/2014 13:31, rolette at infiniteio.com (Jay Rolette) wrote:
>
>> Signed-off-by: J
On Fri, Apr 24, 2015 at 2:47 AM, Luke Gorrie wrote:
> 2. How will DPDK users justify contributing to DPDK upstream?
>
> Engineers in network equipment vendors want to contribute to open source,
> but what is the incentive for the companies to support this? This would be
> easy if DPDK were GPL'd
On Fri, Apr 24, 2015 at 1:51 PM, Neil Horman wrote:
> So, I hear your arguments, and its understandable that you might not want
> a GPL
> licensed product, given that the DPDK is a library (though I'm not sure
> what the
> aversion to LGPL would be). Regardless, I think this conversation is a
>
On Sat, Apr 25, 2015 at 7:10 AM, Neil Horman wrote:
> On Fri, Apr 24, 2015 at 02:55:33PM -0500, Jay Rolette wrote:
> > On Fri, Apr 24, 2015 at 1:51 PM, Neil Horman
> wrote:
> >
> > > So, I hear your arguments, and its understandable that you might not
> want
>
On Tue, Apr 28, 2015 at 12:26 PM, Neil Horman wrote:
> On Mon, Apr 27, 2015 at 08:46:01AM -0500, Jay Rolette wrote:
> > On Sat, Apr 25, 2015 at 7:10 AM, Neil Horman
> wrote:
> >
> > > On Fri, Apr 24, 2015 at 02:55:33PM -0500, Jay Rolette wrote:
> > > >
On Thu, Aug 27, 2015 at 10:23 AM, Zhang, Helin
wrote:
>
>
> > -Original Message-
> > From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> > Sent: Wednesday, August 26, 2015 5:15 PM
> > To: dev at dpdk.org; Zhang, Helin
> > Subject: BUG - KNI broken in 4.2 kernel
> >
> > The net
+100 for the LTS
One of the bigger challenges for products using DPDK is that there is so
much change going in each release with very limited testing. Trying to even
remotely keep up is too risky. We end up back-porting various fixes and
enhancements to whatever version we are on (1.6rc2 currently
Can you improve the comments on these counters? If you didn't happen to
follow this thread, there's no way to reasonably figure out what the
difference is from looking at the code without chasing it all the way down
and cross-referencing the NIC datasheet.
Thanks,
Jay
On Fri, Oct 2, 2015 at 7:47
asheets.
I just went through this a few months ago when I was integrating DPDK port
stats into our stat tracking system.
I appreciate you making the extra effort to make this clearer for app
developers :-)
Jay
> *From:* Jay Rolette [mailto:rolette at infiniteio.com]
> *Sent:* Friday, Oct
Back when this was first submitted in June, I mentioned that
CLOCK_MONOTONIC_RAW was ~10x slower than CLOCK_MONOTONIC:
http://dpdk.org/ml/archives/dev/2015-June/018687.html
It's not completely free from NTP frequency adjustments, but it won't have
any discontinuities.
That's what we've been usin
Is there some technical reason or is it just the push-back you are getting
from some of the maintainers?
I chimed in on one of the other threads already, but I'm extremely
disappointed that usability and serviceability improvements to existing
DPDK capabilities (KNI) are getting blocked like this.
On Tue, Mar 22, 2016 at 5:19 AM, Bruce Richardson <
bruce.richardson at intel.com> wrote:
> On Tue, Mar 22, 2016 at 05:50:28AM +, Qiu, Michael wrote:
> >
> > Why not to implement one simple API with variable arguments, just like
> > syscall ioctl() does. And drivers implement it's specific har
On Mon, Jan 18, 2016 at 5:12 PM, Stephen Hemminger <
stephen at networkplumber.org> wrote:
> On Fri, 15 Jan 2016 16:18:01 +
> Ferruh Yigit wrote:
>
> > This work is to make DPDK ports more visible and to enable using common
> > Linux tools to configure DPDK ports.
> >
> > Patch is based on KN
On Fri, Jan 22, 2016 at 9:22 AM, Van Haaren, Harry <
harry.van.haaren at intel.com> wrote:
> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > Subject: Re: [dpdk-dev] Future Direction for rte_eth_stats_get()
>
> > + Harry
>
> Hey all,
>
> > xstats are driver agnostic and have a wel
On Thu, Jan 28, 2016 at 7:15 AM, Ferruh Yigit
wrote:
> On Thu, Jan 28, 2016 at 11:14:47AM +, Remy Horton wrote:
> > On 27/01/2016 16:24, Ferruh Yigit wrote:
> >
> > > + default:
> > > + ret = -95 /* EOPNOTSUPP */;
> > > + break;
> >
> > Is this intentional? -EOPNOTSUPP i
On Tue, Jul 5, 2016 at 2:35 AM, Bill Bonaparte
wrote:
> Hi:
> I am a new fish, I have tried my best to find answer about my question on
> web, but I failed. so
> I come here to ask for your help. the below is my question:
>
> I found that dpdk provides a api rte_eth_stats_get to read packet
> sta
0 Gigabit Network Connection' drv=igb_uio unused=
> :0c:00.0 'Device 0011' drv=igb_uio unused=
> :0f:00.1 'I350 Gigabit Network Connection' drv=igb_uio unused=
>
> Network devices using kernel driver
> ===========
> :0
On Thu, Jul 21, 2016 at 10:33 AM, Ferruh Yigit
wrote:
> On 7/20/2016 5:07 PM, Thomas Monjalon wrote:
> > The out-of-tree kernel code must be avoided.
> > Moreover there is no good reason to keep this legacy feature
> > which is only partially supported.
> >
> > As described earlier in this plan:
On Thu, Jul 21, 2016 at 3:32 PM, Thomas Monjalon
wrote:
> 2016-07-21 13:20, Jay Rolette:
> > On Thu, Jul 21, 2016 at 10:33 AM, Ferruh Yigit
> > wrote:
> > > KNI ethtool is functional and maintained, and it may have users!
> > >
> > > Why just r
On Wed, Jun 1, 2016 at 10:00 AM, Wiles, Keith wrote:
> Started from the link below, but did not want to highjack the thread.
> http://dpdk.org/ml/archives/dev/2016-June/040021.html
>
> I was thinking about this problem from a user perspective and command line
> options are very difficult to manag
On Tue, Dec 12, 2017 at 11:26 AM, Richardson, Bruce <
bruce.richard...@intel.com> wrote:
> Topic: Management of old patches in patchwork
> * Unanimous agreement that old patches should be rejected in patchwork
> after a reasonable period, set initially at 3 releases (9 months).
> * After a rele
On Mon, Dec 12, 2016 at 3:12 PM, Bruce Richardson <
bruce.richard...@intel.com> wrote:
> On Mon, Dec 12, 2016 at 07:24:02PM +, Luca Boccassi wrote:
> > From: Christian Ehrhardt
> >
> > A tools/init directory is added with dpdk-init, a script that can be
> > used to initialize a DPDK runtime e
On Thu, Dec 15, 2016 at 6:01 AM, Mcnamara, John
wrote:
>
> > -Original Message-
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Stephen Hemminger
> > Sent: Wednesday, December 14, 2016 11:41 PM
> > To: dev@dpdk.org
> > Subject: [dpdk-dev] KNI broken again with 4.9 kernel
> >
> >
On Mon, Jan 16, 2017 at 8:55 AM, Ferruh Yigit
wrote:
> On 1/16/2017 2:47 PM, Shirley Avishour wrote:
> > Hi,
> > As I wrote the kernel thread runs on a dedicated lcore.
> > running top while my application is running I see kni_single and the cpu
> > usage is really low...
> > Is there any rate li
On Tue, Jan 17, 2017 at 12:01 PM, Ferruh Yigit
wrote:
> KNI ethtool support (KNI control path) is not commonly used,
> and it tends to break the build with new version of the Linux kernel.
>
> KNI ethtool feature is disabled by default. KNI datapath is not effected
> from this update.
>
> It is p
On Wed, Jan 18, 2017 at 5:05 AM, Sergey Vyazmitinov <
s.vyazmiti...@brain4net.com> wrote:
> On Thu, Jan 12, 2017 at 12:29 AM, Ferruh Yigit
> wrote:
>
> > On 12/29/2016 11:23 PM, Sergey Vyazmitinov wrote:
> > > This allow to significant reduces packets processing latency.
> > >
> > > Signed-off-b
On Thu, Mar 30, 2017 at 10:51 AM, Wiles, Keith
wrote:
>
> My Soap box comment:
>I think we are limiting DPDK’s growth by only focusing on a few new
> PMDs and reworking the existing code. We need to look forward and grow DPDK
> as a community to get more people involved in adding more applic
On Fri, Mar 10, 2017 at 6:59 AM, Thomas Monjalon
wrote:
> 2017-01-18 07:11, Jay Rolette:
> > On Wed, Jan 18, 2017 at 5:05 AM, Sergey Vyazmitinov <
> > s.vyazmiti...@brain4net.com> wrote:
> >
> > > On Thu, Jan 12, 2017 at 12:29 AM, Ferruh Yigit >
> >
On Fri, Aug 11, 2017 at 3:29 PM, Bruce Richardson <
bruce.richard...@intel.com> wrote:
> On Wed, Aug 09, 2017 at 04:21:32PM -0400, Neil Horman wrote:
> > Can anyone point out to me when and where the change to require SSE4.2
> was
> > dicussed? The first I saw of it was when the commit to the rel
On Wed, Apr 6, 2016 at 12:26 AM, Yuanhan Liu
wrote:
> On Tue, Apr 05, 2016 at 05:31:22PM +0300, Arnon Warshavsky wrote:
> > Googling rte functions or error codes usually takes you to dpdk dev email
> > archive so I don't think it is that much difficult to figure out where
> rte
> > comes from.
>
I had a system lockup hard a couple of days ago and all we were able to get
was a photo of the LCD monitor with most of the kernel panic on it. No way
to scroll back the buffer and nothing in the logs after we rebooted. Not
surprising with a kernel panic due to an exception during interrupt
process
Over a year ago, Neil pointed out that calling netif_rx() from
kni_net_rx_normal() was a bug and could cause lockups. Here's the comment:
http://dpdk.org/ml/archives/dev/2015-March/015783.html
Looking at the current code base, it is still calling netif_rx() instead of
netif_rx_ni() as suggested.
On Thu, Apr 7, 2016 at 9:33 AM, Ferruh Yigit wrote:
> On 4/6/2016 9:22 PM, Jay Rolette wrote:
> > Over a year ago, Neil pointed out that calling netif_rx() from
> > kni_net_rx_normal() was a bug and could cause lockups. Here's the
> comment:
> >
> > http://
In ixgbe_dev_rx_init(), there is this bit of code:
/*
* Configure the RX buffer size in the BSIZEPACKET field of
* the SRRCTL register of the queue.
* The value is in 1 KB resolution. Valid values can be from
* 1 KB to 16 KB.
*/
buf_size
On Wed, Apr 20, 2016 at 4:10 AM, Bruce Richardson <
bruce.richardson at intel.com> wrote:
> On Tue, Apr 19, 2016 at 03:16:37PM -0500, Jay Rolette wrote:
> > In ixgbe_dev_rx_init(), there is this bit of code:
> >
> > /*
> >* Configure the RX buffer
On Wed, Apr 20, 2016 at 4:35 AM, Andriy Berestovskyy
wrote:
> Hi Jay,
>
> On Tue, Apr 19, 2016 at 10:16 PM, Jay Rolette wrote:
> > Should the driver error out in that case instead of only "sort of"
> working?
>
> +1, we hit the same issue. Error or log messag
On Wed, Apr 20, 2016 at 9:05 AM, Bruce Richardson <
bruce.richardson at intel.com> wrote:
> On Wed, Apr 20, 2016 at 07:22:57AM -0500, Jay Rolette wrote:
> > On Wed, Apr 20, 2016 at 4:10 AM, Bruce Richardson <
> > bruce.richardson at intel.com> wrote:
> >
> &g
On Fri, Apr 29, 2016 at 1:16 PM, Don Provan wrote:
> >From: Olivier Matz [mailto:olivier.matz at 6wind.com]
> >Subject: [dpdk-dev] removing mbuf error flags
> >
> >My opinion is that invalid packets should not be given to the application
> and only a statistic counter should be incremented.
>
> T
On Mon, Feb 29, 2016 at 5:06 AM, Thomas Monjalon
wrote:
> Hi,
> I totally agree with Avi's comments.
> This topic is really important for the future of DPDK.
> So I think we must give some time to continue the discussion
> and have netdev involved in the choices done.
> As a consequence, these se
Hi David,
A couple of minor comments inline below. Looks good otherwise.
Jay
On Mon, Sep 1, 2014 at 5:24 AM, David Marchand
wrote:
> - We should not use DEBUGOUT*/DEBUGFUNC macros in non-shared code.
> These macros come as compat wrappers for shared code.
> - We should avoid calling RTE_LOG d
{
> - PMD_INIT_LOG(ERR, "RX mbuf al
On Tue, Sep 2, 2014 at 9:21 AM, Thomas Monjalon
wrote:
> >> -#defineFUNC_PTR_OR_ERR_RET(func, retval) do { \
> > >> - if ((func) == NULL) { \
> > >> - DEBUGOUT("%s:%d function not supported\n", \
> > >> - _
> +(int)queue_idx);
> return I40E_ERR_PARAM;
> }
> if (tx_rs_thresh > tx_free_thresh) {
> - RTE_LOG(ERR, PMD, "tx_rs_thresh must be less than or "
> - "equal to tx_free_thresh.
> (tx_free_thresh=%u"
> - " tx_rs_thresh=%u port=%d queue=%d)\n",
> - (unsigned
> int)tx_free_thresh,
> - (unsigned int)tx_rs_thresh,
> - (int)dev->data->port_id,
> - (int)queue_idx);
> + PMD_INIT_LOG(ERR, "tx_rs_thresh must be less than or "
> +"equal to tx_free_thresh. (tx_free_thresh=%u"
> +" tx_rs_thresh=%u port=%d queue=%d)\n",
> +(unsigned int)tx_free_thresh,
> +(unsigned int)tx_rs_thresh,
> +(int)dev->data->port_id,
> +(int)queue_idx);
> return I40E_ERR_PARAM;
> }
> if ((nb_desc % tx_rs_thresh) != 0) {
> - RTE_LOG(ERR, PMD, "tx_rs_thresh must be a divisor of the "
> - "number of TX descriptors.
> (tx_rs_thresh=%u"
> - " port=%d queue=%d)\n",
> - (unsigned int)tx_rs_thresh,
> - (int)dev->data->port_id,
> - (int)queue_idx);
> + PMD_INIT_LOG(ERR, "tx_rs_thresh must be a divisor of the "
> +"number of TX descriptors. (tx_rs_thresh=%u"
> +" port=%d queue=%d)\n",
> +(unsigned int)tx_rs_thresh,
> +(int)dev->data->port_id,
> +(int)queue_idx);
> return I40E_ERR_PARAM;
> }
> if ((tx_rs_thresh > 1) && (tx_conf->tx_thresh.wthresh != 0)) {
> - RTE_LOG(ERR, PMD, "TX WTHRESH must be set to 0 if "
> - "tx_rs_thresh is greater than 1. "
> - "(tx_rs_thresh=%u port=%d queue=%d)\n",
> - (unsigned int)tx_rs_thresh,
> - (int)dev->data->port_id,
> - (int)queue_idx);
> + PMD_INIT_LOG(ERR, "TX WTHRESH must be set to 0 if "
> +"tx_rs_thresh is greater than 1. "
> +"(tx_rs_thresh=%u port=%d queue=%d)\n",
> +(unsigned int)tx_rs_thresh,
> +(int)dev->data->port_id,
> +(int)queue_idx);
> return I40E_ERR_PARAM;
> }
>
> --
> 1.7.10.4
>
> Reviewed-by: Jay Rolette
"used for the 1G driver.\n");
> if (tx_conf->tx_rs_thresh != 0)
> - RTE_LOG(WARNING, PMD,
> - "The tx_rs_thresh parameter is not "
> - "used for the 1G driver.\n");
> + PMD_INIT_LOG(WARNING, "The tx_rs_thresh parameter is not "
> +"used for the 1G driver.\n");
> if (tx_conf->tx_thresh.wthresh == 0)
> - RTE_LOG(WARNING, PMD,
> - "To improve 1G driver performance, consider
> setting "
> - "the TX WTHRESH value to 4, 8, or 16.\n");
> + PMD_INIT_LOG(WARNING, "To improve 1G driver performance, "
> +"consider setting the TX WTHRESH value to 4,
> 8, "
> +"or 16.\n");
>
> /* Free memory prior to re-allocation if needed */
> if (dev->data->tx_queues[queue_idx] != NULL) {
> --
> 1.7.10.4
>
> Reviewed-by: Jay Rolette
@@ -890,7 +890,7 @@ eth_igb_recv_scattered_pkts(void *rx_queue, struct
> rte_mbuf **rx_pkts,
> nmb = rte_rxmbuf_alloc(rxq->mb_pool);
> if (nmb =
On Mon, Sep 1, 2014 at 5:24 AM, David Marchand
wrote:
> Clean log messages:
> - remove leading \n in some messages,
> - remove trailing \n in some messages,
> - split multi lines messages,
> - replace some PMD_INIT_LOG(DEBUG, "some_func") with PMD_INIT_FUNC_TRACE().
>
> Signed-off-by: David March
*> p.s. Lately someone involved with DPDK said KNI would be deprecated in
future DPDK releases; I haven't read or listen to this before, is this
true? What would be the natural replacement then?*
KNI is a non-trivial part of the product I'm in the process of building.
I'd appreciate someone "in th
gt;
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jay Rolette
> > Sent: Tuesday, September 23, 2014 8:39 PM
> > To: Marc Sune
> > Cc: ; dev-team at bisdn.de
> > Subject: Re: [dpdk-dev] KNI and memzones
> >
>
allocate multiple lcores to achieve
> satisfied throughput for relatively big packets.
>
>
>
> Since NIC control is still in DPDK? PMD for this case, bifurcated driver
> does not fit, unless you only use DPDK to rx/tx packets in your box.
>
>
>
> *From:* Jay Ro
On Thu, Apr 2, 2015 at 7:55 AM, Thomas Monjalon
wrote:
> 2015-04-02 19:30, jerry.lilijun at huawei.com:
> > From: Lilijun
> >
> > In the function map_all_hugepages(), hugepage memory is truly allocated
> by
> > memset(virtaddr, 0, hugepage_sz). Then it costs about 40s to finish the
> > dpdk memo
"C comments" includes //, right? It's been part of the C standard for a long
time now...
Sent from my iPhone
> On Apr 8, 2015, at 8:40 AM, Butler, Siobhan A
> wrote:
>
>
>
>> -Original Message-
>> From: Neil Horman [mailto:nhorman at tuxdriver.com]
>> Sent: Wednesday, April 8, 2015
On Wed, Apr 8, 2015 at 5:38 PM, Stephen Hemminger <
stephen at networkplumber.org> wrote:
> On Wed, 8 Apr 2015 16:29:54 -0600
> Jay Rolette wrote:
>
> > "C comments" includes //, right? It's been part of the C standard for a
> long time now...
>
On Thu, Apr 9, 2015 at 2:16 PM, Neil Horman wrote:
> On Thu, Apr 09, 2015 at 11:31:39AM -0500, Jay Rolette wrote:
> > On Wed, Apr 8, 2015 at 5:38 PM, Stephen Hemminger <
> > stephen at networkplumber.org> wrote:
> >
> > > On Wed, 8 Apr 2015 16:
Hi Stephen,
Thanks for the feedback. Comments and questions inline below.
Jay
On Mon, Apr 13, 2015 at 8:09 PM, Stephen Hemminger <
stephen at networkplumber.org> wrote:
> On Wed, 17 Dec 2014 07:57:02 -0600
> Jay Rolette wrote:
>
> > Signed-off-by: Jay Rolette
> &
Maybe I just haven't had enough caffeine this morning yet, but why would
you add IP reassembly to KNI? If packets are going through KNI, they
already have IP reassembly via the normal Linux networking stack...
Jay
On Mon, Jul 27, 2015 at 8:55 PM, EaseTheWorld Mr.
wrote:
> Hello. I'm a DPDK newb
On Tue, Jun 2, 2015 at 8:11 AM, Roman Dementiev
wrote:
>
> This series of patches adds methods that use hardware memory transactions
> (HTM)
> on fast-path for DPDK locks (a.k.a. lock elision). Here the methods are
> implemented
> for x86 using Restricted Transactional Memory instructions (Intel(
On Wed, Jun 3, 2015 at 7:54 AM, Bruce Richardson wrote:
> On Wed, Jun 03, 2015 at 02:31:47PM +0800, Selmon Yang wrote:
> > Hi,
> >
> > I found that, in dpdk 2.0, rte_eal_alarm_set() is affected by
> > discontinuous jumps in the system time because eal_alarm_callback()
> > and rte_eal_alarm_set()
Don't need the 'safe' version of list_for_each_entry() if you aren't deleting
from the list as you iterate over it
Signed-off-by: Jay Rolette
---
lib/librte_eal/linuxapp/kni/kni_misc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/lib/lib
No reason to check out many entries are in kni->rx_q prior to
actually pulling them from the fifo. You can't dequeue more than
are there anyway. Max entries to dequeue is either the max batch
size or however much space is available on kni->free_q (lesser of the two)
Signed-off-by:
Loop processing packets dequeued from rx_q was using the number of
packets requested, not how many it actually received.
Variable rename to make code a little more clear
Signed-off-by: Jay Rolette
---
lib/librte_eal/linuxapp/kni/kni_net.c | 14 +++---
1 file changed, 7 insertions(+), 7
Some sort of hiccup sending. Not sure why 2/3 didn't come out as expected.
I'll try sending again.
Jay
On Wed, Jun 3, 2015 at 2:07 PM, Jay Rolette wrote:
> No reason to check out many entries are in kni->rx_q prior to
> actually pulling them from the fifo. You can't
1 - 100 of 120 matches
Mail list logo