On 28 March 2016 at 15:42, Thomas Monjalon
wrote:
> Hi Marc,
>
> 2016-03-27 21:39, Marc:
> > On 27 March 2016 at 11:53, Thomas Monjalon
> > wrote:
> > > 2016-03-26 11:24, Marc:
> > > > On 26 March 2016 at 09:08, Thomas Monjalon <
> thomas.monjalon at 6wind.com>
> > > > wrote:
> > > > > 2016-03-2
Hi Olivier,
We could have two threads (running on different cores in the general
case) that both succeed the cmpset operation. In the dequeue path,
when n == 0, then cons_next == cons_head, and cmpset will always
succeed. Now, if they both see an old r->cons.tail value from a
previous dequeue, the
Hi,
Looking into why it hurts performance, I see that ixgbe_dev_rx_queue_count
is implemented a scan of elements of rx descriptors, which is very
expensive. I am wondering why its implemented the way it is. Could it not
just read the head location from the driver?
Thanks!
Mohammad El-Shabani
Hi Wenzhuo,
Thanks. For some reason, we have to stick to dpdk 2.0 for now. Is multi-segment
mbuf supported in this version (any known issue with multi-seg in this
version?) or do we have to upgrade to latest dpdk version for multi-segment
support?
Clarylin
> On Mar 28, 2016, at 6:10 PM, Lu,
For f_tx_bulk functions in rte_port_ethdev.c, we may unintentionally
send bursts larger than tx_burst_sz to the underlying ethdev.
Some PMDs (e.g., ixgbe) may truncate this request to their maximum
burst size, resulting in unnecessary enqueuing failures or ethdev
writer retries.
We propose to fix
For several f_tx_bulk functions in rte_port_{ethdev,ring,sched}.c,
it appears that the intent of the bsz_mask logic is to test whether
pkts_mask contains a full burst (i.e., the least
significant bits are set).
There are two problems with the bsz_mask code: 1) It truncates
by using the wrong size
Ring writer tx_bulk functions may write past the end of tx_buf[].
Solution is to double the size of tx_buf[].
Signed-off-by: Robert Sanford
---
lib/librte_port/rte_port_ring.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/librte_port/rte_port_ring.c b/lib/librte
Add code to send two 60-packet bursts to a ring port_out.
This tests a ring writer buffer overflow problem and fix
(in patch 2/4).
Signed-off-by: Robert Sanford
---
app/test/test_table_ports.c | 27 +--
1 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/app
This patch series does the following:
* enhances port ring writer test, to send two large, but not full
bursts; exposes ring writer buffer overflow
* fixes ring writer buffer overflow
* fixes full burst checks in ethdev, ring, and sched f_tx_bulk ops
* fixes ethdev writer, to send bursts no larg
Hi Qian,
On 28 March 2016 at 10:30, Xu, Qian Q wrote:
> Jianbo
> Could you tell me the case that can reproduce the issue? We can help evaluate
> the impact of performance on ixgbe, but I'm not sure how to check if your
> patch really fix a problem because I don?t know how to reproduce the probl
Hi Marc,
2016-03-27 21:39, Marc:
> On 27 March 2016 at 11:53, Thomas Monjalon
> wrote:
> > 2016-03-26 11:24, Marc:
> > > On 26 March 2016 at 09:08, Thomas Monjalon
> > > wrote:
> > > > 2016-03-25 22:30, Marc:
> > > > > From v9 to v10 patchset the values ETH_LINK_SPEED_AUTONEG and
> > > > ETH_LIN
Calling rte_eth_dev_get_dcb_info to get dcb info from i40e
driver if VMDQ is disabled, results in a segmentation fault.
This patch fixes it by treating VMDQ and No-VMDQ respectively
when querying dcb information.
Fixes: 5135f3ca49a7 ("i40e: enable DCB in VMDQ VSIs")
Signed-off-by: Jingjing Wu
--
Now that vmxnet3 supports TCP/UDP checksum offload, let's update
the default txq flags to allow such offloads. Also fixed the tx
queue setup check to allow TCP/UDP checksum and only error out
if SCTP checksum is requested.
Fixes: f598fd063bb1 ("vmxnet3: add Tx L4 checksum offload")
Reported-by:
I will have one of my team members follow the instructions and we'll have a
patch out this week hopefully.
On Thu, Mar 24, 2016 at 7:04 AM, Bruce Richardson <
bruce.richardson at intel.com> wrote:
> On Wed, Mar 23, 2016 at 01:44:46PM -0500, Michael Habibi wrote:
> > We are using the i40 implement
ixgbe_recv_scattered_pkts was set to be the rx function. Receiving packets
smaller than mbuf size works perfectly. However, if an incoming packet is
greater than the maximum acceptable length of one ?mbuf? data size,
receiving does not work. In this case, isn't it supposed to use
mbuf chaining to r
On 28 March 2016 at 03:54, Lu, Wenzhuo wrote:
> Hi Marc
>
>
>
> *From:* Marc Sune [mailto:marcdevel at gmail.com]
> *Sent:* Saturday, March 26, 2016 9:43 AM
> *To:* dev at dpdk.org; Lu, Wenzhuo
> *Subject:* e1000: randomly loosing link change events triggered by the
> peer
>
>
>
> I found that in
On 26 March 2016 at 09:12, Jan Viktorin wrote:
> Hello,
>
> while extending the DPDK by a kind of platform devices (for the 16.07), an
> access to the FDT might be necessary (or at least very helpful). This patch
> series for 16.07 introduces an approach to solve this topic.
>
> The API is designe
Any pointers to what the issue could be? thanks
On Fri, Mar 25, 2016 at 4:13 PM, Clarylin L wrote:
> Hello,
>
> I am trying to use multi-segment mbuf to receive large packet. I enabled
> jumbo_frame and enable_scatter for the port and was expecting mbuf chaining
> would be used to receive packet
The lower 16 bits of EICR register are used for queue interrupts,
dpdk framework take over the first bit for other interrupts like
LSC, so there're only 15 bits left for queue interrupts mapping.
This patch adds a check for the num of interrupt queues at
dev_start.
Signed-off-by: Wang Xiao W
---
Jianbo
Could you tell me the case that can reproduce the issue? We can help evaluate
the impact of performance on ixgbe, but I'm not sure how to check if your patch
really fix a problem because I don?t know how to reproduce the problem! Could
you first teach me on how to reproduce your issue? Or
Tested-by: Qian Xu
- Test Commit: 8f6f24342281f59de0df7bd976a32f714d39b9a9
- OS/Kernel: Fedora 21/4.1.13
- GCC: gcc (GCC) 4.9.2 20141101 (Red Hat 4.9.2-1)
- CPU: Intel(R) Xeon(R) CPU E5-2695 v4 @ 2.10
- NIC: Intel(R) Ethernet Controller X710 for 10GbE SFP+
- Total 2 cases, 2 passed, 0 failed.
T
Hi Marc
From: Marc Sune [mailto:marcde...@gmail.com]
Sent: Saturday, March 26, 2016 9:43 AM
To: dev at dpdk.org; Lu, Wenzhuo
Subject: e1000: randomly loosing link change events triggered by the peer
I found that in the current HEAD in master testing it with an I218-LM in
autoneg mode, when link
Hi,
> -Original Message-
> From: Wang, Xiao W
> Sent: Monday, March 28, 2016 8:40 AM
> To: Lu, Wenzhuo
> Cc: dev at dpdk.org; Wang, Xiao W
> Subject: [PATCH] ixgbe: return err for too many interrupt queues
>
> The lower 16 bits of EICR register are used for queue interrupts, dpdk
> fram
23 matches
Mail list logo
