On Mon, Jun 15, 2020 at 5:52 PM Stephen Hemminger <
step...@networkplumber.org> wrote:
> I am disturbed by the wide spread use of master/slave in Ethernet bonding.
> Asked the current IEEE chairs and it looks like it is already fixed
> "upstream".
>
> The proper terminology is for Ethernet link ag
On Fri, May 17, 2019 at 1:46 PM Stephen Hemminger <
step...@networkplumber.org> wrote:
> Several customers have reported similar issues with how the owned/stack
> device model
> works in DPDK. With failsafe/tap and VF or netvsc and VF there are DPDK
> ports which
> are marked as owned and therefor
Hi Thomas,
On Fri, Jan 25, 2019 at 10:40 AM Thomas Monjalon
wrote:
> Hi Jay,
>
> 25/01/2019 14:42, Jay Rolette:
> > >* Questions from Intel Test about the use of the Stable Tree.
> > > Do people use it? Each stable/LTS release requires a lot of
>
>* Questions from Intel Test about the use of the Stable Tree.
> Do people use it? Each stable/LTS release requires a lot of
> testing and there are currently 3 releases to be tested.
We do @ infinite io.
Jay
On Fri, Jan 25, 2019 at 3:24 AM Mcnamara, John
wrote:
> Release Status
On Thu, Sep 20, 2018 at 3:16 PM Stephen Hemminger <
step...@networkplumber.org> wrote:
> On Thu, 20 Sep 2018 15:02:53 -0500
> Jay Rolette wrote:
>
> > On Thu, Sep 20, 2018 at 1:11 PM Stephen Hemminger <
> > step...@networkplumber.org> wrote:
> >
> > &
On Thu, Sep 20, 2018 at 1:11 PM Stephen Hemminger <
step...@networkplumber.org> wrote:
> I wonder if KNI is claiming performance that was never measured on current
> CPU, OS, DPDK.
>
> With single stream and TCP testing on IXGBE (DPDK), I see lowest
> performance with KNI.
>
> Rx
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 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 Tue, Jun 13, 2017 at 12:21 PM, Ferruh Yigit
wrote:
> On 5/30/2017 11:55 AM, Thomas Monjalon wrote:
> > 26/05/2017 18:52, Ferruh Yigit:
> >> We are looking for re-sending [1] the Kernel Control Path (KCP)
> >> with some updates [2].
> >>
> >> Mainly this is an usability improvement for DPDK.
>
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 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 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 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 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, 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, 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 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:
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 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
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 the
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 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 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 messag
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
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 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://
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
process
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 har
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 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 se
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 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 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
+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
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
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
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
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
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
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
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
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
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
rmance
improvement 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
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
>>
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)
real11m58.2
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:
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
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
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:
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
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 (Intel(
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 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 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 memo
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 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
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 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
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
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:
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 con
nd 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/patchwork/patch/84/)
There's a fairly old KNI patch (http://dpdk.org/dev/patchwork/patch/84/)
that I reviewed, but I'm not seeing how to submit my "Reviewed-by" when I
don't have any of the emails from the patch in my mail client.
I can copy the text from the 'mbox' link in Patchwork into an email, but
I'm guessing th
Is there a way to control what ethernet port gets mapped to each port_id in
DPDK?
>From what I've seen, it looks like the port_id values just get assigned
based on the order they come back in the PCI probe/scan. Ideally, I'd like
to have the port_id values map reasonably directly to the customer-f
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 appl
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
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 EXTREMEL
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
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
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
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
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
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
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
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
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
1 - 100 of 120 matches
Mail list logo
