On 27 Oct 2023, at 11:22, David Marchand wrote:
> On Fri, Oct 27, 2023 at 11:05 AM Eelco Chaudron wrote:
>>> diff --git a/lib/vhost/virtio_net.c b/lib/vhost/virtio_net.c
>>> index 759a78e3e3..4116f79d4f 100644
>>> --- a/lib/vhost/virtio_net.c
>>> +++
On 23 Oct 2023, at 11:55, David Marchand wrote:
> Modifying vq->access_ok should be done with a write lock taken.
> Annotate vring_translate() and vring_invalidate() and add missing locks.
>
> Signed-off-by: David Marchand
The changes look good to me.
Acked-by: Eelco Chaudron
ck taken before
> calling vring_translate().
>
> Fixes: 03f77d66d966 ("vhost: change virtqueue access lock to a read/write
> one")
> Cc: sta...@dpdk.org
>
> Signed-off-by: David Marchand
Only one question, but whatever the outcome is the change looks good to me.
hand
This change looks good to me.
Acked-by: Eelco Chaudron
essure.
>
> Signed-off-by: Maxime Coquelin
Thanks for adding this Maxime. I did some tests with OVS and my old determinism
patchset, and it works perfectly.
I have two small nits, but this change looks good to me.
Acked-by: Eelco Chaudron
> ---
>
> v3: s/0/false/ (David)
>
>
c ("net/iavf: rework Tx path")
> Cc: sta...@dpdk.org
Thanks for fixing this David! I tested and reviewed this change and it works
now.
Tested-by: Eelco Chaudron
Acked-by: Eelco Chaudron
> Signed-off-by: David Marchand
> ---
> drivers/net/iavf/iavf_rxtx.c | 4
> 1
On 1 Jun 2023, at 22:00, Maxime Coquelin wrote:
> On 5/17/23 11:08, Eelco Chaudron wrote:
>> This series adds an operation callback which gets called every time the
>> library wants to call eventfd_write(). This eventfd_write() call could
>> result in a system call, wh
On 1 Jun 2023, at 10:29, Maxime Coquelin wrote:
> On 6/1/23 10:15, Eelco Chaudron wrote:
>>
>>
>> On 1 Jun 2023, at 4:18, Xia, Chenbo wrote:
>>
>>>> -Original Message-
>>>> From: Maxime Coquelin
>>>> Sent: Wednesd
On 1 Jun 2023, at 4:18, Xia, Chenbo wrote:
>> -Original Message-
>> From: Maxime Coquelin
>> Sent: Wednesday, May 31, 2023 5:29 PM
>> To: Xia, Chenbo ; Thomas Monjalon
>> ; Eelco Chaudron ;
>> david.march...@redhat.com
>> Cc: dev@dpdk.org
On 31 May 2023, at 14:48, Maxime Coquelin wrote:
> On 5/31/23 14:01, David Marchand wrote:
>> Eelco, Maxime,
>>
>> On Wed, May 17, 2023 at 11:09 AM Eelco Chaudron wrote:
>>> @@ -846,6 +848,11 @@ vhost_user_socket_mem_free(struct vhost_user_socket
>>>
On 31 May 2023, at 11:29, Maxime Coquelin wrote:
> On 5/31/23 08:19, Xia, Chenbo wrote:
>>> -Original Message-
>>> From: Maxime Coquelin
>>> Sent: Tuesday, May 30, 2023 11:17 PM
>>> To: Thomas Monjalon ; Eelco Chaudron
>>> ; Xia, Ch
On 31 May 2023, at 11:27, Maxime Coquelin wrote:
> On 5/31/23 08:37, Xia, Chenbo wrote:
>> Hi Eelco,
>>
>>> -Original Message-
>>> From: Eelco Chaudron
>>> Sent: Wednesday, May 17, 2023 5:09 PM
>>> To: maxime.coque...@redhat.com; Xia,
On 17 May 2023, at 19:33, Maxime Coquelin wrote:
> Hi Eelco,
>
> On 5/17/23 11:08, Eelco Chaudron wrote:
>> This change will allow the vhost interrupt datapath handling to be split
>> between two processed without one of them holding an explicit lock.
>>
>
>
On 16 May 2023, at 13:36, Eelco Chaudron wrote:
> On 16 May 2023, at 12:12, David Marchand wrote:
>
>> On Tue, May 16, 2023 at 10:53 AM Eelco Chaudron wrote:
>>> On 10 May 2023, at 13:44, David Marchand wrote:
>>
>> [snip]
>>
>>>>>
) now or have the newly introduced function,
rte_vhost_notify_guest(), called at a later time.
This can be used by 3rd party applications, like OVS, to avoid system
calls being called as part of the PMD threads.
Signed-off-by: Eelco Chaudron
---
lib/vhost/meson.build |2 ++
lib/vhost/rte_vh
ime Coquelin
Signed-off-by: Eelco Chaudron
---
lib/vhost/vhost.h |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/lib/vhost/vhost.h b/lib/vhost/vhost.h
index 37609c7c8d..23a4e2b1a7 100644
--- a/lib/vhost/vhost.h
+++ b/lib/vhost/vhost.h
@@ -903,9 +903,9 @@ vhost_vri
Making the guest_notifications statistic counter atomic, allows
it to be safely incremented while holding the read access_lock.
Signed-off-by: Eelco Chaudron
---
lib/vhost/vhost.c |8
lib/vhost/vhost.h |9 ++---
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git
This change will allow the vhost interrupt datapath handling to be split
between two processed without one of them holding an explicit lock.
Signed-off-by: Eelco Chaudron
---
lib/eal/include/generic/rte_rwlock.h | 17 ++
lib/vhost/vhost.c| 46 +
lib
counter.
- Mark new API as experimental.
- Change the virtual queue spin lock to read/write spin lock.
- Made shared counters atomic.
- Add versioned rte_vhost_driver_callback_register() for
ABI compliance.
Eelco Chaudron (4):
vhost: change vhost_virtqueue access lock t
On 16 May 2023, at 13:45, Maxime Coquelin wrote:
> On 5/16/23 13:36, Eelco Chaudron wrote:
>>
>>
>> On 16 May 2023, at 12:12, David Marchand wrote:
>>
>>> On Tue, May 16, 2023 at 10:53 AM Eelco Chaudron wrote:
>>>> On 10 May 202
On 16 May 2023, at 12:12, David Marchand wrote:
> On Tue, May 16, 2023 at 10:53 AM Eelco Chaudron wrote:
>> On 10 May 2023, at 13:44, David Marchand wrote:
>
> [snip]
>
>>>> @@ -846,6 +848,14 @@ vhost_user_socket_mem_free(struct vhost_user_socket
>>>&
On 10 May 2023, at 13:44, David Marchand wrote:
> On Wed, Apr 5, 2023 at 2:42 PM Eelco Chaudron wrote:
>>
>> This patch adds an operation callback which gets called every time the
>> library wants to call eventfd_write(). This eventfd_write() call could
>> result in
On 5 Apr 2023, at 14:40, Eelco Chaudron wrote:
> This series adds an operation callback which gets called every time the
> library wants to call eventfd_write(). This eventfd_write() call could
> result in a system call, which could potentially block the PMD thread.
>
> The ca
) now or have the newly introduced function,
rte_vhost_notify_guest(), called at a later time.
This can be used by 3rd party applications, like OVS, to avoid system
calls being called as part of the PMD threads.
Signed-off-by: Eelco Chaudron
---
lib/vhost/meson.build |2 +
lib/vhost/rte_vh
Making the guest_notifications statistic counter atomic, allows
it to be safely incremented while holding the read access_lock.
Signed-off-by: Eelco Chaudron
---
lib/vhost/vhost.c |8
lib/vhost/vhost.h |9 ++---
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git
This change will allow the vhost interrupt datapath handling to be split
between two processed without one of them holding an explicit lock.
Signed-off-by: Eelco Chaudron
---
lib/eal/include/generic/rte_rwlock.h | 17 ++
lib/vhost/vhost.c| 46 +
lib
ion name to VDUSE RFC patchset.
- Added error and offload statistics counter.
- Mark new API as experimental.
- Change the virtual queue spin lock to read/write spin lock.
- Made shared counters atomic.
- Add versioned rte_vhost_driver_callback_register() for
ABI compliance
On 27 Mar 2023, at 18:35, Maxime Coquelin wrote:
> On 3/27/23 18:04, Eelco Chaudron wrote:
>>
>>
>> On 27 Mar 2023, at 17:16, Gowrishankar Muthukrishnan wrote:
>>
>>> Hi Eelco,
>>>
>>>> +void
>>>> +rte_vhost_notify_guest(int
On 27 Mar 2023, at 18:35, Maxime Coquelin wrote:
> On 3/27/23 18:04, Eelco Chaudron wrote:
>>
>>
>> On 27 Mar 2023, at 17:16, Gowrishankar Muthukrishnan wrote:
>>
>>> Hi Eelco,
>>>
>>>> +void
>>>> +rte_vhost_notify_guest(int
On 27 Mar 2023, at 17:16, Gowrishankar Muthukrishnan wrote:
> Hi Eelco,
>
>> +void
>> +rte_vhost_notify_guest(int vid, uint16_t queue_id) {
>> +struct virtio_net *dev = get_device(vid);
>> +struct vhost_virtqueue *vq;
>> +
>> +if (!dev || queue_id >= VHOST_MAX_VRING)
>> +
On 27 Mar 2023, at 15:21, Maxime Coquelin wrote:
> Hi Eelco,
>
> On 3/27/23 14:51, Eelco Chaudron wrote:
>> This patch adds an operation callback which gets called every time the
>> library wants to call eventfd_write(). This eventfd_write() call could
>> result in
) now or have the newly introduced function,
rte_vhost_notify_guest(), called at a later time.
This can be used by 3rd party applications, like OVS, to avoid system
calls being called as part of the PMD threads.
Signed-off-by: Eelco Chaudron
---
lib/vhost/rte_vhost.h | 10 +-
lib/
On 30 Jan 2020, at 21:20, Thomas Monjalon wrote:
Yes, sorry, this is what I meant.
Given 19.11.0 already has the symbol as experimental,
and that applications like OVS had to accept it as experimental,
why removing experimental tag in 19.11.1?
I think it was mentioned that it was preferr
On 30 Jan 2020, at 17:04, Luca Boccassi wrote:
On Thu, 2020-01-30 at 16:55 +0100, Thomas Monjalon wrote:
30/01/2020 15:21, Luca Boccassi:
On Thu, 2020-01-30 at 15:17 +0100, Thomas Monjalon wrote:
30/01/2020 13:57, Luca Boccassi:
On Thu, 2020-01-30 at 13:33 +0100, Thomas Monjalon wrote:
H
s: 8b4b949144b8 ("vhost: fix dead lock on closing in server mode")
> Fixes: 5fbb3941da9f ("vhost: introduce driver features related APIs")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Maxime Coquelin
Acked-by: Eelco Chaudron
Thanks!
On 18 Dec 2019, at 3:57, Ye Xiaolong wrote:
On 12/18, Zhang, Xiao wrote:
-Original Message-
From: Eelco Chaudron [mailto:echau...@redhat.com]
Sent: Tuesday, November 19, 2019 9:45 PM
To: Xing, Beilei ; Zhang, Qi Z
Cc: Zhang, Xiao ; dev@dpdk.org
Subject: [PATCH v2] net
Trying again?
On 4 Dec 2019, at 16:18, Eelco Chaudron wrote:
Any update on this patch?
On 19 Nov 2019, at 14:45, Eelco Chaudron wrote:
During a kernel PF reset, this event is propagated to the VF.
The DPDK VF PMD will execute the reset task before the PF is done
with his. This results in
Moved RFC4115 APIs to none experimental as they have been there
since 19.02. Also, these APIs are the same as the none RFC4115 APIs.
Signed-off-by: Eelco Chaudron
---
lib/librte_meter/rte_meter.h |6 --
lib/librte_meter/rte_meter_version.map |4 ++--
2 files changed, 2
Any update on this patch?
On 19 Nov 2019, at 14:45, Eelco Chaudron wrote:
During a kernel PF reset, this event is propagated to the VF.
The DPDK VF PMD will execute the reset task before the PF is done
with his. This results in the admin queue message not being responded
to leaving the port
On 13 Nov 2019, at 2:14, Zhang, Xiao wrote:
-Original Message-
From: Eelco Chaudron [mailto:echau...@redhat.com]
Sent: Tuesday, November 12, 2019 7:09 PM
To: Zhang, Xiao
Cc: Zhang, Qi Z ; dev@dpdk.org; Xing, Beilei
Subject: Re: [dpdk-dev] [PATCH] net/i40e: force promiscuous state
configured independently
of the current admin state.
Signed-off-by: Eelco Chaudron
---
v1-v2:
In the earlier patch, we would force the vf->promisc_unicast_enabled
state to false after a reset. Based on the review comments it was
prefered to not take the current state into account whe
On 12 Nov 2019, at 1:52, Zhang, Xiao wrote:
Hi Eelco,
Seems you missed this mail.
Not sure why I missed this email, as it does not show up in my email
client :(
See below…
Hi Eelco,
I think you may need add more detailed message in the commit log
or comments.
My interpretation of
On 1 Nov 2019, at 9:12, Eelco Chaudron wrote:
+ /*
+* Even though the device reset is successful disabling
promiscuous
+* mode might not always succeed, causing enabling it after
reset
to
I think we need to root cause why fail to disable promiscuous
mode
and
try
On 7 Nov 2019, at 14:27, Ciara Loftus wrote:
Packets larger than this will fail to be transmitted by AF_XDP,
so limit the MTU to 1500.
Signed-off-by: Ciara Loftus
---
drivers/net/af_xdp/rte_eth_af_xdp.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/af_x
On 1 Nov 2019, at 3:38, Xing, Beilei wrote:
-Original Message-
From: Eelco Chaudron [mailto:echau...@redhat.com]
Sent: Tuesday, October 29, 2019 3:47 PM
To: Zhang, Xiao ; Xing, Beilei
Cc: Zhang, Qi Z ; dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] net/i40e: force promiscuous state
On 29 Oct 2019, at 8:39, Zhang, Xiao wrote:
-Original Message-
From: Eelco Chaudron
Sent: Friday, October 25, 2019 5:24 PM
To: Xing, Beilei ; Zhang, Xiao
Cc: Zhang, Qi Z ; dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] net/i40e: force promiscuous state
after VF
reset
On 17 Oct
On 17 Oct 2019, at 8:34, Xing, Beilei wrote:
On 17 Sep 2019, at 9:40, Eelco Chaudron wrote:
Even though the device reset is successful, disabling promiscuous
mode
might not always succeed, causing enabling it after reset to fail.
This would happen when the kernel driver requires a reset
Any update on this patch?
Thanks,
Eelco
On 17 Sep 2019, at 9:40, Eelco Chaudron wrote:
Even though the device reset is successful, disabling promiscuous mode
might not always succeed, causing enabling it after reset to
fail. This would happen when the kernel driver requires a reset of the
be enabled.
Signed-off-by: Eelco Chaudron
---
drivers/net/i40e/i40e_ethdev_vf.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/i40e/i40e_ethdev_vf.c
b/drivers/net/i40e/i40e_ethdev_vf.c
index 551f6fa..e0f99a4 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b
Forgot to include the stable alias to get this in 18.11, sorry Kevin
//Eelco
On 12 Sep 2019, at 14:40, Ye Xiaolong wrote:
On 09/12, David Marchand wrote:
On Thu, Sep 12, 2019 at 12:38 PM Eelco Chaudron
wrote:
When receiving the unsupported AQ messages, it's taken as an
error. It&
On 12 Sep 2019, at 14:40, Ye Xiaolong wrote:
On 09/12, David Marchand wrote:
On Thu, Sep 12, 2019 at 12:38 PM Eelco Chaudron
wrote:
When receiving the unsupported AQ messages, it's taken as an
error. It's not appropriate and triggers too much unnecessary print.
This commit is
When receiving the unsupported AQ messages, it's taken as an
error. It's not appropriate and triggers too much unnecessary print.
This commit is similar to commit e130425300b0 ("net/i40e: downgrade
unnecessary error log") which made the same change for the PF instance.
were called in the fast path.
Signed-off-by: Eelco Chaudron
---
lib/librte_vhost/rte_vhost.h | 10 +-
lib/librte_vhost/vhost.h | 15 ---
2 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/lib/librte_vhost/rte_vhost.h b/lib/librte_vhost/rte_vhost.h
index 7fb1729
Intel, any feedback on the below?
Thanks,
Eelco
On 24 Jun 2019, at 17:39, Eelco Chaudron wrote:
Hi,
I’m running into an issue where I have a VF used by OVS-DPDK and
from the kernel side change the MAC.
I used the following command to change the mac:
ip link set p5p2 vf 0 mac 52:54:00:92
Hi,
I’m running into an issue where I have a VF used by OVS-DPDK and from
the kernel side change the MAC.
I used the following command to change the mac:
ip link set p5p2 vf 0 mac 52:54:00:92:d3:30
In the kernel log I see the following:
[ 3420.075736] i40e :05:00.1: Bring down and up th
Looks good to me…
Acked-by: Eelco Chaudron
On 3 Jun 2019, at 10:31, David Marchand wrote:
> Copy/paste from i40e, let's align with the fix on i40e.
>
> Fixes: a37bde56314d ("net/ice: support statistics")
> Cc: sta...@dpdk.org
>
> Signed-off-by: David M
Looks good to me…
Acked-by: Eelco Chaudron
On 3 Jun 2019, at 10:31, David Marchand wrote:
i40e and i40evf currently use two different names for the statistic on
dropped packets on the rx and tx sides.
Let's prefer i40evf so that all statistics are suffixed with _packets.
This also avo
RFC 4115 allows a meter with either cir and/or eir configured.
When only one is configured a divide by zero would occur.
Fixes: 655796d2b5fb ("meter: support RFC4115 trTCM")
Cc: echau...@redhat.com
Signed-off-by: Eelco Chaudron
---
v3 - Rather than using a 0 check, set up profile
On 28 Feb 2019, at 19:50, Dumitrescu, Cristian wrote:
Hi Eelco,
Sorry for my delayed reply
No problem I was OOO also so hence my late reply ;)
-Original Message-
From: Eelco Chaudron [mailto:echau...@redhat.com]
Sent: Friday, February 1, 2019 4:07 PM
To: Dumitrescu, Cristian
Cc
RFC 4115 allows a meter with either cir and/or eir configured.
When only one is configured a divide by zero would occur.
Fixes: 655796d2b5fb ("meter: support RFC4115 trTCM")
Cc: echau...@redhat.com
Signed-off-by: Eelco Chaudron
---
v2 - Removed configuration change that got i
RFC 4115 allows a meter with either cir and/or eir configured.
When only one is configured a divide by zero would occur.
Fixes: 655796d2b5fb ("meter: support RFC4115 trTCM")
Cc: echau...@redhat.com
Signed-off-by: Eelco Chaudron
---
config/common_linuxapp |4 ++--
lib/li
it last time,
but shouldn’t you assign desired vlan tag to the VF first:
ip link set vf vlan
?
Konstantin
From: Eelco Chaudron [mailto:echau...@redhat.com]
Sent: Thursday, January 3, 2019 4:42 PM
To: Lu, Wenzhuo ; Ananyev, Konstantin
Cc: dev
Subject: Re: [dpdk-dev] VF of a X520 card does not
Hi Xueming,
I was wondering if this patch went anywhere, could not find anything in
the list archive?
I like the idea, as it’s useful for quick unit testing, without
relying on Trex or trafgen.
Cheers,
Eelco
quick guide document:
https://github.com/steevenlee/dpdk/blob/master_scapy/doc/
Thanks Thomas!
On 10 Jan 2019, at 0:22, Thomas Monjalon wrote:
> 07/01/2019 16:58, Dumitrescu, Cristian:
>> From: Eelco Chaudron [mailto:echau...@redhat.com]
>>>
>>> This patch adds support for RFC4115 trTCM meters.
>>>
>>>
>>> Signed
On 4 Jan 2019, at 20:42, Stephen Hemminger wrote:
On Fri, 4 Jan 2019 13:59:42 +
Eelco Chaudron wrote:
This patch adds support for RFC4115 trTCM meters.
Signed-off-by: Eelco Chaudron
Fix comment formatting.
Hi Stephen, I left these warnings in on purpose, to match the existing
On 21 Dec 2018, at 17:15, Dumitrescu, Cristian wrote:
Hi Eelco,
+/** trTCM parameters per metered traffic flow. The CIR, EIT, CBS and
EBS
Small typo here: EIT to be replaced by EIR.
+parameters only count bytes of IP packets and do not include link
specific
+headers. The CBS and EBS
Add test cases for RFC4115 meters
Signed-off-by: Eelco Chaudron
---
test/test/test_meter.c | 212
1 file changed, 212 insertions(+)
diff --git a/test/test/test_meter.c b/test/test/test_meter.c
index 8bb47e75c..f935faa53 100644
--- a/test/test
This patch adds support for RFC4115 trTCM meters.
Signed-off-by: Eelco Chaudron
v4:
- Fixed typo
- Cleaned up code to be aligned with RFC diagram
v3:
- Gave the rfc4115 meter it's own data structures
v2:
- Marked all functions with __rte_experimental, and added
"EXPERIMENT
This patch adds support for RFC4115 trTCM meters.
Signed-off-by: Eelco Chaudron
---
lib/librte_meter/rte_meter.c | 42 ++
lib/librte_meter/rte_meter.h | 233
lib/librte_meter/rte_meter_version.map |9 +
3 files changed, 282
Hi maintainers, any feedback on the below?
Thanks,
Eelco
On 18 Dec 2018, at 12:06, Eelco Chaudron wrote:
Hi,
I’m assigning a VF of an X520 card for DPDK/testpmd/OVS but it's not
accepting tagged VLAN packets (it does accept tag 0). Is this a known
bug/limitation of the 82599ES ch
Add test cases for RFC4115 meters
Signed-off-by: Eelco Chaudron
---
test/test/test_meter.c | 212
1 file changed, 212 insertions(+)
diff --git a/test/test/test_meter.c b/test/test/test_meter.c
index 8bb47e75c..f935faa53 100644
--- a/test/test
This patch adds support for RFC4115 trTCM meters.
Signed-off-by: Eelco Chaudron
---
lib/librte_meter/rte_meter.c | 42 ++
lib/librte_meter/rte_meter.h | 235
lib/librte_meter/rte_meter_version.map |9 +
3 files changed, 284
This patch adds support for RFC4115 trTCM meters.
Signed-off-by: Eelco Chaudron
v3:
- Gave the rfc4115 meter it's own data structures
v2:
- Marked all functions with __rte_experimental, and added
"EXPERIMENTAL:..." to doxygen comments.
- Removed library version change
Hi,
I’m assigning a VF of an X520 card for DPDK/testpmd/OVS but it's not
accepting tagged VLAN packets (it does accept tag 0). Is this a known
bug/limitation of the 82599ES chipset?
This is how I've tested it:
$ echo 1 > /sys/bus/pci/devices/\:05\:00.0/sriov_numvfs
$driverctl -v set-ove
On 17 Dec 2018, at 12:23, Dumitrescu, Cristian wrote:
Hi Eelco,
-Original Message-
From: Eelco Chaudron [mailto:echau...@redhat.com]
Sent: Thursday, November 29, 2018 11:29 AM
To: Dumitrescu, Cristian
Cc: dev@dpdk.org
Subject: [PATCH v2 1/2] lib/librte_meter: add RFC4115 trTCM
This patch adds support for RFC4115 trTCM meters.
Signed-off-by: Eelco Chaudron
---
lib/librte_meter/rte_meter.c | 40 +
lib/librte_meter/rte_meter.h | 236 ++--
lib/librte_meter/rte_meter_version.map |9 +
3 files changed, 269
Add test cases for RFC4115 meters
Signed-off-by: Eelco Chaudron
---
test/test/test_meter.c | 212
1 file changed, 212 insertions(+)
diff --git a/test/test/test_meter.c b/test/test/test_meter.c
index 8bb47e75c..097da0143 100644
--- a/test/test
This patch adds support for RFC4115 trTCM meters.
Signed-off-by: Eelco Chaudron
v2:
- Marked all functions with __rte_experimental, and added
"EXPERIMENTAL:..." to doxygen comments.
- Removed library version change, and merged it with first patch
- D
On 28 Nov 2018, at 13:51, Thomas Monjalon wrote:
> 28/11/2018 13:40, Eelco Chaudron:
>>
>> On 28 Nov 2018, at 11:09, Thomas Monjalon wrote:
>>
>>> 28/11/2018 10:27, Eelco Chaudron:
>>>> On 28 Nov 2018, at 9:38, David Marchand wrote:
>>&g
On 28 Nov 2018, at 11:09, Thomas Monjalon wrote:
28/11/2018 10:27, Eelco Chaudron:
On 28 Nov 2018, at 9:38, David Marchand wrote:
On Tue, Nov 27, 2018 at 4:22 PM Eelco Chaudron
wrote:
--- a/lib/librte_meter/Makefile
+++ b/lib/librte_meter/Makefile
-LIBABIVER := 2
+LIBABIVER := 3
As far
On 28 Nov 2018, at 9:38, David Marchand wrote:
Hello Eelco,
On Tue, Nov 27, 2018 at 4:22 PM Eelco Chaudron
wrote:
Update the ABI to include the new RFC4115 meter functions
---
lib/librte_meter/Makefile |2 +-
lib/librte_meter/meson.build |2 +-
lib
Update the ABI to include the new RFC4115 meter functions
---
lib/librte_meter/Makefile |2 +-
lib/librte_meter/meson.build |2 +-
lib/librte_meter/rte_meter_version.map |9 +
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/lib/librte_mete
This patch adds support for RFC4115 trTCM meters.
Signed-off-by: Eelco Chaudron
---
lib/librte_meter/rte_meter.c | 40 +
lib/librte_meter/rte_meter.h | 193 +++---
2 files changed, 217 insertions(+), 16 deletions(-)
diff --git a/lib/librte_meter
This patch adds support for RFC4115 trTCM meters.
Signed-off-by: Eelco Chaudron
Eelco Chaudron (3):
lib/librte_meter: add RFC4115 trTCM meter support
test/test_meter: update meter test to include RFC4115 meters
lib/librte_meter: update abi to include new rfc4115 function
Add test cases for RFC4115 meters
Signed-off-by: Eelco Chaudron
---
test/test/test_meter.c | 212
1 file changed, 212 insertions(+)
diff --git a/test/test/test_meter.c b/test/test/test_meter.c
index 8bb47e75c..097da0143 100644
--- a/test/test
On 12 Nov 2018, at 12:26, Eelco Chaudron wrote:
On 12 Nov 2018, at 12:18, Alejandro Lucero wrote:
When using large amount of hugepage based memory, doing all the
hugepages mapping can take quite significant time.
The problem is hugepages being initially mmaped to virtual addresses
which
will not collide with the final mmaping.
Fixes: 293c0c4b957f ("mem: use address hint for mapping hugepages")
Signed-off-by: Alejandro Lucero
Thanks Alejandro for sending the patch. This issue was found in an
OVS-DPDK environment.
I verified/tested the patch.
Acked-by: Eelco Chaudr
On 6 Nov 2018, at 11:53, Dumitrescu, Cristian wrote:
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Eelco Chaudron
Sent: Tuesday, November 6, 2018 10:32 AM
To: dev@dpdk.org
Subject: [dpdk-dev] RFC 4115 variant for
rte_meter_trtcm_color_blind/aware_check()
Hi
Hi All,
Was wondering if anyone is planning to add an RFC 4115 equivalent of the
rte_meter_trtcm_color_blind/aware_check() check APIs?
If not I can go ahead and sent a patch to add it, i.e. something like
rte_meter_trtcm_rfc4115_color_blind/aware_check().
Cheers,
Eelco
On 10 Jul 2018, at 19:25, Alejandro Lucero wrote:
Although VT-d emulation currently only supports 39 bits, it could
be iovas being within that supported range. This patch allows
IOVA mode in such a case.
Indeed, memory initialization code can be modified for using lower
virtual addresses tha
ions, returning an error if this function
> returns memsegs out of range.
>
> Another potential usage is for emulated IOMMU hardware with addressing
> limitations.
>
> Applicable to v17.11.3 only.
>
> Signed-off-by: Alejandro Lucero
> Acked-by: Anatoly Burakov
> ---
Looks good to me.
Acked-by: Eelco Chaudron
On 10 Jul 2018, at 13:43, Alejandro Lucero wrote:
On Tue, Jul 10, 2018 at 12:33 PM, Burakov, Anatoly <
anatoly.bura...@intel.com> wrote:
On 10-Jul-18 12:14 PM, Eelco Chaudron wrote:
On 10 Jul 2018, at 12:52, Alejandro Lucero wrote:
On Tue, Jul 10, 2018 at 11:06 AM, Eelco Ch
ood to me!
Cheers,
Eelco
Acked-by: Eelco Chaudron
On 10 Jul 2018, at 12:52, Alejandro Lucero wrote:
On Tue, Jul 10, 2018 at 11:06 AM, Eelco Chaudron
wrote:
On 10 Jul 2018, at 11:34, Alejandro Lucero wrote:
On Tue, Jul 10, 2018 at 9:56 AM, Eelco Chaudron
wrote:
On 4 Jul 2018, at 14:53, Alejandro Lucero wrote:
A device can suffer
On 4 Jul 2018, at 14:53, Alejandro Lucero wrote:
> NFP can handle IOVA as VA. It requires to check those IOVAs
> being in the supported range what is done during initialization.
>
> Signed-off-by: Alejandro Lucero
Changes look good to me!
Acked-by: Eelco Chaudron
anges look good to me!
Acked-by: Eelco Chaudron
On 4 Jul 2018, at 14:53, Alejandro Lucero wrote:
Although VT-d emulation currently only supports 39 bits, it could
be iovas being within that supported range. This patch allows
IOVA mode in such a case.
Indeed, memory initialization code can be modified for using lower
virtual addresses than
On 10 Jul 2018, at 11:34, Alejandro Lucero wrote:
On Tue, Jul 10, 2018 at 9:56 AM, Eelco Chaudron
wrote:
On 4 Jul 2018, at 14:53, Alejandro Lucero wrote:
A device can suffer addressing limitations. This functions checks
memsegs have iovas within the supported range based on dma mask
On 4 Jul 2018, at 14:53, Alejandro Lucero wrote:
A PMD should invoke this function for checking memsegs iovas are
within
the supported range by the device.
Signed-off-by: Alejandro Lucero
Agree with Andrew here, why not call rte_eal_check_dma_mask() directly
in nfp_net_txq_full()?
--
On 4 Jul 2018, at 14:53, Alejandro Lucero wrote:
A device can suffer addressing limitations. This functions checks
memsegs have iovas within the supported range based on dma mask.
PMD should use this during initialization if supported devices
suffer addressing limitations, returning an error
1 - 100 of 119 matches
Mail list logo