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 jus
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:
===
> :0f:00.0 'I350 Gigabit Network Connection' if=enp15s0f0 drv=igb
> unused=igb_uio *Active*
>
> Other network devices
> =
>
>
With it not working on hardware and you having devices successfully bound
to DPDK, maybe it's a problem in your app. Have y
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
>
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 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
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
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 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 mess
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 buf
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.
*/
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://dpdk.
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.
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
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.
>
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
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
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:
> >
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
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
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
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
+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
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
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
ts.
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, October
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
: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: Jay Rolette
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/
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()
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
rovement doesn't really matter.
>
> - Helin
>
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jay Rolette
> > Sent: Thursday, June 4, 2015 3:19 AM
> > To: dev at dpdk.org
> > Subject: [dpdk-dev] [PATCH 1/3
Follow-up to my long email about KNI performance so we don't have
chapter-length quotes in any discussion...
Increasing HZ to 1000 helped, but I'd really like a way to wake the KNI
kernel thread up on demand. I'm hoping someone with more Linux kernel
experience than I have might have some ideas.
On Fri, Jun 5, 2015 at 10:13 AM, Marc Sune wrote:
>
>
> On 05/06/15 17:06, Jay Rolette wrote:
>
>> The past few days I've been trying to chase down why operations over KNI
>> are so bloody slow. To give you an idea how bad it is, we did a simple
>> test
>> o
The past few days I've been trying to chase down why operations over KNI
are so bloody slow. To give you an idea how bad it is, we did a simple test
over an NFS mount:
# Mount over a non-KNI interface (eth0 on vanilla Ubuntu 14.04 LTS)
$ time $(ls -last -R /mnt/sfs2008 > /dev/null)
real
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
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: Jay R
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/librte_eal/linuxapp/kni
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
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: Jay R
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/librte_eal/linuxapp/kni
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()
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
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
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"
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 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 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 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
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
> &
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:
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...
>
"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 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
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
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
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:
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 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 a fai
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 exercising KNI a
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!
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
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 Wed, Jan 28, 2015 at 3:23 PM, Neil Horman wrote:
> On Wed, Jan 28, 2015 at 02:57:58PM -0600, Jay Rolette wrote:
> > Thanks Thomas and Neil. Sadly, no joy. While I generally like gmail for
> my
> > mail, there's not a reasonable way to import the mbox file or to control
e behavior
in our app and ended up avoiding it higher in the stack (in our code).
Reviewed-by: Jay Rolette
Jay
On Wed, Jan 28, 2015 at 10:49 AM, Neil Horman wrote:
> On Wed, Jan 28, 2015 at 09:52:48AM -0600, Jay Rolette wrote:
> > There's a fairly old KNI patch (http://dpdk.org/dev/
On Thu, Jan 22, 2015 at 12:27 PM, Luke Gorrie wrote:
> On 22 January 2015 at 14:29, Jay Rolette wrote:
>
>> Microseconds matter. Scaling up to 100GbE, nanoseconds matter.
>>
>
> True. Is there a cut-off point though?
>
There are always engineering trade-offs t
On Thu, Jan 22, 2015 at 3:06 AM, Luke Gorrie wrote:
Here is another thought: when is it time to start thinking of packet copy
> as a cheap unit-time operation?
>
Pretty much never short of changes to memory architecture, IMO. Frankly,
there are never enough cycles for deep packet inspection
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
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 EXTREMELY high
> rat
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: Tues
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
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 sent
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 Behalf Of
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
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, December 1
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 insertions(+), 1
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)
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
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
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
.
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 Rolette [mailto:rolette at infini
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
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
-
> > 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
> >
> > *> p.s. Lately someone in
*> 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
gt; rte_mbuf **rx_pkts,
> nmb = rte_rxmbuf_alloc(rxq->mb_pool);
> if (nmb == NULL) {
> PMD_R
t;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
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
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", \
> > >> -
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
r 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 IMO.
>
> On Aug
*> 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
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
> wrote:
>
>> Why ar
r to many (any?), but maybe it'll save someone some
time.
Jay Rolette
*infinite io*
94 matches
Mail list logo
