On Thu, Nov 10, 2022 at 12:39 AM Stephen Hemminger <
step...@networkplumber.org> wrote:
> On Wed, 9 Nov 2022 14:04:34 +0800
> Yangchao Zhou wrote:
>
> > In some scenarios, mbufs returned by rte_kni_rx_burst are not freed
> > immediately. So kni_allocate_mbufs may be failed, but we don't know.
>
Hi Ferruh,
In my case, the traffic is not large, so I can't see the impact.
I also tested under high load(>2Mpps with 2 DPDK cores and 2 kernel threads)
and found no significant difference in performance either.
I think the reason should be that it will not
run to 'kni_fifo_count(kni->alloc_q) ==
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
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.
. 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
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
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
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
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
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*
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
step is to ensure they're using it. For that reason, GPL
seems like a step in the wrong direction to me.
- Matt
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,
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
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
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
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
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
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
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
an be
received. Could that be happening with pktgen? Is there any debugging I can do
to help track it down?
The command line I have been launching pktgen with is:
pktgen -c f -n 3 -m 512 -- -p 0x3 -P -m 1.0,2.1
Thanks,
-Matt Smith
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
> On Mar 14, 2015, at 1:33 PM, Wiles, Keith wrote:
>
> Hi Matt,
>
> On 3/14/15, 8:47 AM, "Wiles, Keith" <mailto:keith.wiles at intel.com>> wrote:
>
>> Hi Matt
>>
>> On 3/13/15, 3:49 PM, "Matt Smith" wrote:
>>
>
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
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, 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
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
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
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
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
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
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
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,
> >
> >
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
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
Thanks, I'll give that a try.
In my environment, I'm pretty sure we're using the fully-featured
ixgbe_xmit_pkts() and not _simple(). If setting rs_thresh=1 is safer,
I'll stick with that.
Again, thanks to all for the assistance.
- Matt
On Tue, Nov 17, 2015 at 10:20 AM,
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
it look as though either the
mbuf's data pointer is screwed up, or the VA translation done on it is. I
suspect that we're getting to a failure mode similar to the one you
experienced, though perhaps for different reasons.
Thanks,
Matt
On Wed, Apr 6, 2016 at 5:30 PM, Sanford, Robert wro
> -Original Message-
> From: Legacy, Allain
> Sent: Tuesday, August 13, 2019 8:20 AM
> To: hemant.agra...@nxp.com
> Cc: dev@dpdk.org; john.mcnam...@intel.com; marko.kovace...@intel.com;
> cristian.dumitre...@intel.com; Peters, Matt
> Subject: [PATCH 1/2] test: repl
> -Original Message-
> From: Legacy, Allain
> Sent: Tuesday, August 13, 2019 8:20 AM
> To: hemant.agra...@nxp.com
> Cc: dev@dpdk.org; john.mcnam...@intel.com; marko.kovace...@intel.com;
> cristian.dumitre...@intel.com; Peters, Matt
> Subject: [PATCH 2/2] doc: replace l
> -Original Message-
> From: Legacy, Allain
> Sent: Tuesday, June 18, 2019 3:19 PM
> To: tho...@monjalon.net
> Cc: dev@dpdk.org; ferruh.yi...@intel.com; Peters, Matt
> Subject: [PATCH v3] net/avp: remove resources when port is closed
>
> The rte_eth_dev_clos
> -Original Message-
> From: Legacy, Allain
> Sent: Monday, May 27, 2019 1:03 PM
> To: tho...@monjalon.net
> Cc: dev@dpdk.org; ferruh.yi...@intel.com; Peters, Matt
> Subject: [PATCH v2] net/avp: remove resources when port is closed
>
> The rte_eth_dev_clos
the marketing aspects of the project and
to allow association for marketing purposes
Calling these Gold and Silver is fine with me, but as I say, lets discuss this
at next weeks meeting.
Matt
From: moving on behalf of O'Driscoll, Tim
Sent: 08 November 20
ow me to have all Rx
information dealt with on one core and all Tx on another?
Thanks,
Matt Olson
44 matches
Mail list logo
