On 4 Nov 2019, at 18:42, Burakov, Anatoly
mailto:anatoly.bura...@intel.com>> wrote:
On 04-Nov-19 5:34 PM, Damjan Marion (damarion) wrote:
On 4 Nov 2019, at 18:27, Burakov, Anatoly
mailto:anatoly.bura...@intel.com>> wrote:
On 04-Nov-19 1:57 PM, Damjan Marion (damarion) wrote:
On
> On 4 Nov 2019, at 18:27, Burakov, Anatoly wrote:
>
> On 04-Nov-19 1:57 PM, Damjan Marion (damarion) wrote:
>>> On 25 Oct 2019, at 15:02, Damjan Marion (damarion) >> <mailto:damar...@cisco.com>> wrote:
>>>
>>>
>>>
>>>
On 27 Oct 2019, at 08:00, Shahaf Shuler
mailto:shah...@mellanox.com>> wrote:
-Original Message-
From: Damjan Marion (damarion) mailto:damar...@cisco.com>>
Sent: Friday, October 25, 2019 2:14 PM
To: Thomas Monjalon mailto:tho...@monjalon.net>>
Cc: David Marchand
On 25 Oct 2019, at 15:02, Damjan Marion (damarion)
mailto:damar...@cisco.com>> wrote:
On 25 Oct 2019, at 14:23, Burakov, Anatoly
mailto:anatoly.bura...@intel.com>> wrote:
On 25-Oct-19 12:13 PM, Damjan Marion (damarion) wrote:
On 25 Oct 2019, at 00:32, Thomas Monjalon
rruh
>> ; jerinjac...@gmail.com; Ye, Xiaolong
>> ; Kinsella, Ray ; Sun,
>> Chenmin ; Slava Ovsiienko
>> ; Damjan Marion (damarion)
>> ; Liu, Yu Y
>> Subject: RE: [PATCH v1 3/3] ethdev: enhance the API for getting burst mode
>> information
>>
>
On 25 Oct 2019, at 14:23, Burakov, Anatoly
mailto:anatoly.bura...@intel.com>> wrote:
On 25-Oct-19 12:13 PM, Damjan Marion (damarion) wrote:
On 25 Oct 2019, at 00:32, Thomas Monjalon
mailto:tho...@monjalon.net>> wrote:
24/10/2019 21:09, David Marchand:
On Thu, Oct 24, 2019 at 2:1
> On 25 Oct 2019, at 00:32, Thomas Monjalon wrote:
>
> 24/10/2019 21:09, David Marchand:
>> On Thu, Oct 24, 2019 at 2:18 PM Anatoly Burakov
>> wrote:
>>>
>>> The rte_vfio_dma_map/unmap API's have been marked as deprecated in
>>> release 19.05. Remove them.
>>>
>>> Signed-off-by: Anatoly Bura
--
Damjan
On 7 May 2019, at 13:29, Honnappa Nagarahalli
mailto:honnappa.nagaraha...@arm.com>> wrote:
On 3/22/2019 11:57 AM, Jakub Grajciar wrote:
Memory interface (memif), provides high performance packet transfer
over shared memory.
Signed-off-by: Jakub Grajciar mailto:jgraj...@cisco.com>>
> On 6 May 2019, at 13:00, Jakub Grajciar -X (jgrajcia - PANTHEON TECHNOLOGIES
> at Cisco) wrote:
>
>
>
> From: Honnappa Nagarahalli
> Sent: Friday, May 3, 2019 6:27 AM
> To: Jakub Grajciar; Ferruh Yigit; dev@dpdk.org; Honnappa Nagarahalli
> Cc: nd; n
Fixes: 75d133dd3296 ("net/i40e: enable 25G device")
Cc: sta...@dpdk.org
Signed-off-by: Damjan Marion
---
drivers/net/i40e/i40e_ethdev.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/i40e/i40e_ethdev.h b/drivers/net/i40e/i40e_ethdev.h
index
At this point valid data is already set by rte_eth_get_device_info.
device field becomes zero and consumer is not able to retrieve pci data.
Signed-off-by: Damjan Marion
---
drivers/net/i40e/i40e_ethdev_vf.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/i40e/i40e_ethdev_vf.c
b
Hi,
Currently in VPP we do memcpy of whole packet when we need to do
replication as we cannot know if specific buffer is transmitted
from tx ring before we update it again (i.e. l2 header rewrite).
Unless there is already a way to address this issue in DPDK which I?m not aware
of my proposal is
2] i40e: Enable bad checksum flags in i40e vPMD
From: Damjan Marion mailto:damar...@cisco.com>>
Decode the checksum flags from the rx descriptor, setting the appropriate bit
in the mbuf ol_flags field when the flag indicates a bad checksum.
Signed-off-by: Damjan Marion mailto:d
> On 15 Jul 2016, at 17:08, Thomas Monjalon
> wrote:
>
> 2016-07-15 16:37, Thomas Monjalon:
>> I will apply it with trivial changes suggested by Jan and
>> the small needed changes that I describe below:
>>
>> 2016-07-14 20:03, Jan Viktorin:
>>> On Thu, 14 Jul 2016 15:27:29 +0200
>>> damarion
> On 15 Jul 2016, at 12:09, Thomas Monjalon
> wrote:
>
> 2016-07-15 09:54, Damjan Marion:
>> So we don?t have much pending beside 2 patches for i40e which
>> Jeff submitted yesterday and they will i guess need to wait for 16.11.
>
> Yes these i40e patches wi
> On 15 Jul 2016, at 10:31, Thomas Monjalon
> wrote:
>
> 2016-07-14 22:20, Damjan Marion:
>>
>>> On 15 Jul 2016, at 00:06, Thomas Monjalon
>>> wrote:
>>>
>>> 2016-07-14 18:10, Damjan Marion:
>>>> Dear Jan,
>>>&g
> On 15 Jul 2016, at 00:06, Thomas Monjalon
> wrote:
>
> 2016-07-14 18:10, Damjan Marion:
>> Dear Jan,
>>
>> Thank you for your comments. A bit too much overhead to submit simple patch
>> so let?s forget about it. I will just add it as it is to our private
ower case
> letter, so "move constructor..."
>
> On Thu, 14 Jul 2016 15:27:29 +0200
> damarion at cisco.com wrote:
>
>> From: Damjan Marion
>>
>> Having constructor function in the header gile is generaly
>
> I'd write:
>
> Having con
> On 14 Jul 2016, at 13:30, Thomas Monjalon
> wrote:
>
> 2016-07-14 09:36, Damjan Marion:
>>>>
>>>> linking fails with:
>>>> dpdk/include/rte_spinlock.h:103: undefined reference to
>>>> `rte_cpu_get_flag_enabled?
>>>>
&
> On 14 Jul 2016, at 10:20, Thomas Monjalon
> wrote:
>
> 2016-07-13 22:58, Damjan Marion:
>> I have issues with linking application to 16.07-rc2.
>>
>> Looks like reason is constructor function in include file,
>> so our unit test apps are failing to l
Folks,
I have issues with linking application to 16.07-rc2.
Looks like reason is constructor function in include file,
so our unit test apps are failing to link as they are not linked with dpdk libs.
(and they should not be as they are not calling any dpdk function).
static inline void __attri
> On 21 Jun 2016, at 09:01, Ferruh Yigit wrote:
>
> Hi Damjan,
>
> On 6/21/2016 4:01 PM, Damjan Marion (damarion) wrote:
>>
>> Hello,
>>
>> We just spent few hours troubleshooting why vPMD is not working
>> in i40e driver. Conclusion was tha
Hello,
We just spent few hours troubleshooting why vPMD is not working
in i40e driver. Conclusion was that problem is caused by linker
linking the wrong instance of the i40e_rx_vec_dev_conf_condition_check(...).
That function is defined 2 times, once in i40e_rxtx.c and once in
i40e_rxtx_vec.c.
> On 17 Jun 2015, at 16:06, Bruce Richardson
> wrote:
>
> On Wed, Jun 17, 2015 at 01:55:57PM +0000, Damjan Marion (damarion) wrote:
>>
>>> On 15 Jun 2015, at 16:12, Bruce Richardson
>>> wrote:
>>>
>>> The next pointers always sta
> On 15 Jun 2015, at 16:12, Bruce Richardson
> wrote:
>
> The next pointers always start out as NULL when the mbuf pool is created. The
> only time it is set to non-NULL is when we have chained mbufs. If we never
> have
> any chained mbufs, we never need to touch the next field, or even read i
This patch improves performance of vectored rx on i40e devices.
Signed-off-by: Damjan Marion
---
drivers/net/i40e/i40e_rxtx.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
index 2de0ac4..152e9e6 100644
--- a/drivers/net/i40e
Hi,
We noticed 7% performance improvement by simply moving rte_mbuf.next field to
the 1st cache line.
Currently, it falls under /* second cache line - fields only used in slow path
or on TX */
but it is actually used at several places in rx fast path. (e.g.:
i40e_rx_alloc_bufs() is setting th
Fix NULL dereference if virtio control queue is not negotiated.
Signed-off-by: Damjan Marion
---
drivers/net/virtio/virtio_ethdev.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/virtio/virtio_ethdev.c
b/drivers/net/virtio/virtio_ethdev.c
index f74e413
> On 06 Feb 2015, at 11:26, De Lara Guarch, Pablo intel.com> wrote:
>
>
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Linhaifeng
>> Sent: Friday, February 06, 2015 2:04 AM
>> To: Damjan Marion (damarion); de
> On 05 Feb 2015, at 15:59, Neil Horman wrote:
>
> On Thu, Feb 05, 2015 at 01:20:01PM +0000, Damjan Marion (damarion) wrote:
>>
>>> On 05 Feb 2015, at 13:59, Neil Horman wrote:
>>>
>>> On Thu, Feb 05, 2015 at 12:00:48PM +, Damjan Marion (damarion
On 05 Feb 2015, at 14:22, Jay Rolette mailto:rolette
at infiniteio.com>> wrote:
On Thu, Feb 5, 2015 at 6:00 AM, Damjan Marion (damarion) mailto:damarion at cisco.com>> wrote:
Hi,
I have system with 2 NUMA nodes and 256G RAM total. I noticed that DPDK crashes
in rte_eal_init()
wh
> On 05 Feb 2015, at 13:59, Neil Horman wrote:
>
> On Thu, Feb 05, 2015 at 12:00:48PM +0000, 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
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).
I also tried with allocating 4 on node0 and 0 on node1, same crash happens.
On 17 Sep 2014, at 09:32, Olivier MATZ wrote:
> Hello,
>
> On 09/12/2014 12:25 AM, damarion at cisco.com wrote:
>> From: Damjan Marion
>>
>> If VIRTIO_NET_F_CTRL_VQ is not negotiated hw->cvq will be NULL
>>
>> Signed-off-by: Damjan Marion
>>
34 matches
Mail list logo
