Otherwise cache_flushthresh can be bigger than n, and
a consumer can starve others by keeping every element
either in use or in the cache.
Signed-off-by: Zoltan Kiss
---
lib/librte_mempool/rte_mempool.c | 3 ++-
lib/librte_mempool/rte_mempool.h | 2 +-
2 files changed, 3 insertions(+), 2
Hi,
Any opinion on this patch?
Regards,
Zoltan
On 13/05/15 19:59, Zoltan Kiss wrote:
> Otherwise cache_flushthresh can be bigger than n, and
> a consumer can starve others by keeping every element
> either in use or in the cache.
>
> Signed-off-by: Zoltan Kiss
> ---
>
On 18/05/15 13:41, Ananyev, Konstantin wrote:
>
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zoltan Kiss
>> Sent: Monday, May 18, 2015 1:28 PM
>> To: dev at dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH] mempool:
On 18/05/15 14:14, Ananyev, Konstantin wrote:
>
>
>> -Original Message-----
>> From: Zoltan Kiss [mailto:zoltan.kiss at linaro.org]
>> Sent: Monday, May 18, 2015 1:50 PM
>> To: Ananyev, Konstantin; dev at dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH] mempool
Otherwise cache_flushthresh can be bigger than n, and
a consumer can starve others by keeping every element
either in use or in the cache.
Signed-off-by: Zoltan Kiss
---
v2: use macro for calculation, with proper casting
lib/librte_mempool/rte_mempool.c | 8 +---
lib/librte_mempool
On 18/05/15 15:13, Ananyev, Konstantin wrote:
>
>
>> -Original Message-----
>> From: Zoltan Kiss [mailto:zoltan.kiss at linaro.org]
>> Sent: Monday, May 18, 2015 2:31 PM
>> To: Ananyev, Konstantin; dev at dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH] mempool
atic inline functions rte_mbuf_from_indirect()
> and rte_mbuf_to_baddr() to replace the existing macros, which
> take the private size in account when attaching and detaching
> mbufs.
>
> Signed-off-by: Olivier Matz
Reviewed-by: Zoltan Kiss
I assume the rest of the series haven't changed apart
Hi,
I have two questions regarding mempools:
- the first is trivial: how do you delete them? Can you? I can't see a
function to do that, and none of the examples are doing such thing. When
exactly it get deleted?
- during creation, cache_size have one requirement: it has to be smaller
than RTE
Hi,
On 15/04/15 20:15, Zoltan Kiss wrote:
> Hi,
>
> I have two questions regarding mempools:
>
> - the first is trivial: how do you delete them? Can you? I can't see a
> function to do that, and none of the examples are doing such thing. When
> exactly it get de
Hi,
On 22/04/15 12:59, Ananyev, Konstantin wrote:
>
>
>> -Original Message-
>> From: Olivier Matz [mailto:olivier.matz at 6wind.com]
>> Sent: Wednesday, April 22, 2015 10:57 AM
>> To: dev at dpdk.org
>> Cc: Ananyev, Konstantin; zoltan.kiss at linaro.org; Richardson, Bruce;
>> nhorman at t
On 27/04/15 12:54, Nikita Kalyazin wrote:
> Hi,
>
>
> As far as I understand, DPDK vhost-user implementation requires data copy for
> either RX or TX (rte_vhost_dequeue_burst() and rte_vhost_enqueue_burst()). It
> means that two data copies are needed to transfer a packet from one VM to
> anot
On 27/04/15 18:38, Thomas Monjalon wrote:
> 2015-04-24 11:38, Zoltan Kiss:
>> On 22/04/15 12:59, Ananyev, Konstantin wrote:
>>> From: Olivier Matz [mailto:olivier.matz at 6wind.com]
>>> Sent: Wednesday, April 22, 2015 10:57 AM
>>>> The first objective
On 28/04/15 02:22, Xie, Huawei wrote:
>
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zoltan Kiss
>> Sent: Tuesday, April 28, 2015 12:27 AM
>> To: Nikita Kalyazin; dev at dpdk.org
>> Subject: Re: [dpdk-dev] data cop
Hi,
I'm experimenting a little bit with the scheduler library, and I got some
performance numbers which seems to be worse than what I've expected.
I'm sending 64 bytes packets on a 10G interface to a separate thread, and
my simple test program (based on the qos_sched example) does the following:
On 16/02/17 20:08, Dumitrescu, Cristian wrote:
Hi Zoltan,
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Zoltan Kiss
Sent: Thursday, February 16, 2017 3:14 PM
To: dev@dpdk.org
Subject: [dpdk-dev] rte_sched library performance question
Hi,
I'm experiment
On 14/09/16 15:42, Ferruh Yigit wrote:
> On 7/20/2016 6:11 PM, Zoltan Kiss wrote:
>> Using weak symbols have a few issues with static linking:
>>
>> - normally the linker searches the .o files already linked, if your weak
>>one is there, it won't check if there
On 04/08/15 08:32, Cunming Liang wrote:
> On receive side, the burst size now floor aligns to RTE_IXGBE_DESCS_PER_LOOP
> power of 2.
> According to this rule, the burst size less than 4 still won't receive
> anything.
> (Before this change, the burst size less than 32 can't receive anything.)
>
gt; PMD_INIT_LOG(DEBUG, "Vector rx enabled, please make sure RX "
> -"burst size no less than 32.");
> + "burst size no less than %d (port=%d).",
> +
On 05/08/15 07:28, Liang, Cunming wrote:
> Hi Zoltan,
>
>> -Original Message-----
>> From: Zoltan Kiss [mailto:zoltan.kiss at linaro.org]
>> Sent: Wednesday, August 05, 2015 12:26 AM
>> To: Liang, Cunming; dev at dpdk.org
>> Cc: Ananyev, Konstantin
>
Hi,
I've set up a simple packet forwarding perf test on a dual-port 10G
82599ES: one port receives 64 byte UDP packets, the other sends it out,
one core used. I've used latest OVS with DPDK 2.1, and the first result
was only 13.2 Mpps, which was a bit far from the 13.9 I've seen last
year with
Hi,
On 24/08/15 12:43, Traynor, Kevin wrote:
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at openvswitch.org] On Behalf Of Zoltan Kiss
>> Sent: Friday, August 21, 2015 7:05 PM
>> To: dev at dpdk.org; dev at openvswitch.org
>> Cc: Richa
at much, while with the non-vector PMD it can
max out the link.
Any more suggestions?
Regards,
Zoltan
On 21/08/15 19:05, Zoltan Kiss wrote:
> Hi,
>
> I've set up a simple packet forwarding perf test on a dual-port 10G
> 82599ES: one port receives 64 byte UDP packets, the oth
have something in the cache, try to combine them
- the refill happens at the end, and its failure doesn't modify our return
value
Signed-off-by: Zoltan Kiss
---
v2:
- fix subject
- add unlikely for branch where request is fulfilled both from cache and ring
On 02/07/15 18:07, Ananyev, Konstantin wrote:
>
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zoltan Kiss
>> Sent: Wednesday, July 01, 2015 10:04 AM
>> To: dev at dpdk.org
>> Subject: [dpdk-dev] [PATCH v2] mem
Hi,
I've been asked this question, and I realized I'm not sure about the
answer. In other words: can you call rte_eth_tx_burst() and
rte_eth_tx_burst() on the same port at the same time from different
threads? In theory it seems possible, as you still access different
queues (an RX and a TX on
Hi,
On 27/06/16 09:00, Ananyev, Konstantin wrote:
>> The default behavior is to NOT support the old ptype behavior,
>> but enabling the configuration option the old ptype style
>> can be supported.
>>
>> Add support for old behaviour until we have a cleaner solution using
>> a configuration option
Hi,
I have a quick question about this field: how do I know if the
underlying PMD supports a particular protocol parsing. Let's say I want
to check for SCTP packets, looking at this field tells me EITHER the
packet is SCTP (or not), OR that the hardware has no idea about SCTP. Is
there a way t
Hi,
I've noticed that ixgbe_set_tx_function() selects the non-SG function
even if (dev->data->scattered_rx == 1). That seems a bit dangerous, as
you can turn that on inadvertently when you don't set max_rx_pkt_len and
buffer size in certain ways. I've learnt it in the hard way, as my
segmented
On 04/03/16 01:47, Lu, Wenzhuo wrote:
> Hi Zoltan,
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zoltan Kiss
>> Sent: Wednesday, March 2, 2016 3:19 AM
>> To: dev at dpdk.org
>> Subject: [dpdk-dev] ixgbe TX fun
On 04/03/16 10:58, Ananyev, Konstantin wrote:
> Hi,
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier MATZ
>> Sent: Friday, March 04, 2016 9:29 AM
>> To: Zoltan Kiss; dev at dpdk.org
>> Subject: Re: [dpdk-dev] r
On 30/06/15 12:58, Olivier MATZ wrote:
> Hi Zoltan,
>
> On 06/25/2015 08:48 PM, Zoltan Kiss wrote:
>> The current way has a few problems:
>>
>> - if cache->len < n, we copy our elements into the cache first, then
>>into obj_table, that's unnecess
< Points to the other buffer if this one
is (in)direct. Otherwise NULL. */
What do you think?
Regards,
Zoltan Kiss
This macro and function were copies from the mbuf library, no reason to keep
them.
Signed-off-by: Zoltan Kiss
---
examples/vhost/main.c | 38 +-
1 file changed, 5 insertions(+), 33 deletions(-)
diff --git a/examples/vhost/main.c b/examples/vhost/main.c
index
Hi Olivier,
On 25/03/15 17:04, Olivier MATZ wrote:
> Hi Zoltan,
>
> On 03/24/2015 06:42 PM, Zoltan Kiss wrote:
>> Hi,
>>
>> I've noticed in lib/netdev-dpdk.c that __rte_pktmbuf_init() stores the
>> packet metadata right after "struct rte_mbuf", an
't establish an error scenario yet, I think it's quite dangerous
to leave the packet to inherit the previous packet's ofpbuf.
Or am I missing some place where this piece is reinitialized?
Regards,
Zoltan Kiss
On 26/03/15 01:20, Ananyev, Konstantin wrote:
>
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zoltan Kiss
>> Sent: Wednesday, March 25, 2015 6:43 PM
>> To: dev at dpdk.org
>> Cc: Zoltan Kiss
>> Subject: [dpd
On 26/03/15 15:59, Olivier Matz wrote:
> Add a new private_size field in mbuf structure that should
> be initialized at mbuf pool creation. This field contains the
> size of the application private data in mbufs.
>
> Introduce new static inline functions rte_mbuf_from_indirect()
> and rte_mbuf_to
On 26/03/15 17:34, Ananyev, Konstantin wrote:
>
>
>> -Original Message-----
>> From: Zoltan Kiss [mailto:zoltan.kiss at linaro.org]
>> Sent: Thursday, March 26, 2015 4:46 PM
>> To: Ananyev, Konstantin; dev at dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH]
licate set to zero.
Signed-off-by: Zoltan Kiss
---
lib/librte_mbuf/rte_mbuf.h | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index 17ba791..3ec4024 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_
On 27/03/15 15:17, Olivier MATZ wrote:
> Hi Konstantin,
>
> On 03/27/2015 03:25 PM, Ananyev, Konstantin wrote:
>> Hi Olivier,
>>
>>> -Original Message-
>>> From: Olivier MATZ [mailto:olivier.matz at 6wind.com]
>>> Sent: Friday, March 27, 2015 1:56 PM
>>> To: Ananyev, Konstantin; dev at dp
Hi,
On 30/03/15 18:39, Don Provan wrote:
> if (likely (rte_mbuf_refcnt_read(m) == 1) ||
> likely (rte_mbuf_refcnt_update(m, -1) == 0))
>
> In all the debate about atomics, I don't think anyone got around to pointing
> out that in the unlikely case that
On 28/09/15 00:19, Ananyev, Konstantin wrote:
>
>
>> -Original Message-----
>> From: Zoltan Kiss [mailto:zoltan.kiss at linaro.org]
>> Sent: Friday, September 25, 2015 7:29 PM
>> To: Richardson, Bruce; dev at dpdk.org
>> Cc: Ananyev, Konstantin
>> S
On 15/10/15 09:32, Younghwan Go wrote:
> Hi,
>
> I'm pretty new to playing with DPDK. I was trying to see if I can always
> receive MAX_BURST packets by calling rte_eth_rx_burst() multiple times
> on same pair (code shown below). I'm using DPDK-2.1.0 on 2
> dual-port Intel 82599ES 10Gbps NICs wi
On 15/10/15 00:23, Ananyev, Konstantin wrote:
>
>
>> -Original Message-----
>> From: Zoltan Kiss [mailto:zoltan.kiss at linaro.org]
>> Sent: Wednesday, October 14, 2015 5:11 PM
>> To: Ananyev, Konstantin; Richardson, Bruce; dev at dpdk.org
>> Subject
On 15/10/15 11:43, Younghwan Go wrote:
> Hi Zoltan,
>
> Thanks for the email.
>
> 2015-10-15 ?? 7:23? Zoltan Kiss ?(?) ? ?:
>>
>>
>> On 15/10/15 09:32, Younghwan Go wrote:
>>> Hi,
>>>
>>> I'm pretty new to playing with DPDK. I w
On 15/10/15 16:43, Ananyev, Konstantin wrote:
>
>
>> -Original Message-----
>> From: Zoltan Kiss [mailto:zoltan.kiss at linaro.org]
>> Sent: Thursday, October 15, 2015 11:33 AM
>> To: Ananyev, Konstantin; Richardson, Bruce; dev at dpdk.org
>> Subject
On 19/10/15 19:57, Ananyev, Konstantin wrote:
>
>
>> -Original Message-----
>> From: Zoltan Kiss [mailto:zoltan.kiss at linaro.org]
>> Sent: Monday, October 19, 2015 5:30 PM
>> To: Ananyev, Konstantin; Richardson, Bruce; dev at dpdk.org
>> Subject: Re: [P
haviour of other receive functions.
Signed-off-by: Zoltan Kiss
---
diff --git a/drivers/net/ixgbe/ixgbe_rxtx_vec.c
b/drivers/net/ixgbe/ixgbe_rxtx_vec.c
index cf25a53..51299fa 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx_vec.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx_vec.c
@@ -502,6 +502,15 @@ _recv_ra
On 02/09/15 15:08, Jay Rolette wrote:
> On Wed, Sep 2, 2015 at 7:56 AM, Bruce Richardson intel.com
>> 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, c
Hi,
I just realized I've missed the "[PATCH]" tag from the subject. Did
anyone had time to review this?
Regards,
Zoltan
On 01/09/15 20:17, Zoltan Kiss wrote:
> The lack of this prefetch causes a significant performance drop in
> OVS-DPDK: 13.3 Mpps instead of 14 wh
On 07/09/15 13:57, Richardson, Bruce wrote:
>
>
>> -Original Message-----
>> From: Zoltan Kiss [mailto:zoltan.kiss at linaro.org]
>> Sent: Monday, September 7, 2015 1:26 PM
>> To: dev at dpdk.org
>> Cc: Ananyev, Konstantin; Richardson, Bruce
>> S
Hi,
The recv function does a prefetch on cacheline1, however it seems to me
that rx_pkts[pos] should be uninitialized pointer at that time:
http://dpdk.org/browse/dpdk/tree/drivers/net/ixgbe/ixgbe_rxtx_vec.c#n287
So I guess it prefetches only random value. Or am I missing something?
Regards,
Hi,
On 01/07/16 11:19, Sergio Gonzalez Monroy wrote:
> On 01/07/2016 11:16, Elo, Matias (Nokia - FI/Espoo) wrote:
>>> -Original Message-
>>> From: Sergio Gonzalez Monroy [mailto:sergio.gonzalez.monroy at intel.com]
>>> Sent: Friday, July 01, 2016 1:05 PM
>>> To: Elo, Matias (Nokia - FI/Esp
d a static library depending on DPDK
This patch merges the two version and make the behaviour rely on the
config.
If we can agree in the concept, I can send a series to fix this for the
other weak functions.
Signed-off-by: Zoltan Kiss
---
drivers/net/i40e/i40e_rxtx.
The new mempool handler interface forgets to register the free() function
of the ops. Introduced in this patch:
449c49b9 mempool: support handler operations
Signed-off-by: Zoltan Kiss
---
lib/librte_mempool/rte_mempool_ops.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib
;t break applications
previously not failing due to the truncating bug now fixed.
Signed-off-by: Zoltan Kiss
---
lib/librte_eal/common/include/rte_memzone.h | 2 +-
lib/librte_mempool/rte_mempool.h| 4 +++-
lib/librte_ring/rte_ring.h | 5 -
3 files changed, 8 inser
On 19/07/16 16:37, Olivier Matz wrote:
> Hi Zoltan,
>
> On 07/19/2016 04:37 PM, Zoltan Kiss wrote:
>> A recent fix brought up an issue about the size of the 'name' fields:
>>
>> 85cf0079 mem: avoid memzone/mempool/ring name truncation
>
On 19/07/16 16:26, Olivier Matz wrote:
> Hi Zoltan,
>
> I ran ./scripts/check-git-log.sh on your patch, showing some minor
> styling issues:
Thanks, do you want me to resend it, or could Thomas fix them upon
commiting?
>
> On 07/19/2016 04:37 PM, Zoltan Kiss wrote:
>&
On 19/07/16 17:17, Olivier Matz wrote:
> Hi Zoltan,
>
> On 07/19/2016 05:59 PM, Zoltan Kiss wrote:
>>
>>
>> On 19/07/16 16:37, Olivier Matz wrote:
>>> Hi Zoltan,
>>>
>>> On 07/19/2016 04:37 PM, Zoltan Kiss wrote:
>>>> A
d a static library depending on DPDK
This patch merges the two version and make the behaviour rely on the
config.
If we can agree in the concept, I can send a series to fix this for the
other weak functions.
Signed-off-by: Zoltan Kiss
---
Notes:
v2: fix commit message
drivers/net/i40e/i
The new mempool handler interface forgets to register the free() function
of the ops. Introduced in this patch:
Fixes: 449c49b93a6b ("mempool: support handler operations")
Signed-off-by: Zoltan Kiss
Acked-by: Olivier Matz
---
Notes:
v2: fix commit message
lib/libr
int. Applications
relying on these constants need to be recompiled, otherwise they'll run
into ENAMETOOLONG issues.
The size of the arrays are kept 32 for ABI compatibility, it can be
decreased next time the ABI changes.
Signed-off-by: Zoltan Kiss
---
Notes:
v2: keep arrays 32 bytes and
(strlen(name) == sizeof(mz->name) - 1) is a valid case, change the
condition to reflect that.
Move it earlier to avoid lookup with invalid name.
Change errno to ENAMETOOLONG.
Fixes: 85cf0079 ("mem: avoid memzone/mempool/ring name truncation")
Signed-off-by: Zoltan Kiss
---
l
On 20/07/16 14:37, Olivier Matz wrote:
> Hi,
>
> On 07/20/2016 02:41 PM, Zoltan Kiss wrote:
>>
>>
>> On 19/07/16 17:17, Olivier Matz wrote:
>>> Hi Zoltan,
>>>
>>> On 07/19/2016 05:59 PM, Zoltan Kiss wrote:
>>>>
>>>>
On 21/07/16 14:40, Olivier Matz wrote:
> Hi Zoltan,
>
>
> On 07/20/2016 07:16 PM, Zoltan Kiss wrote:
>> A recent patch brought up an issue about the size of the 'name' fields:
>>
>> 85cf0079 mem: avoid memzone/mempool/ring name truncation
>>
>&g
On 21/07/16 19:58, bynes adam wrote:
> On Wed, Jul 20, 2016 at 06:11:16PM +0100, Zoltan Kiss wrote:
> Hi, Kiss
>> Using weak symbols have a few issues with static linking:
>>
>> - normally the linker searches the .o files already linked, if your weak
>> one is the
This returns the error code provided by pcap_sendpacket()
Signed-off-by: Zoltan Kiss
diff --git a/drivers/net/pcap/rte_eth_pcap.c b/drivers/net/pcap/rte_eth_pcap.c
index 7e213eb..0899bac 100644
--- a/drivers/net/pcap/rte_eth_pcap.c
+++ b/drivers/net/pcap/rte_eth_pcap.c
@@ -41,6 +41,7
Hi,
I forgot to add the i40 maintainers as well. Would anyone like to weigh in?
Regards,
Zoltan
On 22/07/16 12:34, Zoltan Kiss wrote:
>
>
> On 21/07/16 19:58, bynes adam wrote:
>> On Wed, Jul 20, 2016 at 06:11:16PM +0100, Zoltan Kiss wrote:
>> Hi, Kiss
>>> Using
This check doesn't do what's required by rte_eth_tx_burst:
"When the number of previously sent packets reached the "minimum transmit
packets to free" threshold"
This can cause problems when txq->tx_free_thresh + [number of elements in the
pool] < txq->
at is motivating this change?
>
> Regards,
> Venky
>
>
>> On May 28, 2015, at 1:42 AM, Zoltan Kiss wrote:
>>
>> This check doesn't do what's required by rte_eth_tx_burst:
>> "When the number of previously sent packets reached the "mi
Hi,
I've came across an another problem while sorting out the one fixed by
my patch "ixgbe: fix checking for tx_free_thresh". Even when the
threshold check is correct it can happen that the application run out of
free buffers, and the only solution would be to get back the ones from
the TX rin
Also, there could be places in the code where we change a set of
continuous fields in the mbuf. E.g. ixgbe vector pmd receive function
takes advantage of 128 bit vector registers and fill out
rx_descriptor_fields1 with one instruction. But I guess there are other
places too, and they are really
On 14/07/15 19:21, Polevoy, Igor wrote:
> Hi,
> We are developing an application that uses DPDK PMD functionality .
> We are using a linux shared library which contains the network packets
> processing code and it is statically linked with all the necessary DPDK libs.
> The .so is loaded by the
he first half of this 32 byte array. But
_recv_raw_pkts_vec() seems to use the whole array. Is this a bug or a
feature? Or am I mistaken in the math somewhere?
Regards,
Zoltan Kiss
fixed by changing the uint32_t values to be uint64_t
> instead.
>
> Fixes: cf4b4708a88a ("ixgbe: improve slow-path perf with vector scattered Rx")
>
> Reported-by: Zoltan Kiss
> Signed-off-by: Bruce Richardson
>
> ---
> V2: Rename variable from
On 22/07/15 10:59, Bruce Richardson wrote:
> On Wed, Jul 22, 2015 at 10:47:34AM +0100, Zoltan Kiss wrote:
>> Hi,
>>
>> And what happens if someone changes RTE_IXGBE_VPMD_RX_BURST to something
>> else than 32? I guess this bug were introduced when someone raised it fr
On 22/07/15 14:19, Zoltan Kiss wrote:
> Btw. vPMD was a bit misleading abbreviation for me, it took me a while
> until I realized 'v' stands for 'vector', not 'virtualization' as in
> most cases nowadays.
>
Though that's mostly my fault to not to check the documentation :)
ts on the descriptor ring, it will go out in some finite time, or
if the card itself drops it, it will appear in the stats at least, but
the oerrors and q_errors values are always 0.
Does anyone has an idea where could those packets (avg 0.6 Mpps) get
dropped?
Regards,
Zoltan Kiss
On 23/07/15 12:15, Zoltan Kiss wrote:
> Hi,
>
> I've seen an odd behaviour in my test setup, which affected my test
> results, so I set up a much simpler scenario.
> I'm using netmap pktgen as a packet source, it creates a steady 14.2
> Mpps of 64 byte UDP packets ove
Hi,
On 24/07/15 11:13, Ciprian Barbu wrote:
> From: Ciprian Barbu
>
> This tries to show an approximate behavior described in an earlier discussion
> called "can eth_igb_xmit_pkts called with len 0 affect transmission?"
>
> I'm using Intel i350 dual port 1Gb card and I've tweaked the pool size to
Hi,
I was thinking how to handle the situation when you call
rte_eth_rx_burst with less than RTE_IXGBE_VPMD_RX_BURST buffers. In
ODP-DPDK unfortunately we can't force this requirement onto the calling
application.
One idea I had to check in ixgbe_recv_pkts_vec() if nb_pkts <
RTE_IXGBE_VPMD_RX_
o:dev-bounces at dpdk.org] On Behalf Of Zoltan Kiss
>> Sent: Friday, July 24, 2015 4:00 PM
>> To: Richardson, Bruce; dev at dpdk.org
>> Subject: [dpdk-dev] ixgbe vPMD RX functions and buffer number minimum
>> requirement
>>
>> Hi,
>>
>> I was thinking
Hi,
On 28/07/15 01:10, Ananyev, Konstantin wrote:
> Hi Zoltan,
>
>> -Original Message-----
>> From: Zoltan Kiss [mailto:zoltan.kiss at linaro.org]
>> Sent: Monday, July 27, 2015 12:38 PM
>> To: Ananyev, Konstantin; Richardson, Bruce; dev at dpdk.org
>> S
On 31/07/15 09:17, Cunming Liang wrote:
> The patch removes the restriction of burst size on a constant 32.
>
> On receive side, the burst size floor now aligns to RTE_IXGBE_DESCS_PER_LOOP
> power of 2.
> According to this rule, the burst size less than 4 still won't receive
> anything.
> (Befo
On 31/07/15 11:21, Ananyev, Konstantin wrote:
>
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zoltan Kiss
>> Sent: Friday, July 31, 2015 11:04 AM
>> To: Liang, Cunming; dev at dpdk.org
>> Subject: Re: [dpdk-dev]
On 31/07/15 12:57, Zoltan Kiss wrote:
>>
>> Another thing, that I just thought about:
>> Right now we invoke ixgbe_rxq_rearm() only at the start of
>> _recv_raw_pkts_vec().
>> Before it was ok, as _recv_raw_pkts_vec() would never try to read more
>> then
Hi,
Anyone would like to review this patch? Venky sent a NAK, but I've
explained to him why it is a bug.
Regards,
Zoltan
On 27/05/15 21:12, Zoltan Kiss wrote:
> This check doesn't do what's required by rte_eth_tx_burst:
> "When the number of previously sent pa
On 01/06/15 09:50, Andriy Berestovskyy wrote:
> Hi Zoltan,
>
> On Fri, May 29, 2015 at 7:00 PM, Zoltan Kiss
> wrote:
>> The easy way is just to increase your buffer pool's size to make
>> sure that doesn't happen.
>
> Go for it!
I went for it,
On 02/06/15 14:31, Ananyev, Konstantin wrote:
> Hi Zoltan,
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zoltan Kiss
>> Sent: Monday, June 01, 2015 5:16 PM
>> To: dev at dpdk.org
>> Subject: Re: [dpdk-
On 02/06/15 18:35, Ananyev, Konstantin wrote:
>
>
>> -Original Message-----
>> From: Zoltan Kiss [mailto:zoltan.kiss at linaro.org]
>> Sent: Tuesday, June 02, 2015 4:08 PM
>> To: Ananyev, Konstantin; dev at dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH] ix
On 10/03/16 07:51, Wu, Jingjing wrote:
> Hi, Zoltan
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zoltan Kiss
>> Sent: Wednesday, March 2, 2016 3:19 AM
>> To: dev at dpdk.org
>> Subject: [dpdk-dev] ixgbe TX fun
On 14/03/16 17:54, Saurabh Mishra wrote:
> Hi,
>
> We are planning to support virtio, vmxnet3, ixgbe, i40e, bxn2x and SR-IOV
> on some of them with DPDK.
>
> We have seen that even if we give correct number of mbufs given the number
> hugepages reserved, rte_eth_tx_queue_setup() may still fail wi
On 18/03/16 00:45, Lu, Wenzhuo wrote:
> Hi Zoltan,
>
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zoltan Kiss
>> Sent: Friday, March 18, 2016 1:11 AM
>> To: Wu, Jingjing; dev at dpdk.org
>> Subject: Re:
At the original point the rx_pkts[pos( + n)] pointers are not initialized, so
the code is prefetching random data.
Signed-off-by: Zoltan Kiss
diff --git a/drivers/net/ixgbe/ixgbe_rxtx_vec.c
b/drivers/net/ixgbe/ixgbe_rxtx_vec.c
index 3c6d8c5..ccd93c7 100644
--- a/drivers/net/ixgbe
On 25/09/15 04:47, Mcnamara, John wrote:
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zoltan Kiss
>> Sent: Friday, September 25, 2015 1:23 AM
>> To: dev at dpdk.org
>> Subject: [dpdk-dev] [PATCH] ixgbe: prefetch cacheline
At the original point the rx_pkts[pos( + n)] pointers are not initialized, so
the code is prefetching random data.
Signed-off-by: Zoltan Kiss
---
v2: fixing tabs
diff --git a/drivers/net/ixgbe/ixgbe_rxtx_vec.c
b/drivers/net/ixgbe/ixgbe_rxtx_vec.c
index 3c6d8c5..ccd93c7 100644
--- a/drivers/net
On 07/09/15 07:41, Richardson, Bruce wrote:
>
>> -Original Message-
>> From: Zoltan Kiss [mailto:zoltan.kiss at linaro.org]
>> Sent: Monday, September 7, 2015 3:15 PM
>> To: Richardson, Bruce; dev at dpdk.org
>> Cc: Ananyev, Konstantin
>> Subject: Re:
This test selects AVX2 code even if the target architecture doesn't support it.
Signed-off-by: Zoltan Kiss
---
diff --git a/lib/librte_acl/Makefile b/lib/librte_acl/Makefile
index 46acc2b..17a9f96 100644
--- a/lib/librte_acl/Makefile
+++ b/lib/librte_acl/Makefile
@@ -57,7
Hi,
On 19/05/16 13:18, Ananyev, Konstantin wrote:
> I wonder does anyone really use mbuf port field?
> My though was - could we to drop it completely?
There are a few example codes which are reading the port field. Although
they can retain this metadata in the private area of the mbuf, right
af
On 09/06/15 12:18, Ananyev, Konstantin wrote:
>
>
>> -Original Message-----
>> From: Zoltan Kiss [mailto:zoltan.kiss at linaro.org]
>> Sent: Wednesday, June 03, 2015 6:47 PM
>> To: Ananyev, Konstantin; dev at dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH] ix
1 - 100 of 103 matches
Mail list logo
