Le 21-10-21 à 12:41, Xueming Li a écrit :
In current DPDK framework, all Rx queues is pre-loaded with mbufs for
incoming packets. When number of representors scale out in a switch
domain, the memory consumption became significant. Further more,
polling all ports leads to high cache miss, high lat
Le 31-03-21 à 02:44, Honnappa Nagarahalli a écrit :
- Ability to tune the values of #defines
* Few prominent points discussed
- This will result in #ifdefs in the code (for ex: in testpmd)
- One option is for all the PMDs to document their configurable
#defines in PMD
Le 07-03-21 à 11:02, Viacheslav Ovsiienko a écrit :
There are two different timestamp formats can be provided potentially
by mlx5 supported hardware.
The free-running format provides some opaque values captured from
internal clock counter clocked by some independent oscillator.
The free-running
Le 16/01/2021 à 21:01, Liron Himi a écrit :
Hi,
Sorry for rearising this issue again, please check my comments inline
Liron Himi
-Original Message-
From: Stephen Hemminger
Sent: Wednesday, 6 May 2020 23:24
To: Liron Himi
Cc: dpdk-dev
Subject: Re: [EXT] Re: [dpdk-dev] input port in m
Hi all,
In an ageing scenario, is there a faster way than calling
rte_hash_del_key() to delete an entry when we have the position (the
result of rte_hash_lookup()) on hand?
Particularly, with and without CONCURRENCY_LF set.
For instance, is it correct to call rte_hash_free_key_with_position(
Could you provide a cover letter?
Thanks,
Tom
Le 03/09/2020 à 12:13, Michael Baum a écrit :
v1:
Initial version
Michael Baum (18):
net/mlx5: fix Rx hash queue creation error flow
net/mlx5: fix Rx queue state update
net/mlx5: fix types differentiation in Rxq create
net/mlx5: mitiga
Nice patch!
However I would use a multiply and shift approach instead of a division
in the fast path. When we did that it was really hurting the performance.
Cheers,
Tom
Le 24/07/2020 à 22:23, Patrick Keroulas a écrit :
From: Vivien Didelot
When hardware timestamping is enabled on Rx path
Le 22/05/2020 à 20:43, PATRICK KEROULAS a écrit :
mlx5 part of libibverbs includes a ts-to-ns converter which takes the
instantaneous clock info. It's unused in dpdk so far. I've tested it in the
device/port init routine and the result looks reliable. Since this approach
looks very simple, comp
Le 25/05/2020 à 22:34, Thomas Monjalon a écrit :
25/05/2020 20:44, Morten Brørup:
From: Thomas Monjalon
25/05/2020 18:09, Burakov, Anatoly:
obviously, but i have a suspicion that we'll get more of it if we
lower
the barrier for entry (not the barrier for merge!). I think there is
a
way to
Hi all,
I could not check all discussions regarding the graph subsystem, but I
could not find a trivia behind the idea of re-creating yet another graph
processing system like VPP, BESS, Click/FastClick and a few others that
all support DPDK already and comes with up to thousands of "nodes"
al
Le 30/04/2020 à 09:36, Matan Azrad a écrit :
Hi Tom
From: Tom Barbette
Great news!
- I can understand why there is no timeout unit. But that's calling for user
nightmare. Eg I could only get from the code (and not from documentation
yet? ) of the following mlx5 driver patch that the
Great news!
- I can understand why there is no timeout unit. But that's calling for
user nightmare. Eg I could only get from the code (and not from
documentation yet? ) of the following mlx5 driver patch that the value
should be in tenth of seconds. If I build an application that is
supposed
Le 27/03/2020 à 16:06, Thomas Monjalon a écrit :
27/03/2020 15:24, Tom Barbette:
Le 27/03/2020 à 14:55, Thomas Monjalon a écrit :
27/03/2020 13:35, Tom Barbette:
Le 27/03/2020 à 11:35, Thomas Monjalon a écrit :
27/03/2020 10:14, Tom Barbette:
CC'ing original participants as I don&
Le 27/03/2020 à 15:44, Andrew Rybchenko a écrit :
On 3/27/20 5:29 PM, Tom Barbette wrote:
Hi all,
It seems rte_flow_item_eth takes its ethertype in host byte order with
i40e, but in network byte order with mlx5.
If so, it is definitely bug in i40e, since struct rte_flow_item_eth
defines type
Hi all,
It seems rte_flow_item_eth takes its ethertype in host byte order with
i40e, but in network byte order with mlx5.
Wouldn't it be nice to unify that? Else is there a way to know in which
byte order the spec should be given? I guess that expands to all fields,
but I only compared the e
Le 27/03/2020 à 14:55, Thomas Monjalon a écrit :
27/03/2020 13:35, Tom Barbette:
Le 27/03/2020 à 11:35, Thomas Monjalon a écrit :
27/03/2020 10:14, Tom Barbette:
CC'ing original participants as I don't see a way out of this.
Le 12/03/2020 à 13:04, Tom Barbette a écrit :
Hi al
Le 27/03/2020 à 11:35, Thomas Monjalon a écrit :
27/03/2020 10:14, Tom Barbette:
CC'ing original participants as I don't see a way out of this.
Le 12/03/2020 à 13:04, Tom Barbette a écrit :
Hi all,
If the user follows the quick guide
(http://core.dpdk.org/doc/quick-start/) DP
CC'ing original participants as I don't see a way out of this.
Le 12/03/2020 à 13:04, Tom Barbette a écrit :
Hi all,
If the user follows the quick guide
(http://core.dpdk.org/doc/quick-start/) DPDK will be compiled in the
"build" folder.
However, external applications
Hi all,
If the user follows the quick guide
(http://core.dpdk.org/doc/quick-start/) DPDK will be compiled in the
"build" folder.
However, external applications will always fail to build because
RTE_SDK_BIN is strictly defined as $RTE_SDK/$RTE_TARGET, and
mk/internal/rte.extvars.mk needs to
It depends on the datastructure.
If you use rte_hash, with the thread safety flags, it's safe.
In any case having a lot of cores accessing the same DS will lead to bad
performance. You should try to have per-core data structures whenever possible.
Tom
D
maybe?
Thanks,
Tom
Le 30/11/2019 à 12:19, Tom Barbette a écrit :
Hi all,
I'm struggling to use the group feature with MLX5.
I'm using 19.08.2 for now (while
https://bugs.dpdk.org/show_bug.cgi?id=371 gets fixed).
I use the latest OFED (no inbox driver this time).
I have dv_flow_e
Hi all,
I'm struggling to use the group feature with MLX5.
I'm using 19.08.2 for now (while
https://bugs.dpdk.org/show_bug.cgi?id=371 gets fixed).
I use the latest OFED (no inbox driver this time).
I have dv_flow_en=1, but I still get "cannot create jump action.:
Operation not supported". w
Hi Gokul,
As Setphen said, only Mellanox sets the hardware timestamp.
If you have a Mellanox card, you can actually follow the example given
in the rxtx_callback sample application that precisely gives the number
of CPU cycles a packet spent into the queue.
Tom
Le 22/11/2019 à 18:00, Gokul
My two cents as a regular user of the flow and mark feature: (A) seems much
better and natural.
In packet processing platform such as FastClick, I don't have a real
understanding of the rules of the user, and rules can be added by the user
while the application is running via a socket or web in
ore contention.
I'm trying to reproduce with the smallest possible modification of testpmd so
other people might experience this.
Thanks,
Tom
De : David Christensen
Envoyé : vendredi 25 octobre 2019 19:35
À : Tom Bar
Hi all,
We're experiencing a very strange problem. The code of our application
is modified to always use 8 cores. However, when running with "-l
0-MAXCPU", with MAXCPU varying between 7 and 15 (therefore "allocating"
more *unused* cores), the performance of the application change. It can
be m
Regarding rxtx_callbacks, it's the only one featuring the use of
hardware timestamping. I would delay its removal until the feature is
more known and mature.
Tom
On 2019-07-18 11:33, Bruce Richardson wrote:
A standard item on the agenda of the DPDK technical board meetings has been
the number
I think the silent breaking is still not solved for
DEV_RX_OFFLOAD_RSS_HASH and DEV_RX_OFFLOAD_FLOW_MARK.
An old application will still compile without any problem, but the RSS
hash will not be written and the app will break... They should be
negative. Eg DEV_RX_OFFLOAD_NO_RSS_HASH and DEV_RX_
the test library or your own application.
Workaround:
Update to OFED 4.6, or do not use STATIC linking
We could have disabled STATIC if the OFED is 4.5, I guess it's too late
now... Sorry about that timing...
Tom
On 2019-03-20 18:13, Tom Barbette wrote:
I completely removed with apt r
Hi all,
I still find it a little bit unclear about direct rules. And therefore, how to
enable this large sclale mode.
It is only available for eswitch ? Therefore PF rules will still be slow ? How
can I be sure to be in direct mode ?
At some point someone mentioned performance of using a seco
is userlevel, calling
get_timeofday for millions of packets pretty much kills the capture.
Here we do a simple math per packet to convert the packet's timestamp in
ticks to the real clock time, (very) much cheaper than even a vDSO syscall.
Tom
On 2019-05-02 14:11, Tom Barbette wrote:
Some
or an example.
Signed-off-by: Tom Barbette
Acked-by: Shahaf Shuler
---
drivers/net/mlx5/mlx5.c| 1 +
drivers/net/mlx5/mlx5.h| 1 +
drivers/net/mlx5/mlx5_ethdev.c | 30 ++
drivers/net/mlx5/mlx5_glue.c | 8
drivers/net/mlx5/mlx5_glue.h | 2
read_clock gives an
amount in ticks, and that it has no unit.
Tom Barbette (3):
rte_ethdev: Add API function to read dev clock
mlx5: Implement support for read_clock
rxtx_callbacks: Add support for HW timestamp
doc/guides/nics/features.rst| 1 +
doc/guides/sample_app_u
timestamp field
to real time without the complexity of the rte_timesync* facility. One can
derivate the clock frequency by calling twice read_clock and then keep a
common time base.
Signed-off-by: Tom Barbette
---
doc/guides/nics/features.rst | 1 +
lib/librte_ethdev/rte_ethdev.c
stack.
Signed-off-by: Tom Barbette
---
doc/guides/sample_app_ug/rxtx_callbacks.rst | 9 ++-
examples/rxtx_callbacks/Makefile| 3 +
examples/rxtx_callbacks/main.c | 87 -
examples/rxtx_callbacks/meson.build | 3 +
4 files changed, 97 insertions
@Andrew I applied your comments. Thanks.
On 2019-04-25 20:28, Wiles, Keith wrote:
What is a raw clock value? It took me a bit to find that it is in nano-seconds
need to document that point.
It is not in nanosecond, it has no units. Finding the relation between
the device clock and the real t
timestamp field
to real time without the complexity of the rte_timesync* facility. One can
derivate the clock frequency by calling twice read_clock and then keep a
common time base.
Signed-off-by: Tom Barbette
---
doc/guides/nics/features.rst | 1 +
lib/librte_ethdev/rte_ethdev.c
stack.
Signed-off-by: Tom Barbette
---
doc/guides/sample_app_ug/rxtx_callbacks.rst | 9 ++-
examples/rxtx_callbacks/Makefile| 3 +
examples/rxtx_callbacks/main.c | 87 -
examples/rxtx_callbacks/meson.build | 3 +
4 files changed, 97 insertions
or an example.
Signed-off-by: Tom Barbette
Acked-by: Shahaf Shuler
---
drivers/net/mlx5/mlx5.c| 1 +
drivers/net/mlx5/mlx5.h| 1 +
drivers/net/mlx5/mlx5_ethdev.c | 30 ++
drivers/net/mlx5/mlx5_glue.c | 8
drivers/net/mlx5/mlx5_glue.h | 2
uld use it blindly.
Change in v2:
- Rebase on current master
Change in v3:
- Address comments from Ferruh Yigit
Tom Barbette (3):
rte_ethdev: Add API function to read dev clock
mlx5: Implement support for read_clock
rxtx_callbacks: Add support for HW timestamp
doc/guides/nics/fe
Clarify the fact that mask bits should be set in rte_eth_reta_query.
v2:
- Change documentation string as suggested by Ferruh
Signed-off-by: Tom Barbette
---
lib/librte_ethdev/rte_ethdev.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/librte_ethdev/rte_ethdev.h b
As the librte function checks that bits of up to reta_size in reta_conf
are set, the arg passed must have the mask set to 1. I spent quite some
time before finding the issue here, so I thought updating the doc may
help other people.
The problem raise when the size of the table is not on a (byte?)
Le 02/04/2019 à 20:22, Ferruh Yigit a écrit :
Same comment as ethdev one, above code assume if driver announces
'DEV_RX_OFFLOAD_TIMESTAMP' capability, it have to implement 'read_clock'
dev_ops, should it be the case?
Write now only mlx implements it so this is not a problem at all, but I don't
k
Le 02/04/2019 à 19:46, Ferruh Yigit a écrit :
+* **[implements] eth_dev_ops**: ``read_clock``.
This means for a PMD to claim 'timestamp' support, it should implement the
'read_clock' dev_ops, is it really the case?
Should we say 'related' instead of 'implements' ?
Ok for me. I guess this wil
Le 02/04/2019 à 20:26, Ferruh Yigit a écrit :
error: no member named 'ctx' in 'struct mlx5_priv'
Yes indeed, master changed since my last rebase. This is fixed in v3
(I'll address other comments in related patches before sending v3).
I already addressed Shahaf's comments for this patch in
On 2019-03-27 15:54, Wiles, Keith wrote:
I know the API rte_eht_read_clock() is attempting to read the NIC for this
timestamp, but if the PMD does not support this request can we just default to
the rte_rdtsc() as a return value?
I would not advise that, because the goal of the function is to h
Signed-off-by: Tom Barbette
---
drivers/net/mlx5/mlx5.c| 1 +
drivers/net/mlx5/mlx5.h| 1 +
drivers/net/mlx5/mlx5_ethdev.c | 29 +
drivers/net/mlx5/mlx5_glue.c | 8
drivers/net/mlx5/mlx5_glue.h | 2 ++
5 files changed, 41 insertions
stack.
Signed-off-by: Tom Barbette
---
doc/guides/sample_app_ug/rxtx_callbacks.rst | 9 ++-
examples/rxtx_callbacks/Makefile| 2 +
examples/rxtx_callbacks/main.c | 86 -
examples/rxtx_callbacks/meson.build | 1 +
4 files changed, 93 insertions
timestamp field
to real time without the complexity of the rte_timesync* facility. One can
derivate the clock frequency by calling twice read_clock and then keep a
common time base.
Signed-off-by: Tom Barbette
---
doc/guides/nics/features.rst | 1 +
lib/librte_ethdev/rte_ethdev.c
way. More importantly, the returned
value is not a timeval, but an amount of ticks. We could have a cast-based
solution, but on top of being an ugly solution, some people seeing the timeval
type of rte_eth_timesync_read_time could use it blindly.
Change in v2:
- Rebase on current master
Tom B
n with --force.
Let me know if that works.
Regards,
Ali
-Original Message-
From: Tom Barbette
Sent: Tuesday, March 19, 2019 11:34 AM
To: Ali Alnubani
Cc: dev@dpdk.org; Erez Scop ; Olga Shern
; Yongseok Koh ; Shahaf
Shuler ; john.mcnam...@intel.com;
marko.kovace...@intel.com
Subject: Re:
Message-
From: dev On Behalf Of Tom Barbette
Sent: Thursday, March 14, 2019 1:20 PM
To: Shahaf Shuler ; john.mcnam...@intel.com;
marko.kovace...@intel.com
Cc: dev@dpdk.org; Erez Scop ; Olga Shern
; Yongseok Koh
Subject: Re: [dpdk-dev] [PATCH 2/2] doc: update Mellanox supported OFED
version
A
A bit of an old thread, but I just tried to update the OFED 4.5 as this
doc patch suggests and DPDK (19.02 or master) do not compile anymore for
mlx5?
Was the doc updated too soon or should I do something special to clean
4.4 and update 4.5?
I did install the OFED with --upsteam-libs and --d
t;. Would it be possible to ignore the message and overwrite?
Tom
On 2019-02-14 14:15, Shahaf Shuler wrote:
Hi Tom,
Thursday, February 14, 2019 1:31 PM, Tom Barbette:
Subject: rte_flow update support?
Hi all,
Are there plans to add support for modifying rules using the rte_flow API ?
Th
Hi all,
Are there plans to add support for modifying rules using the rte_flow API ?
The first problem with destroy+create is atomicity. During the process
some packets will get lost.
Then the second problem is performance. We measured Mellanox CX5 (mlx5
driver) to be able to "update" at best
On 2019-01-31 10:11, Bruce Richardson wrote:
What header is that? From what I see the patchset only makes changes to .c
files rather than any .h files, so not sure it would help in your case.
Yes you're right. There are other occurrences of register indeed.
I got the warning from rte_common.h:
Hi all,
Has there been any change regarding this? I'm still at DPDK 18.11. Maybe
automatically add -Wno-register when C++17 is enabled? Or have a some
register macro which gets undefined if C++17 is enabled?
The "warning: ISO C++1z does not allow ‘register’ storage class
specifier" is annoyi
15:31, Tom Barbette wrote:
?CC-ing maintainers.
De : Georgios Katsikas
Envoyé : mardi 4 décembre 2018 11:41
À : dev@dpdk.org
Cc : Tom Barbette
Objet : Flow Director vs. 5-tuple filters on a 10GbE Intel 82599 ES NIC
Dear all,
I am performing rule installatio
Ferruh Yigit wrote:
> Why timestamp offloading become useless? When timestamp offloading enabled,
> device fills 'mbuf.timestamp' and you can use it.
But the frequency is unknown, and the reference time neither. So it can be used
only to know that "some time passed" between packets.
> For your ca
Ferruh Yigit wrote :
> Is this a common enough feature to include into ethdev abstraction layer? Or a
> feature for a single vendor?
I found reference to mbuf’s timestamp field only in MLX5. I think it is the
only one to support timestamp offloading. This new API is only useful to make
sense out
stack.
Signed-off-by: Tom Barbette
---
doc/guides/sample_app_ug/rxtx_callbacks.rst | 9 ++-
examples/rxtx_callbacks/Makefile| 2 +
examples/rxtx_callbacks/main.c | 86 -
examples/rxtx_callbacks/meson.build | 1 +
4 files changed, 93 insertions
Signed-off-by: Tom Barbette
---
drivers/net/mlx5/Makefile | 2 +-
drivers/net/mlx5/meson.build | 2 +-
drivers/net/mlx5/mlx5.c| 1 +
drivers/net/mlx5/mlx5.h| 1 +
drivers/net/mlx5/mlx5_ethdev.c | 30 ++
drivers/net/mlx5/mlx5_glue.c | 8
timestamp field
to real time without the complexity of the rte_timesync* facility. One can
derivate the clock frequency by calling twice read_clock and then keep a
common time base.
Signed-off-by: Tom Barbette
---
doc/guides/nics/features.rst | 1 +
lib/librte_ethdev/rte_ethdev.c
way. More importantly, the returned
value is not a timeval, but an amount of ticks. We could have a cast-based
solution, but on top of being an ugly solution, some people seeing the timeval
type of rte_eth_timesync_read_time could use it blindly.
Tom Barbette (3):
rte_ethdev: Add API function t
?CC-ing maintainers.
De : Georgios Katsikas
Envoyé : mardi 4 décembre 2018 11:41
À : dev@dpdk.org
Cc : Tom Barbette
Objet : Flow Director vs. 5-tuple filters on a 10GbE Intel 82599 ES NIC
Dear all,
I am performing rule installation/deletion benchmarks on a
d be afraid some people seeing the timeval type of
rte_eth_timesync_read_time would use it blindly.
But as far as I'm concerned, I can go with one or the other in our use cases...
Thanks,
Tom
De : z...@semihalf.com
Envoyé : mercredi 5 décemb
Ferruh Yigit wrote:
> According my understanding,
> Only *one* DPDK application (primary or secondary) should control a device.
> There is no restriction in DPDK for it, this responsibility is pushed to
> application, application should manage it.
...
> Device initialization (probe()) done only b
without the complexity of the rte_timesync* facility. One can
derivate the clock frequency by calling twice read_clock and then keep a
common time base.
Signed-off-by: Tom Barbette
---
doc/guides/nics/features.rst | 1 +
lib/librte_ethdev/rte_ethdev.c | 13 +
lib
complements the one
in rxtx_callback.
Tom Barbette (3):
rte_ethdev: Add API function to read dev clock
mlx5: Implement support for read_clock
rxtx_callbacks: Add support for HW timestamp
doc/guides/nics/features.rst | 1 +
drivers/net/mlx5/mlx5.c | 1 +
dri
stack.
Signed-off-by: Tom Barbette
---
examples/rxtx_callbacks/Makefile| 2 +
examples/rxtx_callbacks/main.c | 87 +++--
examples/rxtx_callbacks/meson.build | 1 +
3 files changed, 86 insertions(+), 4 deletions(-)
diff --git a/examples/rxtx_callbacks/Makefile b
Signed-off-by: Tom Barbette
---
drivers/net/mlx5/mlx5.c| 1 +
drivers/net/mlx5/mlx5.h| 1 +
drivers/net/mlx5/mlx5_ethdev.c | 31 +++
drivers/net/mlx5/mlx5_glue.c | 8
drivers/net/mlx5/mlx5_glue.h | 2 ++
5 files changed, 43 insertions
> Tom - please have a second look and confirm.
Looks good. I tried next-net-mlx and it works fine. My imissed increases as
expected, rx_discards_phy also (sadly).
Thanks,
Tom
Shuler as per
v1 comments
Signed-off-by: Tom Barbette
---
doc/guides/nics/mlx5.rst| 2 +-
drivers/net/mlx5/mlx5.h | 8 ++-
drivers/net/mlx5/mlx5_stats.c | 53 -
drivers/net/mlx5/mlx5_trigger.c | 2 +-
4 files changed, 46 inserti
discards_phy no matter what in xstats as it is needed for the full
picture. Then the documentation can mention that.
Tom
De : Shahaf Shuler
Envoyé : mercredi 14 novembre 2018 16:17
À : Tom Barbette; dev@dpdk.org
Cc : Yongseok Koh
Objet : RE: [PATCH] mlx5:
not, this should be considered a
bug. Eg, user looking at imissed will think the packets are lost before
reaching the device.
As for xstats, I added a base counter to be able to "reset" imissed.
Signed-off-by: Tom Barbette
---
drivers/net/mlx5/mlx5.h | 2 ++
drivers/net/ml
> For others, if the driver has no places it allocates mbufs or drops packets
> in the driver I see no
> reason that the driver needs to do anything with those fields.
I understand. I'll fix the driver I use then. There may still be some counters
that should increase but are not reported by hard
> The other option would be to push for implementing all basic stats
> in all drivers, and consider an unimplemented stat as a bug.
It may be impossible in some cases. I think imissed is not even reported by
hardware for mlx5 cards. Only an aggregate for all queues.
I'll add a "uint64_t stats_ca
Hi ethdev maintainers,
Support of drivers for the fields in rte_eth_stats is a bit random, and never
mentioned in the doc. A quick survey showed me :
ipackets : implemented by all drivers
ibytes : all except null, ring
ierror : all except af_packet, ark, avf, axgbe, fm10k, kni, null, pcap, rin
> It will tell you if in a given offset on the rxq you have a packet ready. I
> think it will fit your needs, see below.
So we just loose in precision here. We're looking at ML techniques that will
play better with a numerical value and benefit from more entropy than
arbitrarily poking of some
:37
À : Tom Barbette; dev@dpdk.org; Ferruh Yigit; Thomas Monjalon; Andrew
Rybchenko; olivier.m...@6wind.com
Cc : Yongseok Koh
Objet : RE: [PATCH v4] mlx5: Support for rte_eth_rx_queue_count
Hi Tom,
Adding ethdev maintainers and Oliver as the author of the new API.
Saturday, October 27, 2018 6:
that...
Tom
De : Tom Barbette
Envoyé : samedi 27 octobre 2018 17:10
À : dev@dpdk.org
Cc : shah...@mellanox.com; ys...@mellanox.com; Tom Barbette
Objet : [PATCH v4] mlx5: Support for rte_eth_rx_queue_count
This patch adds support for the rx_queue_count API
disappeared in v3
Signed-off-by: Tom Barbette
---
drivers/net/mlx5/mlx5.c | 1 +
drivers/net/mlx5/mlx5_rxtx.c | 78 ++--
drivers/net/mlx5/mlx5_rxtx.h | 1 +
3 files changed, 70 insertions(+), 10 deletions(-)
diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net
This patch adds support for the rx_queue_count API in mlx5 driver
Changes in v2:
* Fixed styling issues
* Fix missing return
Changes in v3:
* Fix styling comments and checks as per Yongseok Koh
comments. Thanks !
Signed-off-by: Tom Barbette
---
drivers/net/mlx5/mlx5.c | 1
This patch adds support for the rx_queue_count API in mlx5 driver
Changes in v2:
* Fixed styling issues
* Fix missing return
Signed-off-by: Tom Barbette
---
drivers/net/mlx5/mlx5.c | 1 +
drivers/net/mlx5/mlx5_rxtx.c | 60 +---
drivers/net/mlx5
This patch adds support for the rx_queue_count API in mlx5 driver
Signed-off-by: Tom Barbette
---
drivers/net/mlx5/mlx5.c | 1 +
drivers/net/mlx5/mlx5_rxtx.c | 62 +---
drivers/net/mlx5/mlx5_rxtx.h | 1 +
3 files changed, 54 insertions(+), 10
mputation instead of a real
synchronization? But now timestamp is in the rte_mbuf, so it could also
technically go in.
Tom
De : Shahaf Shuler
Envoyé : jeudi 6 septembre 2018 11:07
À : Tom Barbette; dev@dpdk.org; Alex Rosenbaum
Cc : Yongseok Koh; joh
num,
struct ibv_port_attr *port_attr);
struct ibv_comp_channel *(*create_comp_channel)
--
2.7.4
De : Shahaf Shuler
Envoyé : mercredi 5 septembre 2018 10:18
À : Tom Barbette; dev@dpdk.org; Alex Rosenbaum
Cc : Yongseok Koh; john.mcnam...@intel.com; marko.kovace...@
Thanks for your answer Shahaf !
We're trying to measure the latency of packets going through various service
chains inside individual "server". Eg. we can see that on Server 1, the
latency for the service chain handling HTTP packets is ~800ns (+ max and mins,
tail latency, etc). What we do no
Hi all,
As far as I know, MLX5 is the only driver to support hardware timestamping.
It would be great to update the doc to explain what the hardware timestamp is
supposed to be. If it's nanoseconds, then just a shift regarding system time is
enough ? Does it also need a multiplication? Can we
Hi list,
I found out that to staticly compile against DPDK using the combined lib, I
needed all these options :
-I${RTE_SDK}/${RTE_TARGET}/include -L${RTE_SDK}/${RTE_TARGET}/lib
-Wl,--whole-archive -ldpdk -Wl,--no-whole-archive -lnuma -ldl -lpthread -lm
-lmlx4 -lmlx5 -libverbs
The whole-archi
Hi all,
I get a EINVAL since DPDK 16.07 when trying to allocate a mempool with
rte_pktmbuf_pool_create. This is when I use --no-huge --vdev=eth_ring0. But
this happens before accessing the virtual device in any ways.
Which, btw shows the documentation is wrong as it indicates :
EINVAL - cache
how to allow e.g. VMDq pools
to receive packets without VLAN tags.
Signed-off-by: Tom Barbette
---
lib/librte_ether/rte_ethdev.h | 18 ++
1 file changed, 18 insertions(+)
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 1446540..98f18d7 100644
--
>From documentation it is very unclear how VMDq configuration can be
tweaked, and online search offer very poor results.
This patch will ultimately spawn an online documentation page
for the rte_eth_vmdq_rx_conf struct which will eventually add a bit of
documentation about the rx_mode tag and how
Hi list,
I'm trying to use the ETH_MQ_RX_VMDQ_RSS mode. The vmdq example is working fine
with VMDQ_ONLY, that is if I change the MAC address and VLAN of my crafted
packets, the RX queue also changes according to the matching pool.
But if I change the mode to VMDQ_RSS, the packet always end up i
P and UDP when only ETH_RSS_IP is given
instead of hashing to 0. That would mimic ixgbe behaviour btw.
Tom
- Mail original -
De: "Konstantin Ananyev"
À: "tom barbette" , "Bruce Richardson"
Cc: dev@dpdk.org
Envoyé: Lundi 6 Février 2017 13:25:59
Objet: RE: b
That also leave the question of how to HASH only on the IP tuple for TCP and
UDP packets? The use case is that I want all packets from the same IP src/dst
pair to be hashed to the same queue. This cannot be enforced with a complete
hash on TCP/UDP fields.
Tom
That solved it ! Thanks.
However I think this should be documented somewhere, especially as the
behaviour is different between i40e and ixgbe.
Tom
- Mail original -
De: "Bruce Richardson"
À: "tom barbette"
Cc: dev@dpdk.org
Envoyé: Lundi 30 Janvier 2017 11:46:30
Hi all,
No matter the number of queues or the ETH_RSS_X parameter the mbuf->hash.rss
field is empty using XL710 NICs. The exact same configuration gives me good
hash value values with ixgbe/82599 cards.
Any idea? I checked it is the same problem on 2.2 and 16.11. FlowDirector is
not used.
Tha
d it at runtime
for any NIC? I imagine that vector rx will create a problem if I give a burst
size of 1 even with a recent DPDK version, right?
Thanks,
Tom
Tom Barbette
PhD Student @ Université de Liège
Office 1/13
Bâtiment B37
Quartier Polytech
Allée de la découverte, 12
4000 Liège
04/3
Hi list,
Between 2.2.0 and 16.04 (up to at least 16.07.2 if not current), with the XL710
controller I do not get any packet when calling rte_eth_rx_burst if nb_pkts is
too small. I would say smaller than 32. The input rate is not big, if that
helps. But It should definitely get at least one pac
1 - 100 of 102 matches
Mail list logo
