Hi Qiming,
That's fantastic news. Thank you very much for taking the time to figure
the issue out.
Would it be possible to backport the fix to the 16.11 LTS release? This
kind of problem seems tailor-made for LTS.
--
Matt Laswell
lasw...@infinite.io
On Tue, Jul 18, 2017 at 3:58 AM,
On Thu, May 4, 2017 at 1:15 PM, Matt Laswell wrote:
> Hey Keith,
>
> Here is a hexdump of a subset of one of my packet captures. In this
> capture, all of the packets are part of the same TCP connection, which
> happens to be NFSv3 traffic. All of them except packet number 6 ge
hat's a more convenient
way to interact with the packets.
--
Matt Laswell
lasw...@infinite.io
16:08:37.093306 IP 10.151.3.81.disclose > 10.151.3.161.nfsd: Flags [P.],
seq 3173509264:3173509380, ack 3244259549, win 580, options [nop,nop,TS val
23060466 ecr 490971270], length 116: NF
mode I can think of would tend to affect all of
the packets in the connection consistently, even if incorrectly.
Thanks in advance for any ideas.
--
Matt Laswell
lasw...@infinite.io
some work done on tcpdump like
applications within DPDK, but don't remember what state those efforts are
in presently.
--
Matt Laswell
laswell at infinite.io
infinite io, inc.
On Fri, Jul 15, 2016 at 12:54 AM, Raja Jayapal wrote:
> Hi All,
>
> I have installed dpdk on VM and would like
n");
This approach is a little bit more cumbersome to code, but safer.
The last time that I looked the DPDK rte_dump_stack() is using vfprintf(),
which isn't safe in a signal handler. However, it's been several DPDK
releases since I peeked at the details.
--
Matt Laswell
Princi
Hey Robert,
Thanks for the insight. I work with Jay on the code he's asking about; we
only have one mbuf pool that we use for all packets. Mostly, this is for
the reasons that you describe, as well as for the sake of simplicity. As
it happens, the stack trace we're seeing makes it look as thoug
to set tx_rs_thresh=1.
>
> Though as I understand from your previous mails, you already did that, and
> it didn?t help.
>
> Konstantin
>
>
>
>
>
> *From:* Matt Laswell [mailto:laswell at infiniteio.com]
> *Sent:* Tuesday, November 17, 2015 3:05 PM
> *To:* Ananyev
t.
Thanks,
- Matt
On Tue, Nov 17, 2015 at 8:44 AM, Ananyev, Konstantin <
konstantin.ananyev at intel.com> wrote:
>
>
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Matt Laswell
> > Sent: Tuesday, November 17, 2015 2:24 PM
Stephen Hemminger <
stephen at networkplumber.org> wrote:
> On Mon, 16 Nov 2015 18:49:15 -0600
> Matt Laswell wrote:
>
> > Hey Stephen,
> >
> > Thanks a lot; that's really useful information. Unfortunately, I'm at a
> > stage in our release cycle w
pgrade DPDK entirely,
backporting targeted fixes is more doable.
Again, thanks.
- Matt
On Mon, Nov 16, 2015 at 6:12 PM, Stephen Hemminger <
stephen at networkplumber.org> wrote:
> On Mon, 16 Nov 2015 17:48:35 -0600
> Matt Laswell wrote:
>
> > Hey Folks,
> >
> >
th* calls to synchronize access
to the NIC. Given some recent discussion here, I also tried changing the
TX RS threshold from 0 to 32, 16, and 1. None of these strategies proved
effective.
Like I said at the top, I'm a little at a loss at this point. If you were
dealing with this set of sympto
Keith speaks truth. If I were going to do what you're describing, I would
do the following:
1. Start with the l2fwd example application.
2. Remove the part where it modifies the ethernet MAC address of received
packets.
3. Add a call in to clone mbufs via rte_pktmbuf_clone() and send the cloned
p
7;re trying to
accomplish.
--
Matt Laswell
infinite io, inc.
laswell at infiniteio.com
On Thu, May 28, 2015 at 10:38 AM, Kyle Larose wrote:
> I'm fairly new to dpdk, so I may be completely out to lunch on this, but
> here's an idea to possibly improve performance compared to a
a
packet mbuf isn't difficult.
--
Matt Laswell
infinite io, inc.
laswell at infiniteio.com
* Don't ask me how I know how much awesome fun this can be, though I
suspect you can guess.
On Thu, May 28, 2015 at 9:52 AM, Stephen Hemminger <
stephen at networkplumber.org> wrote:
> On T
On Fri, May 8, 2015 at 5:54 PM, Ravi Kerur wrote:
>
>
> On Fri, May 8, 2015 at 3:29 PM, Matt Laswell
> wrote:
>
>>
>>
>> On Fri, May 8, 2015 at 4:19 PM, Ravi Kerur wrote:
>>
>>> This patch replaces memcmp in librte_hash with rte_memcmp wh
ts of the sources. Also, if this function is to handle arbitrarily large
source data, the 128 byte case needs to be in a loop.
What am I missing?
--
Matt Laswell
infinite io, inc.
laswell at infiniteio.com
On Fri, Apr 24, 2015 at 12:39 PM, Jay Rolette
wrote:
>
> I can tell you that if DPDK were GPL-based, my company wouldn't be using
> it. I suspect we wouldn't be the only ones...
>
I want to emphasize this point. It's unsurprising that Jay and I agree,
since we work together. But I can say with
ile preserving RSS's effectiveness at load spreading
with typical traffic data. Not all 16 bit values will do this.
--
Matt Laswell
infinite io, inc.
laswell at infiniteio.com
On Mon, Mar 30, 2015 at 10:00 AM, Vladimir Medvedkin
wrote:
> Matthew,
>
> I don't use any sp
Hey Folks,
I have essentially the same question as Matthew. Has there been progress
in this area?
--
Matt Laswell
infinite io, inc.
laswell at infiniteio.com
On Sat, Mar 14, 2015 at 3:47 PM, Matthew Hall wrote:
> A few months ago we had this thread about symmetric hashing of TCP in
me
whether this is the preferred way to recover from link down?
Thanks,
--
Matt Laswell
*infinite io, inc.*
laswell at infiniteio.com
On Tue, Mar 10, 2015 at 10:47 AM, Matt Laswell
wrote:
> Hey Folks,
>
> I'm running into an issue that I hope is obvious and simple. We're
es back up.
Specifically, our calls to rte_eth_tx_burst() get return values that
indicate that no packets could be sent.
Is there an additional step that we have to do on link down/up operations,
perhaps to tell the NIC to flush its descriptor ring?
Thanks in advance for your help.
--
Matt Laswell
gone far too long for a Monday
morning. Regardless, I hope you found it useful. Let me know if you have
questions or comments.
--
Matt Laswell
infinite io, inc.
laswell at infiniteio.com
On Sun, Feb 22, 2015 at 10:50 PM, Matthew Hall
wrote:
>
> On Feb 22, 2015, at 4:02 PM, Stephen Hem
. Perhaps some profiler time is in my future.
Again, thanks to everybody for the useful information.
--
Matt Laswell
laswell at infiniteio.com
infinite io, inc.
On Tue, Dec 9, 2014 at 1:06 PM, Matthew Hall wrote:
> On Tue, Dec 09, 2014 at 10:33:59AM -0600, Matt Laswell wrote:
> > O
r the covers?
2. If not, is there any simple way that we can shorten memory
initialization time?
Thanks in advance for your insights.
--
Matt Laswell
laswell at infiniteio.com
infinite io, inc.
Fantastic. Thanks for the assist.
--
Matt Laswell
laswell at infiniteio.com
infinite io, inc.
On Sat, Nov 15, 2014 at 1:10 AM, Yerden Zhumabekov
wrote:
> Hello Matt,
>
> You can specify RSS configuration through rte_eth_dev_configure() function
> supplied with this structure
f you point me to
some example code that demonstrates the steps needed to configure RSS?
We're using Niantic NICs, so I assume that this is pretty standard stuff,
but having an example to study is a real leg up.
Again, thanks for all of the information.
--
Matt Laswell
laswell at infiniteio.com
i
rames will be
segmented into 2K chunks.
Any chance we could get an improvement to the documentation about this
parameter? It seems as though the opaque pointer isn't a pointer and
probably shouldn't be opaque.
Hope this helps the next person who comes across this behavior.
--
Matt Laswel
Bruce,
That's tremendously helpful. Thanks for the information.
--
Matt Laswell
*infinite io*
On Sun, Sep 7, 2014 at 2:52 PM, Richardson, Bruce <
bruce.richardson at intel.com> wrote:
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On
enabled? I think it probably
is, but would love to hear reasons why not and/or pitfalls that we need to
avoid.
Thanks in advance.
--
Matt Laswell
*infinite io*
Thanks Roger,
We saw similar issues with regard to kcompat.h. Can I ask if you've done
anything beyond the example applications under 14.04?
--
Matt Laswell
infinite io
On Thu, Jul 10, 2014 at 7:07 PM, Wiles, Roger Keith <
keith.wiles at windriver.com> wrote:
> The one prob
product to 14.04 for a
variety of reasons, but would hate to spend time chasing down subtle
incompatibilities. I'm guessing we're not the first ones to try this...
Thanks.
--
Matt Laswell
infinite io
that I'm going to move
towards smaller pages, but I very much appreciate the insights.
--
Matt Laswell
On Tue, Jul 1, 2014 at 6:51 AM, Burakov, Anatoly
wrote:
> Hi Matt,
>
> > I'm curious - is it possible in practical terms to run DPDK without
> hugepages?
>
> Sta
ence (or a
back-of-the-envelop estimate) of how badly such a configuration would hurt
performance? For sake of argument, assume that virtually all of the memory
being used is in pre-allocated mempools (e.g lots of rte_mempool_create(),
very little rte_malloc().
Thanks in advance for your help.
--
Matt Laswell
34 matches
Mail list logo
