dp_packet_l4_size(seg));
> -ip_hdr->ip_id = htons(ip_id);
> +tnl_hdr = dp_packet_l4(seg);
> +ip_tot_len = sizeof *ip_hdr + dp_packet_l4_size(seg);
ip_hdr->ip_tot_len = htons(dp_packet_l3_size(seg));
> +
mails.dpdk.org/archives/dev/2024-June/296764.html
>
> Suggested-by: David Marchand
> Signed-off-by: Ales Musil
I would split this in two patches (compilation changes in one patch,
error log in another) but overall the changes lgtm.
One nit below.
> ---
> tests/system-dp
On Fri, Jun 21, 2024 at 5:07 PM David Marchand
wrote:
> net/mlx5 is claiming (geneve|vxlan)_tso_offload while not supporting
> outer udp checksum.
This may be a set of capabilities we can use if, for example, no udp
checksum is requested.
How about adding:
# git diff
diff --git a/lib/netd
On Thu, Jun 27, 2024 at 4:04 PM David Marchand
wrote:
> @@ -926,6 +926,17 @@ netdev_send(struct netdev *netdev, int qid,
> struct dp_packet_batch *batch,
> return netdev_send_tso(netdev, qid, batch,
> concurrent_txq);
> }
> }
On Thu, Jun 27, 2024 at 10:38 AM Ales Musil wrote:
>
> Add more options that will shave some compilation time off DPDK by
> skipping unused parts of the code.
>
> Suggested-by: David Marchand
> Signed-off-by: Ales Musil
Reviewed-by: David Marchand
On Thu, Jun 27, 2024 at 10:38 AM Ales Musil wrote:
>
> Add skip for memory error produced by DPDK on ARM with 2MB hugepages
> which isn't harmful [0].
>
> [0] http://mails.dpdk.org/archives/dev/2024-June/296764.html
>
> Suggested-by: David Marchand
> Signed-off-by:
p_id);
> +tnl = false;
> +
> +if (outer_ipv4) {
> +outer_ip_id = ntohs(ip_hdr->ip_id);
> +}
> }
>
[snip]
Once this patch is in, we can re-enable
RTE_ETH_TX_OFFLOAD_VXLAN_TNL_TSO / RTE_ETH_TX_OFFLOAD_GENEVE_TNL_TSO
for Intel d
ing it?
OVS main branch uses DPDK 23.11 LTS.
Re-enabling this offload for Intel drivers will have to wait until the
fixes are part of a released 23.11 LTS (which is expected in August,
after OVS 3.4 is released).
--
David Marchand
___
dev mailing li
87292c ("userspace: Support VXLAN and GENEVE TSO.")
> Signed-off-by: Mike Pattrick
Reviewed-by: David Marchand
--
David Marchand
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
t_txq);
> }
> -return netdev_send_tso(netdev, qid, batch, concurrent_txq);
> }
> }
> }
A final note, I suspect all those checks negatively impact non tso
packets processing when OVS tso is
t; we no longer need to disable the VXLAN/Geneve TSO flags from intel
> hardware support flags.
>
> The modification to outer UDP offload is still required pending a future
> DPDK release.
>
> Suggested-by: David Marchand
> Signed-off-by: Mike Pattrick
Reviewed-by: David Marc
On Mon, Jul 8, 2024 at 4:22 PM Mike Pattrick wrote:
> On Mon, Jul 8, 2024 at 8:23 AM David Marchand
> wrote:
> > A final note, I suspect all those checks negatively impact non tso
> > packets processing when OVS tso is enabled.
> >
> > Would it be feasible to mark
i
The issue seems generic as any netdev for which a call to
netdev_get_stats failed would trigger the same leak.
So I would update the commit title with something more generic like:
dpctl: Fix netdev reference leak in "show" command.
This can probably be changed when applying.
In an
Caught by code review, calling netdev_open works in pair of netdev_close
when no reference to a netdev must be kept.
Fixes: 921c370a9df5 ("dpif-netlink: Probe for out-of-tree tunnels, decides used
interface")
Signed-off-by: David Marchand
---
lib/dpif-netlink-rtnl.c | 1 +
1 file
gt; At any rate, giving my ACK for this patch.
>
> Acked-by: Eric Garver
Thanks.
--
David Marchand
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
ixes: 084c8087292c ("userspace: Support VXLAN and GENEVE TSO.")
> Signed-off-by: Mike Pattrick
I see no difference with v4, so just repeating:
Reviewed-by: David Marchand
--
David Marchand
___
dev mailing list
d...@openvswitch.org
https://mail.o
is skipped in the
CI) but I was ok with the previous version.
Reviewed-by: David Marchand
--
David Marchand
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
ation to outer UDP offload is still required pending a future
> DPDK release.
Indeed, when the dpdk fixes are in, we can re-enable those
capabilities (well, to be more precise, we can stop filtering broken
capabilities) on those nics.
>
> Suggested-by: David Marchand
> Signed-off-by: Mi
ng by default.")
Signed-off-by: David Marchand
---
Note: this issue was first noticed while natting IP packets received from
a DPDK port (reporting that the packet IP checksum was correct) and
sending those packets to a tap netdev.
---
lib/netdev-linux.c | 16 +++-
1 file changed, 3
As OVS does not know of the 25G speed, matching on a list of known speed
for deducing full duplex capability is broken.
Invert the test and assume full duplex is the default.
Suggested-by: Adrian Moreno
Signed-off-by: David Marchand
---
lib/netdev.c | 10 +-
1 file changed, 5
,
> + netdev_dpdk_get_port_id(netdev), ds_cstr(&s));
I wonder why we had two log messages so far.
In any case, wrt ratelimit, with this change above, I would say we
should log only one message.
--
David Marchand
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
if (is_queue_stat(name) ||
string_ends_with(name, "_errors") ||
strstr(name, "_management_") ||
string_ends_with(name, "_dropped")) {
dev->rte_xstats_ids[dev->rte_xstats_ids_size] = id;
dev->rte_xstats_ids_size++;
netdev_get_name(netdev), extra_str,
> -netdev_dpdk_get_port_id(netdev), ds_cstr(&s));
> +VLOG_DBG("%s: rte_flow creation failed [%d (%s)]: "
> + "%s flow create %d %s", netdev_get_name(netdev),
>
topic :-).
>
> Fixes: 084c8087292c ("userspace: Support VXLAN and GENEVE TSO.")
> Reported-by: Jun Wang
>
Nit: no need for an extra line here.
> Signed-off-by: Jun Wang
Acked-by: David Marchand
--
David Marchand
"on numa node %d. Port \'%s\' rx queue %d will "
> + "be assigned to a pmd on numa node %d. "
> +"This may lead to reduced performance.",
> +numa_id, netdev_rxq_get_name(rxq->rx),
> +netdev_rxq_get_queue_id(rxq->rx), numa->numa_id);
> +}
> +
> +sched_pmd = NULL;
> +if (numa) {
> +/* Select the PMD that should be used for this rxq. */
> +sched_pmd = get_next_pmd(numa, algo);
> +if (sched_pmd) {
> +VLOG(level, "Core %2u on numa node %d assigned port \'%s\' "
> +"rx queue %d.%s",
%d%s.
> +sched_pmd->pmd->core_id, sched_pmd->pmd->numa_id,
> +netdev_rxq_get_name(rxq->rx),
> +netdev_rxq_get_queue_id(rxq->rx),
> +get_rxq_cyc_log(rxq_cyc_log, algo, proc_cycles)
> +? rxq_cyc_log : "");
> +sched_add_rxq_to_sched_pmd(sched_pmd, rxq, proc_cycles);
> }
> }
> +if (!sched_pmd) {
> +VLOG(level == VLL_DBG ? level : VLL_WARN,
> +"No non-isolated pmd on any numa available for "
> +"port \'%s\' rx queue %d.%s "
%d%s.
> +"This rx queue will not be polled.",
> +netdev_rxq_get_name(rxq->rx),
> +netdev_rxq_get_queue_id(rxq->rx),
> +get_rxq_cyc_log(rxq_cyc_log, algo, proc_cycles)
> +? rxq_cyc_log : "");
> +}
> }
> -
> -rr_numa_list_destroy(&rr);
> free(rxqs);
> }
>
> +static void
> +rxq_scheduling(struct dp_netdev *dp) OVS_REQUIRES(dp->port_mutex)
> +{
> +struct sched_numa_list *numa_list;
> +bool algo = dp->pmd_rxq_assign_cyc;
> +
> +numa_list = xzalloc(sizeof *numa_list);
> +
> +sched_numa_list_populate(numa_list, dp);
> +sched_numa_list_schedule(numa_list, dp, algo, VLL_INFO);
> +sched_numa_list_put_in_place(numa_list);
> +
> +sched_numa_list_free_entries(numa_list);
> +free(numa_list);
> +}
> +
> static void
> reload_affected_pmds(struct dp_netdev *dp)
> @@ -5406,10 +5763,5 @@ reconfigure_datapath(struct dp_netdev *dp)
> }
> }
> -
> -/* Add pinned queues and mark pmd threads isolated. */
> -rxq_scheduling(dp, true);
> -
> -/* Add non-pinned queues. */
> -rxq_scheduling(dp, false);
> +rxq_scheduling(dp);
>
> /* Step 5: Remove queues not compliant with new scheduling. */
> diff --git a/tests/pmd.at b/tests/pmd.at
> index cc5371d5a..78105bf45 100644
> --- a/tests/pmd.at
> +++ b/tests/pmd.at
> @@ -580,5 +580,5 @@ p1 3 0 2
> ])
>
> -OVS_VSWITCHD_STOP(["/dpif_netdev|WARN|There is no PMD thread on core/d"])
> +OVS_VSWITCHD_STOP(["/cannot be pinned with port/d"])
> AT_CLEANUP
>
> --
> 2.31.1
>
--
David Marchand
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
struct sched_numa {
> };
>
> +static uint64_t variance(uint64_t a[], int n);
Nit: this fwd declaration can be moved right before
sched_numa_list_variance() which is the only function that uses it.
Or variance() itself could be moved.
> +
> static size_t
> sched_numa_list_count(struct sched_numa_list *numa_list)
> @@ -5181,4 +5049,36 @@ sched_add_rxq_to_sched_pmd(struct sched_pmd *sched_pmd,
> }
>
> +static void
> +sched_numa_list_assignments(struct sched_numa_list *numa_list,
> + struct dp_netdev *dp)
Indent of second line.
+
Don't we need a OVS_REQUIRES(dp->port_mutex) annotation?
> +{
> +struct dp_netdev_port *port;
> +
> +/* For each port. */
> +HMAP_FOR_EACH (port, node, &dp->ports) {
> +if (!netdev_is_pmd(port->netdev)) {
> +continue;
> +}
[snip]
--
David Marchand
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
ed_assignment_type algo,
> + bool has_proc)
> {
> -return get_available_rr_pmd(numa, algo);
> +if (algo == SCHED_GROUP) {
> +struct sched_pmd *sched_pmd = NULL;
> +
> +/* Check if the rxq has associated cycles. This is handled
&g
+++ b/tests/pmd.at
> @@ -552,7 +552,10 @@ AT_CHECK([ovs-vsctl set Open_vSwitch .
> other_config:pmd-cpu-mask=6])
>
> dnl We removed the cores requested by some queues from pmd-cpu-mask.
> -dnl Those queues will not be polled.
> +dnl Those queues will be polled by remaining non-isolated pmds.
> AT_CHECK([ovs-appctl dpif-netdev/pmd-rxq-show | parse_pmd_rxq_show], [0],
> [dnl
> +p1 0 0 1
> +p1 1 0 1
> p1 2 0 2
> +p1 3 0 1
> ])
>
> --
> 2.31.1
>
--
David Marchand
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
On Thu, Jun 24, 2021 at 4:52 PM David Marchand
wrote:
> > @@ -5229,16 +5300,40 @@ get_available_rr_pmd(struct sched_numa *numa, bool
> > updown)
> >
> > static struct sched_pmd *
> > -get_next_pmd(struct sched_numa *numa, bool algo)
> > +get_ne
ed* by
> +default. This means that this thread will only poll the *pinned* Rx queues.
> +
> +If using ``pmd-rxq-assign=group`` PMD threads with *pinned* Rxqs can be
> +*non-isolated* by setting::
> +
> + $ ovs-vsctl set Open_vSwitch . other_config:pmd-isolate=false
pmd-rxq-isolat
l, this series lgtm with the comments I sent.
It is worth adding some point in the NEWS file to advertise the new feature.
--
David Marchand
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
y: Ben Pfaff
> Reported-by: 贺鹏
--
David Marchand
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
eue-id: 0 (enabled) pmd usage: 0 %
port: vhost4queue-id: 0 (enabled) pmd usage: 0 %
port: vhost5queue-id: 0 (enabled) pmd usage: 92 %
port: vhost7queue-id: 0 (enabled) pmd usage: 0 %
overhead: 7 %
Signed-off-by: David Marchand
---
Change
On Fri, Jun 11, 2021 at 2:02 PM Kevin Traynor wrote:
>
> Hi David,
>
> A few comments below,
Thanks for the review and comments, all seemed fine to me.
Retested with my setup and I just posted v2 on the ml.
--
David Marchand
___
dev ma
Explicitely setting the memory configuration gives determinism.
Hugepages allocations are done once at EAL init, and then OVS picks
into them for building mempools and for rte_malloc's.
As long as those operations are done in control path, this is not
really a concern.
But iirc, we have rte_malloc calls in the datapath for TSO support
(external buffer) and here, it means syscalls in the datapath when
growing "DPDK heap".
I agree, this might not happen often with 1G hugepages and once
reaching a steady state.
--
David Marchand
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
gt; + The new debug appctl command `dpif-netlink/dispatch-mode`
> + will return the current dispatch mode for each datapath.
>
> v2.15.0 - 15 Feb 2021
> -
--
David Marchand
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Same as for Travis, let's have dpdk-latest build against the dpdk current
main branch.
Note: this should not be merged to master, intended for dpdk-latest
branch only.
Signed-off-by: David Marchand
---
.github/workflows/build-and-test.yml | 1 +
1 file changed, 1 insertion(+)
diff --
ng assignments so they are used
>
> Signed-off-by: Kevin Traynor
Acked-by: David Marchand
--
David Marchand
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
ments, new functions are added to populate the current
> assignments and use the rxq scheduling data structs for variance
> calculations.
>
> Now that the new rxq scheduling data structures are being used in
> PMD auto load balance, the older rr_* data structs and associated
> functions can
xqs
> on different runs for no reason other than how the PMDs are stored
> in the hash map.
>
> This can be easily changed by sorting the PMDs by core id after
> they are extracted, so the PMDs will be used in a consistent order.
>
> Signed-off-by: Kevin Traynor
Acked-b
used.
>
> Signed-off-by: Kevin Traynor
Acked-by: David Marchand
--
David Marchand
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
t one PMD may have a group of low load rxqs assigned to it
> while another PMD has one high load rxq assigned to it, as that is the
> best balance of their measured loads across the PMDs.
>
> Signed-off-by: Kevin Traynor
Acked-by: David Marchand
--
David Marchand
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
of the other rxq assignment algorithms.
>
> Signed-off-by: Kevin Traynor
Acked-by: David Marchand
--
David Marchand
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
> Signed-off-by: Kevin Traynor
Acked-by: David Marchand
--
David Marchand
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
64932
>
> v4:
> - Fixed NEWS file conflict from (almost) mid-air collision of other patch
> merging
There is again one conflict now, but it does not deserve a v5.
Series lgtm, thanks.
--
David Marchand
___
dev mailing list
d...@openvswitch.org
option.
GHA ui jumps at the last line of a failing step, but the problem is
that, in OVS, we dump all logs which adds a lot of noise.
We could stop dumping them, since those logs are attached to the job
as an archive.
Like what is done in DPDK.
http://git.dpdk.org/dpdk/tree/.ci/linux-build.sh#n3
W
.lo] Error 1
make[2]: *** Waiting for unfinished jobs
The rest of the file uses memset() for this kind of init to 0.
Probably worth aligning null_police too.
--
David Marchand
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
t; ^
> 1 error generated.
> make[2]: *** [lib/netdev-linux.lo] Error 1
> make[2]: *** Waiting for unfinished jobs
>
> Fixes: c2567e533 ("add port-based ingress policing based packet-per-second
> rate-limiting")
> Reported-by: Davi
GHA webui directly focus on the last lines for a failing step.
config and testsuite logs are attached as artifacts in GHA in case of
failures, so dumping them just adds noise.
Skip dumping those files. Travis is left untouched though
Signed-off-by: David Marchand
---
Note:
I could do only little
he race was probably not a problem
before actually doing full offload.
Reported-at:
https://mail.openvswitch.org/pipermail/ovs-dev/2021-March/381296.html
> Signed-off-by: Eli Britstein
> Reviewed-by: Gaetan Rivet
Copying Maxime.
Patch lgtm and it fixes the issue I had seen.
Reviewed-by:
")
>
> Signed-off-by: Eli Britstein
> Reviewed-by: Gaetan Rivet
Reviewed-by: David Marchand
--
David Marchand
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
eue-id: 0 (enabled) pmd usage: 0 %
port: vhost4queue-id: 0 (enabled) pmd usage: 0 %
port: vhost5queue-id: 0 (enabled) pmd usage: 92 %
port: vhost7queue-id: 0 (enabled) pmd usage: 0 %
overhead: 7 %
Signed-off-by: David Marchand
---
Change
On Fri, Jul 16, 2021 at 7:30 PM Stokes, Ian wrote:
>
> > On 16/07/2021 17:21, David Marchand wrote:
> > > Users complained that per rxq pmd usage was confusing: summing those
> > > values per pmd would never reach 100% even if increasing traffic load
> > > beyo
This is a simple cleanup with a script of mine.
Signed-off-by: David Marchand
---
This script is a bit too silly/simplistic and requires manual review
(too many false positives), but I don't think it is worth investing too
much time into integrating this kind of check in utilities/checkpat
59&state=*
Signed-off-by: David Marchand
---
.ci/dpdk-build.sh| 28 +++-
.ci/linux-build.sh | 9
.github/workflows/build-and-test.yml | 4 ++--
Documentation/faq/releases.rst | 2 +-
Documentation/i
t; Signed-off-by: Eelco Chaudron
Thanks for the fix.
Reviewed-by: David Marchand
--
David Marchand
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
e
cpu spent calling ovs-appctl).
Suggested-by: Ilya Maximets
Reviewed-by: Maxime Coquelin
Acked-by: Eelco Chaudron
Signed-off-by: David Marchand
---
Changes since v4:
- rebased,
- updated genpkts.py so it outputs 8 packets per line and have
netdev-dummy/receive called for 8 packets at a time
The MFEX code and tests do not depend on DPDK anymore.
We can move the unit tests to dpif-netdev.
Reviewed-by: Maxime Coquelin
Acked-by: Eelco Chaudron
Acked-by: Kumar Amber
Signed-off-by: David Marchand
---
Changes since v4:
- rebased,
- added dummy numa configuration,
Changes since v3
ed-by: Eelco Chaudron
Signed-off-by: David Marchand
---
Changes since v5:
- rebased,
- moved the script to the python scripts list in automake.mk,
- bumped copyright date,
Changes since v4:
- separated from the original series,
- rebased,
- dropped mlx5 devices from the discovery script,
- docum
59&state=*
There is a known issue with i40e VF devices where OVS main thread may
block when adding such devices as dpif-netdev dpdk ports.
Signed-off-by: David Marchand
---
.ci/dpdk-build.sh| 28 +++-
.ci/linux-build.sh
ing further.
>
> David, could you, please, add a note in the NEWS file and send a new version
> of the patch?
I just sent a v2.
I'll continue investigating the iavf issue.
--
David Marchand
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
10,sport=,...
Fixes: 07659514c3c1 ("Add support for connection tracking.")
Signed-off-by: David Marchand
---
tests/system-common-macros.at | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/system-common-macros.at b/tests/system-common-macros.at
index 01ebe
hread later handles the port reset request.
Link: https://bugs.dpdk.org/show_bug.cgi?id=1337
Signed-off-by: David Marchand
---
lib/netdev-dpdk.c | 73 +--
1 file changed, 58 insertions(+), 15 deletions(-)
diff --git a/lib/netdev-dpdk.c b/lib/netdev-d
On Thu, Jan 18, 2024 at 2:23 PM Ilya Maximets wrote:
>
> On 1/18/24 14:16, David Marchand wrote:
> > When OVS (main thread) configures a DPDK netdev, it holds a netdev_dpdk
> > mutex lock.
> > As part of this configure operation, the net/iavf driver (used with i40e
&g
hread later handles the port reset request.
More details in the DPDK upstream bz as this issue appeared following a
change in DPDK.
Link: https://bugs.dpdk.org/show_bug.cgi?id=1337
Signed-off-by: David Marchand
---
Changes since v1:
- converted to atomic accesses on netdev_dpdk_pending_
On Thu, Jan 18, 2024 at 3:41 PM David Marchand
wrote:
> Changes since v1:
> - converted to atomic accesses on netdev_dpdk_pending_reset[],
I did not wait for the clang results during my tests... cooking v3.
--
David Marchand
___
dev mailing
On Thu, Jan 18, 2024 at 4:43 PM Ilya Maximets wrote:
>
> On 1/18/24 15:41, David Marchand wrote:
> > When OVS (main thread) configures a DPDK netdev, it holds a netdev_dpdk
> > mutex lock.
> > As part of this configure operation, the net/iavf driver (used with i40e
&g
hread later handles the port reset request.
More details in the DPDK upstream bz as this issue appeared following a
change in DPDK.
Link: https://bugs.dpdk.org/show_bug.cgi?id=1337
Signed-off-by: David Marchand
---
Changes since v2:
- fixed build with clang,
- fixed indentation,
- updated
On Fri, Jan 19, 2024 at 1:20 PM Simon Horman wrote:
>
> On Thu, Jan 18, 2024 at 02:00:18PM +0100, David Marchand wrote:
> > Seen in GHA recently.
> > Unit tests are checking conntracks relating to a destination ip address
> > but the FORMAT_CT macro is not strict enough a
On Fri, Jan 19, 2024 at 1:49 PM Ilya Maximets wrote:
>
> On 1/18/24 14:00, David Marchand wrote:
> > Seen in GHA recently.
> > Unit tests are checking conntracks relating to a destination ip address
> > but the FORMAT_CT macro is not strict enough and would match unre
packet is already flagged
> for tunneling, so an incorrect determination isn't possible as long as
> the flags of the packet are correct.
>
> Fixes: 85bcbbed839a ("userspace: Enable tunnel tests with TSO.")
> Signed-off-by: Mike Pattrick
R
m
offloading, this patch also fixes the packet_type used by other
dp_packet helpers.
I see nothing fixed on that later topic though.
>
> Fixes: ccc096898c46 ("bfd: Implement Bidirectional Forwarding Detection.")
> Signed-off-by: Mike Pattrick
Reviewed-by: David
t; @@ -125,7 +134,7 @@ avx512_dp_packet_resize_l2(struct dp_packet *b, int
> resize_by_bytes)
> /* Each lane represents 16 bits in a 12-bit register. In this case the
> * first three 16-bit values, which will map to the l2_5_ofs, l3_ofs and
> * l4_ofs fields. */
> -const uint8_t k_lanes = 0b1110;
> +const uint8_t k_lanes = 0b10;
>
> /* Set all 16-bit words in the 128-bits v_offset register to the value we
> * need to add/substract from the l2_5_ofs, l3_ofs, and l4_ofs fields. */
Touching this part scares me.
I think some comments are wrong, and otherwise I hope Intel CI will be
enough to check nothing gets broken here :-).
--
David Marchand
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
igned-off-by: Mike Pattrick
Reviewed-by: David Marchand
--
David Marchand
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
ere is no handler to start at all.
--
David Marchand
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
On Tue, Feb 6, 2024 at 3:47 PM Eelco Chaudron wrote:
> On 6 Feb 2024, at 15:17, David Marchand wrote:
>
> > On Tue, Feb 6, 2024 at 2:31 PM Eelco Chaudron wrote:
> >>
> >> Avoid unnecessary thread creation as no upcalls are generated,
> >> resulting in idle
e other
> metadata like packet_type are set appropriately.
>
> Fixes: ccc096898c46 ("bfd: Implement Bidirectional Forwarding Detection.")
> Signed-off-by: Mike Pattrick
Reviewed-by: David Marchand
--
David Marchand
___
dev
On Mon, Feb 12, 2024 at 7:54 AM Mike Pattrick wrote:
>
> Include inner offsets in functions where l3 and l4 offsets are either
> modified or checked.
>
> Fixes: 084c8087292c ("userspace: Support VXLAN and GENEVE TSO.")
> Signed-off-by: Mike Pattrick
Reviewed-by:
> UDP tunnel layer instead of the intermediary tunnel layer.
>
> This resulted in the middle UDP tunnel not checksum offloading properly.
>
> Fixes: 3337e6d91c5b ("userspace: Enable L4 checksum offloading by default.")
> Reported-by: David Marchand
> Signed-off-by: Mike P
en in 3.3.
If we strip the 3rd layer of tunnel from my unit test, it would be
enough to reproduce without hitting af_xdp headroom limit.
Or do you think we can extend an existing test?
At least, fixes should be isolated from the new features like one
introduced in patch 1 of this series.
--
Da
n
> index 9569265fcb..a6a4a24606 100644
> --- a/vswitchd/ovs-vswitchd.8.in
> +++ b/vswitchd/ovs-vswitchd.8.in
> @@ -81,6 +81,14 @@ unavailable or unsuccessful.
> .SS "DPDK Options"
> For details on initializing \fBovs\-vswitchd\fR to use DPDK ports,
> refer to the documentation or \fBovs\-vswitchd.conf.db\fR(5).
> +.SS "DPDK HW Access Options"
> +.IP "\fB\-\-hw\-rawio\-access\fR"
> +Tells \fBovs\-vswitchd\fR to retain the \fBCAP_SYS_RAWIO\fR capability,
> +to allow userspace drivers access to raw hardware memory. This will
> +also allow the \fBovs\-vswitchd\fR daemon to call \fBiopl()\fR and
> +\fBioperm()\fR functions to set port access. This is a \fBvery\fR
The main usecase for this OVS option would be mlx5 + full hwoffload in
DPDK, so if giving an example in the manual, I'd rather mention it.
On the other hand, iopl() is (was?) used in DPDK for x86 + virtio pmd
with virtio pre v1.
And here, I don't expect many people plugging OVS on top of this.
Do you have another case in mind for iopl()/ioperm()?
The rest lgtm.
Thanks for working on this Aaron.
> +powerful capability, so generally only enable as needed for specific
> +hardware.
> .SS "Daemon Options"
> .ds DD \
> \fBovs\-vswitchd\fR detaches only after it has connected to the \
--
David Marchand
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
lding DPDK does not depend on how we will link OVS against it, so we
can use a single cache entry regardless of DPDK_SHARED option,
Signed-off-by: David Marchand
---
.ci/dpdk-build.sh| 68
.ci/dpdk-prepare.sh | 11 +
.ci/
On Thu, Mar 30, 2023 at 11:24 AM David Marchand
wrote:
>
> Let's separate DPDK compilation from the rest of OVS build:
> - this avoids multiple jobs building DPDK in parallel, which especially
> affects builds in the dpdk-latest branch,
Err, this patch actually breaks dpdk
et a working container.
I would go with ubuntu-latest.
> +container: fedora:37
> +timeout-minutes: 30
> +
> +strategy:
> + fail-fast: false
--
David Marchand
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> We may switch to quay.io if that will ever become a problem
> in the future.
>
> Signed-off-by: Ilya Maximets
Reviewed-by: David Marchand
--
David Marchand
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Hello Ilya,
On Tue, Apr 4, 2023 at 8:01 PM Ilya Maximets wrote:
>
> On 3/30/23 11:24, David Marchand wrote:
> > Let's separate DPDK compilation from the rest of OVS build:
> > - this avoids multiple jobs building DPDK in parallel, which especially
> > affects bui
lding DPDK does not depend on how we will link OVS against it, so we
can use a single cache entry regardless of DPDK_SHARED option,
Signed-off-by: David Marchand
---
Changes since v1:
- filtered dpdk build job dependencies: it only needs gcc, ninja and
libnuma-dev,
- removed matrix configuratio
60b89a309d ("dpif-netlink: Offloading meter to tc police action")
Signed-off-by: David Marchand
---
tests/system-offloads-traffic.at | 1 -
1 file changed, 1 deletion(-)
diff --git a/tests/system-offloads-traffic.at b/tests/system-offloads-traffic.at
index da18597cd8..df43caa9e5 10064
On Tue, Apr 18, 2023 at 10:20 AM Simon Horman wrote:
>
> On Mon, Apr 17, 2023 at 06:28:13PM +0200, David Marchand wrote:
> > Caught during some code review.
> > The incriminated commit had put an unneeded check on tc ingress support
> > for the meter offlo
request.user_features |= OVS_DP_F_VPORT_PIDS;
dp_request.user_features |= OVS_DP_F_UNSUPPORTED;
-error = dpif_netlink_dp_transact(&dp_request, &dp, &buf);
+error = dpif_netlink_dp_transact(&dp_request, NULL, NULL);
if (error) {
/* The Open vSwitch kernel modul
Caught during some code review.
SUPPORT_TC_INGRESS_PPS has been replaced with CHECK_TC_INGRESS_PPS().
Fixes: 5f0fdf5e2c2e ("test: Move check for tc ingress pps support to test
script.")
Signed-off-by: David Marchand
---
tests/system-offloads-traffic.at | 2 +-
1 file changed, 1 inser
ag for your patch.
I just sent a new patch, and marked this current one as Rejected.
Thanks Simon and sorry for the confusion.
--
David Marchand
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
transact() makes it possible for a
caller to simply ignore the reply from the kernel by passing both
'reply' and 'bufp' as NULL.
- In the specific call to dpif_netlink_dp_transact() (line 398) in
dpif_netlink_open(), the 'dp&#
onned it initially when enabling ASan:
https://mail.openvswitch.org/pipermail/ovs-dev/2021-February/380467.html
More recently, Eelco mentionned it:
https://mail.openvswitch.org/pipermail/ovs-dev/2022-September/397476.html
I also see it every once in a while in GHA.
--
David Marchand
e
> value and log.
>
> Reported-at: https://bugzilla.redhat.com/2119876
> Signed-off-by: Kevin Traynor
Thanks for the added log.
Overall, this looks good to me.
I have a comment on how the limits are taken into account (see below).
But in any case this patch is ok as is for me:
Reviewed-
#15 0x40ba5a in bridge_reconfigure vswitchd/bridge.c:885
> #16 0x41f1a9 in bridge_run vswitchd/bridge.c:3313
> #17 0x42d4fb in main vswitchd/ovs-vswitchd.c:132
> #18 0x7fe09cc03c86 in __libc_start_main (/usr/lib64/libc.so.6+0x25c86)
>
> Fixes: b841e3cd4a28 ("dpif-ne
ding DPDK including
> > DPDK_VER.
> > + # This also allows us to use cache from any branch as long as version
> > + # and a way we're building DPDK stays the same.
> > + run: |
> > + grep -irE 'RTE_|DPDK|meson|ninja' .ci/dpdk-* > dp
On Fri, Apr 28, 2023 at 11:36 AM David Marchand
wrote:
> > > +- name: create ci signature file for the dpdk cache key
> > > + # This will collect most of DPDK related lines, so hash will be
> > > different
> > > + # if something changed in
lding DPDK does not depend on how we will link OVS against it, so we
can use a single cache entry regardless of DPDK_SHARED option,
Reviewed-by: Simon Horman
Signed-off-by: David Marchand
---
Changes since v2:
- removed unneeded checks when the cache is hit,
- exposed the cache key computed i
On Fri, Apr 28, 2023 at 2:26 PM David Marchand
wrote:
>
> On Fri, Apr 28, 2023 at 11:36 AM David Marchand
> wrote:
> > > > +- name: create ci signature file for the dpdk cache key
> > > > + # This will collect most of DPDK related lines, s
1 - 100 of 1021 matches
Mail list logo
